Failing to run export on other (headless) machine

Help/How To
1

So I thought, can I do the editing on one machine and then move the export job (ie: the melt xml saved from the job queue) to another machine to actually run the export and encode? It looks like it should work, that the XML job file is a melt file that can be fed into the melt commandline tool. All the information appears to be there.

It doesn’t work. :frowning: I still think it should and wonder what incantations I’m missing…

In a bit more detail: :grinning: Interactive editing machine is a Mac running 21.05.18, this includes a melt 7.1.0 binary (which I presume comes from git master as that’s later than the stable release).

Desired encoding machine is Linux running Ubuntu 20.04, on which I have compiled and installed melt 7.1.0 from git master, using cmake, and provided all the dependencies it seems to want. But ignore potential issues with that build (for now) as, when it didn’t work, I just tried the file against the melt binary in the shotcut app on the Mac and am still seeing the same problem. Needless to say, running the encode jobs in shotcut does work.

(The encode itself is just using avformat, libx265, all software-based, no attempted use of GPU accelerated encoders. The only transitions being used are cuts, no filters. And I did amend the file to point to the different locations of the files on the other machine. And it is finding them.)

The commandline is just melt <filename.mlt>, although also tried with -verbose and -debug which showed some more output but nothing very useful (like: error messages or indications of anything going wrong).

The symptom is that, after a lot of output from the decoders (which I see just the same when eg: using handbrake), it gets to:

Current Position: 0

And it stays there forever. the ‘melt’ process taking 100% of a single CPU core. Although, visible on Linux at least, it seems to change which core from time to time. The output file is created, but stays stubbornly at 0 bytes.

This is on both the Linux system and the Mac system with the melt binary inside the shotcut app.

I do notice when exporting in shotcut itself, that it too sits for a while seemingly preparing itself for the task ahead, before it starts actually encoding. But here “a while” is typically about a minute or so? I’ve left the commandline melt processing running an hour in the hope of seeing it produce something, and there’s nothing.

I think it crashed. I can’t ctrl-c to stop it, or kill -15. Only kill -9 works. (Or the equivalent “force quit” from the mac activity monitor.)

2

If I run a Shotcut (not melt) encode job on a big project, I see this command line in Task Manager:

melt-7 -verbose -progress2 -abort xml:%2Ftmp%2Fshotcut-WcUdlq.mlt

The %2F is URL encoding for forward slash, as in, the whole filename needs to be URL encoded.

Inside that MLT file is my project along with an extra <consumer> element which contains all my encoding settings:

<?xml version='1.0' standalone='no'?>
<mlt producer="main_bin" LC_NUMERIC="C" version="7.1.0" title="Shotcut version 21.06.15">
  <profile description="HD 1080p 25 fps" sample_aspect_num="1" height="1080" sample_aspect_den="1" display_aspect_num="16" frame_rate_den="1001" frame_rate_num="30000" progressive="1" colorspace="709" display_aspect_den="9" width="1920"/>
  <consumer bf="3" top_field_first="2" g="149" acodec="aac" vcodec="libx265" ab="256k" real_time="-1" x265-params="keyint=149:bframes=3:crf=28:" threads="0" f="mp4" target="/home/mint/Videos/Output.mp4" mlt_service="avformat" crf="28" ar="48000" movflags="+faststart" deinterlace_method="yadif" rescale="bilinear" preset="medium" channels="2"/>

The target attribute in particular has the output filename.

If your MLT file doesn’t have that <consumer> element added to it, or the command line isn’t specifying any output options, then melt probably doesn’t know what format to produce or where to save it.

A possibility to make your life easier…

Instead of bringing melt in from Git master and compiling yourself, you could download the .tar.gz version of Shotcut and unpack it and run melt directly out of there. It skips the compile step, and also guarantees you’re using the same version of melt that Shotcut would for that version.

Never mind: Looks like you already did that.

3

i should have thought to look at that. (Hint to other mac/linux users: It shows up with ps -ef.) Those weren’t important though. (I fixed it.)

-progress2 is just showing progress on separate lines rather than overwriting the first line (in classic console terms, a crlf rather than just a cr), and is presumably making it easier for the gui to catch it.

-abort, dunno, it’s not in its --help message, but i’ll use it. Maybe it needs that to quit without being killed…

xml:<url-encoded-path> seems not to be necessary. it’s happy just taking the filename.

But the actual problem turned out to be an error in my custom export preset, which I thought I had working… An extra ffmpeg option made its way in there without any obvious intervention from me (“frame_rate_den=1000000” A million frames per second). Take that out and it’s processing happily now on my Linux box.

Looks like it gets added by default when you add a custom export. Can see it in the full list of options it shows me during the add export process. Maybe a bug?

4

When you create an export preset, all information is included - including what is on the video tab - in the dialog that appears. It recommends that you review and edit (remove) things that should not be preset.

5

The URL encoding is optional but helps with special characters anywhere in the path. There is one other important thing not shown: set the environment variable LC_ALL=C. Otherwise it may interpret the real numbers in your XML incorrectly.

6

I figured, and recreated the preset accordingly. I still can’t see where that frame-rate-den is coming from though. eg: just click on the standard HEVC Main Profile preset, click Plus to make a custom preset out of that, and there it is, but i can’t see anything in the export dialogs that relate to it.

7

… one for the script, when i get to making a script. :grinning: It seems to be content with the default though, at least here in en-GB-land

8

Reproduced using stock video modes 1080p 25fps and 60fps:

frame_rate_num=25000000
frame_rate_den=1000000

Curious that the multiplier is so high for non-fractional frame rates.

The frame rate numbers come from the Video Mode, not necessarily the export settings (unless overridden).

9

hm. i misread the meaning of the field before, and yes, 25 million divided by one million may look excessive but should work. Nevertheless, removing it during the process of adding the preset, but leaving the frame_rate_num=25000000 in, seems to be producing a working output. I get this in the subsequent export mlt using that export:
<profile sample_aspect_den="1" frame_rate_den="1" description="PAL 4:3 DV or DVD" height="1080" progressive="1" colorspace="709" sample_aspect_num="1" width="1920" frame_rate_num="25" display_aspect_den="9" display_aspect_num="16"/>
… which looks correct.

10

Looks like there was a workaround to a UI issue re: adding the million multiplier.

11

That code is writing the consumer element… Or at least it’s writing into a structure that’s going to be written to the consumer element. And it looks OK to me.

What I see (in the preset where it was set) is that the frame_rate_den attribute is written, with 1000000, and that gets written into the consumer element of the export job. But the frame_rate_num attribute is not written into the consumer element. Looking at that code, I’m not sure how that happens. It looks like it only writes both or neither, as it should, and I can’t see anything glaringly removing it later as well.

Are we sure we know what qRound is returning there? it looks like it should be int 25000000 (which should be OK, it’s well under INT_MAX) but is it? Is Mlp::Properties->set not liking what it’s given but just not doing anything rather than throwing an error? Or maybe writing an empty attribute value, which would get skipped when it finally is actually creating the DOM element.

So then when it actually makes the calculation, it takes the frame_rate_num from the profile, which is 25, and the frame_rate_den from the consumer, which is 1000000. To give a framerate of 25/1000000, which it probably didn’t like very much!

12

This topic was automatically closed after 90 days. New replies are no longer allowed.