#21 MLT can't encode faster than 1x

[Anonymous]

MLT is intended to stream live video, so, is impossible to configure it for encoding a edited video.

I'm trying to create a script that joins some clips with transitions, but when I execute it the script needs more time than the film created (using any codec)

So, there must be a limitation (or a config value) for the playback speed.
For example, the profiles should have something like "playback_speed", configurable in FPS or in 1x / 2x ..; and that setting should be set to "Infinite" when streaming to a file.

[Dan Dennedy]

Just because your situation required longer than realtime does not mean it is incapable. It means the processing and encoding of your project takes longer than realtime due to lack of adequate hardware and potentially the need for additional software optimization. (And do not open a bug that MLT needs to be faster; that is not specific enough. Of course, all software needs to be faster even though the predominant trend is otherwise.) For example:

$ ffmpeg -i chap.ts
...
Duration: 00:17:31.61 ...

$ time inigo -profile quarter_ntsc chap.ts -consumer avformat:test.avi threads=2
...
real 8m20.379s

8 minutes is less than 17.

[David Martínez]

>Just because your situation required longer than realtime does not mean it
>is incapable. It means the processing and encoding of your project takes
>longer than realtime due to lack of adequate hardware and potentially the
>need for additional software optimization.

I see. I was very ofuscated yesterday trying to optimize the process in several ways, and I got confused.
My best ratio was 0.9x, but today I tried with some other arguments and I was able to encode something at 2x.

By the way, I believe that MLT needs some optimization when exporting to a file (I tried libdv and avformat).
When I play a video with inigo (for example, a wrestley XML that makes a edited video) it plays very smooth, and it only uses a 30% of CPU (and is displaying it with sdl).
In the other hand, I exported a rawvideo file and I encoded it with ffmpeg. Ffmpeg is encoding it at 60fps (and the video has 25fps)

So, I don't know why, when writting to a file, inigo spends a lot more of time than the needed (in my opinion).
The time needed for one minute would be: (In my PC AMD64, 720x576@25fps)
1. Time for decompressing, editing, text rendering, etc. About 20 seconds of CPU. (That's the CPU used by inigo when playing)
2. Time spended by avcodec (or ffmpeg) to recode it. About 30 seconds of CPU. (CPU used by ffmpeg for encoding a raw)
So, for one minute would be 50 seconds of CPU. (about 1.15x)
However, inigo spends 80 seconds for each encoded minute. No matter wich options are passed to libavcodec (I tried a lot of possibilities)

So, you're right, it's not a problem about being capable to encode faster than realtime; But i believe that there are something in the file-writting process that makes Inigo a 30% slower than the ideal (at 720x576@25fps)

I tried different values of buffer, threads, motionestimation method, .... without any visible effect. That loss seems to be proportional to the amount of raw data per second.

I have no idea on how MLT works internally, so it's possible that I've made a big mistake estimating the ideal CPU times. (And I'm using it from two days ago).

Hope that helps.

[Dan Dennedy]

OK, you might have a point. I ran a test of a simple file transcode against ffmpeg because ffmpeg does have titling, etc.
I have a 17.5 minute NTSC MPEG-2 at 528x480 [PAR 40:33 DAR 4:3].
$ time ffmpeg -i chap.ts -deinterlace -s 640x480 test.avi
...
real 12m44.605s

$ time inigo -profile square_ntsc chap.ts -consumer avformat:test.avi
"-profile square_ntsc" causes scaling to 640x480 just as -s 640x480 does in ffmpeg. It also indicates progressive, kicking on the deinterlacer for this interlaced source, equivalent to '-deinterlace' for ffmpeg.
...
real 9m26.752s

Wow, inigo is actually quite faster! I did not run anything else on my system during both tests except typical background processes. I attribute this speedup to the fact that inigo is multithreaded, and I am on dual core. Reading, decoding, deinterlacing, and scaling occurs in one thread, while encoding and writing is in another. ffmpeg can multithread some codecs, but it does not separate the read/decode and encode/write as MLT does. I did not use multithreading for codecs in either test. Next, I ran inigo without multithreading:

$ time inigo -profile square_ntsc chap.ts avformat:test.avi real_time=0
...
real 12m34.364s

hmm, still faster. Maybe the YUV scaler I implemented in MMX is faster that what's in ffmpeg.