Using "real_time" and "threads" options should not change the final result -
unless you happen to expose a bug. It should not matter if you use one, the
other or in combination.
In my own experience, if I have an EDL that only has a few filters/transitions
and I am encoding to H.264, I only need to set "threads=4" and I can pretty
much saturate my CPU. Basically, one core ends up doing all the decoding and
MLT processing and the rest of the cores get used up for encoding.
~Brian
From: jeffrey k eliasen <j...@jke.net>
To: Brian Matherly <c...@brianmatherly.com>
Cc: "mlt-devel@lists.sourceforge.net" <mlt-devel@lists.sourceforge.net>
Sent: Friday, June 17, 2016 3:28 AM
Subject: Re: [Mlt-devel] Optimizing `melt` in a CPU-intensive environment
OK, that's exactly what I was looking for, thanks!
Looks like I also had a typo in an earlier reply, using ':' instead of '=' to
denote a property value, that took longer than it should have to recognize.
Finally, you mention the real_time and threads options can be combined, but
does this change the final result in any way vs. using just one or the other
(assuming I'm not dropping frames)?
#yiv6254521583 .yiv6254521583ExternalClass * {line-height:100%;}
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://sdm.link/zohomanageengine
_______________________________________________
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel
