This might be due to your libavcodec detecting number of CPUs for
multi-threaded decoding, and it might be specific to this version (or some
range of versions).

On Tue, Apr 28, 2015 at 8:37 AM Javier Matas <javier.ma...@yump.com> wrote:

> I tried many combinations and similar options but it didn't work. It
> always generates X repeated frames if I execute it in a X-core machine.
>
> Thank you anyway!
>
>
>
> 2015-04-28 15:43 GMT+02:00 Brian Matherly <c...@brianmatherly.com>:
>
>>
>> http://www.mltframework.org/bin/view/MLT/Questions#Does_MLT_take_advantage_of_multi
>>
>> Instead of real_time=0, try real_time=-1. On your 8-core machine, you
>> might try real_time=-8. The negative number indicates that frame dropping
>> is disabled.
>>
>> The real_time property changes the MLT consumer behavior. You might also
>> want to try tweaking the libx264 threading behavior. You do that by setting:
>>     x264opts="threads=1"
>>
>> ~Brian
>>
>>   ------------------------------
>>  *From:* Javier Matas <javier.ma...@yump.com>
>> *To:* Dan Dennedy <d...@dennedy.org>
>> *Cc:* mlt-devel@lists.sourceforge.net
>> *Sent:* Tuesday, April 28, 2015 4:47 AM
>> *Subject:* Re: [Mlt-devel] Repeated frames with melt
>>
>>
>> Another question, is there any option in melt config to execute this
>> command in just one core?
>>
>> The commands of threads and slices seem to do nothing for us. I've proven
>> this command on melt 0.8.0 and 0.9.0 and got no difference (8 frames
>> repeated in a 8-core machine):
>>
>> melt -provider in.mov -consumer avformat:out.mp4 vcodec=libx264 an=1
>> preset=ultrafast vb=2M qmin=10 qmax=22 me_method=hex g=120 threads=0
>> slices=0 cpu-used=1 real_time=0
>>
>> Thank you.
>>
>>
>>
>>
>> 2015-04-28 10:53 GMT+02:00 Javier Matas <javier.ma...@yump.com>:
>>
>> Hello, problem solved!!
>>
>> We executed that melt command in a machine with only 1 core and it
>> worked. We've realized that if we execute it on a machine with 2 cores, 2
>> frames were repeated. In a machine with 4 cores...4 frames were repeated,
>> ....
>>
>> I don't know if it's a bug of melt multithreading, but it only works for
>> us in that case. Machines with one core are the key.
>>
>> Thank you.
>>
>> 2015-04-27 21:25 GMT+02:00 Dan Dennedy <d...@dennedy.org>:
>>
>>
>> On Mon, Apr 27, 2015 at 10:34 AM Javier Matas <javier.ma...@yump.com>
>> wrote:
>>
>> Hello,
>>
>> We are using melt in order to build videos from .mov fragments, and when
>> we process the fragments, we realize that the output videos have around 10
>> repeated frames at the beginning.
>>
>> The melt command we use is:
>>
>> melt -provider in.mov -consumer avformat:out.mp4 vcodec=libx264 an=1
>> preset=ultrafast vb=2M qmin=10 qmax=22 me_method=hex g=120 threads=4
>> slices=4
>>
>> And its console output is:
>>
>> libdc1394 error: Failed to initialize libdc1394
>> No LADSPA plugins were found!
>>
>> Check your LADSPA_PATH environment variable.
>> [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f14c88d16a0] max_analyze_duration reached
>> [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f14c8988600] max_analyze_duration reached
>> [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f14c8da2900] max_analyze_duration reached
>> [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f14c88e6820] max_analyze_duration reached
>> [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f14c88e0cc0] max_analyze_duration reached
>> [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f14c899e240] max_analyze_duration reached
>> [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f14c88c1ea0] max_analyze_duration reached
>> [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f14c88c9fc0] max_analyze_duration reached
>> [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f14c8da0fe0] max_analyze_duration reached
>> +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
>> |1=-10| |2= -5| |3= -2| |4= -1| |5=  0| |6=  1| |7=  2| |8=  5| |9= 10|
>> +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
>> +---------------------------------------------------------------------+
>> |               H = back 1 minute,  L = forward 1 minute              |
>> |                 h = previous frame,  l = next frame                 |
>> |           g = start of clip, j = next clip, k = previous clip       |
>> |                0 = restart, q = quit, space = play                  |
>> +---------------------------------------------------------------------+
>> [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f14c94cd880] max_analyze_duration reached
>> [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f14c94d31e0] max_analyze_duration reached
>> [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f14c94ce960] max_analyze_duration reached
>> [libx264 @ 0x7f14c98b8a20] lookaheadless mb-tree requires intra refresh
>> or infinite keyint
>> Current Position:        488
>>
>>
>> Tho OSs we use are debian 7 and ubuntu 14.04, and we've realized that the
>> number of repeated frames depends only on the machine in which we're
>> executing it (from 5 to 12). This causes annoying stops in the videos.
>>
>> Our theory is that the architecture of the machine has a lot to do with
>> these problems, but trying to do the fine tuning with threads, slices and
>> other parameters like thread_type or real_time is proving useless.
>>
>> We usually run this command from a Docker with debian 7 and melt 0.8.0,
>> but as I said before, the OS and the melt version don't matter because in
>> each machine we always have the same number of repeated frames, and this
>> number is only different among different host machines.
>>
>> Thank you very much.
>>
>>
>> I do not understand how or why different hosts running the same code will
>> produce different numbers of repeated frames for the same input. However,
>> Debian 7 and Ubuntu 14.04 probably have different versions of
>> libavformat/libavcodec, and melt v0.8.0 is quite old.
>>
>> I recommend that you try one of these clips in Shotcut on your desktop.
>> You can see if reproduces by stepping frame-by-frame in the player from the
>> beginning of the clip, by encoding the clip as H.264 within Shotcut, or by
>> using the melt that comes with Shotcut. (If using Linux, you must use the
>> wrapper script at Shotcut.app/melt instead of running Shotcut.app/bin/melt
>> directly.)
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> One dashboard for servers and applications across Physical-Virtual-Cloud
>> Widest out-of-the-box monitoring support with 50+ applications
>> Performance metrics, stats and reports that give you Actionable Insights
>> Deep dive visibility with transaction tracing using APM Insight.
>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>>
>> _______________________________________________
>> Mlt-devel mailing list
>> Mlt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mlt-devel
>>
>>
>>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Mlt-devel mailing list
> Mlt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mlt-devel
>
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel

Reply via email to