Thanks for the response Dan, see inline.
On 4/30/2014 11:55 AM, Dan Dennedy wrote:
On Wed, Apr 30, 2014 at 10:19 AM, Dan Dennedy <d...@dennedy.org
<mailto:d...@dennedy.org>> wrote:
Why not simple math?
200 - 120 = 80
qmelt 1.mov out=80 -blank 120 -consumer ...
yields, actually, 202 frames because out points are frame numbers
(or time value), which are are 0-based and not durations.
Therefore, out=80 is a duration of 81 frames. Thus, to really get
200 frames you need to do:
qmelt 1.mov out=79 -blank 119 -consumer ...
I didn't realize it was 0 based, makes sense though, thanks. Are you
also saying that it can take a time value? I didn't know that, what is
the format of the time value the out and in properties can take?
In the long run we should be able to do the math. Right now we don't
have anything which will easily give us the number of frames, or time
length, of the video we are using in the construction. I'm basically
trying to cheat for demo purposes but limiting the final video size was
also going to be a feature. It is looking like that would be difficult
only dealing with command line generation from everything you have
indicated.
The framework and modules, by design, do not provide much in the
way of authoring as much as they simply facilitate it. You need to
make your own layer that generates the composition as melt command
lines, MLT XML, or by custom program using the API.
Right now I have a DSL builder in Java which makes creating the complex
command lines easy. I know it probably isn't the correct solution for
the long run, but so far it has been the quickest to prove out for 90%
of what we have to do.
Now, with that said, and with your claim that you just need a simple
way to limit the number of frames in the output, if the consumer
honored an out property or melt let you target the track or tractor
properties, then you could accomplish that. I am just not sure how you
want to determine the length of the video clip vs. the number of blank
frames.
For the demo these are hard coded and passed to the builder directly.
Ultimately I need the clip's meta information and the immediate need for
limiting the output will be gone. I wanted the size of the clips, in
the demo, not to matter but it looks like I will need to do the math
ahead of time and pass out parameters for each clip.
melt 1.mov -blank 119 -consumer xml:test.mlt no_meta=1
edit test.mlt so that playlist out=199
melt test.mlt -consumer avformat:demo.mp4
So, the solution may be to generate MLT XML, perhaps with a template
engine, instead of complex melt command lines. You can even put a
consumer element into the XML:
<consumer mlt_service="avformat" target="demo.mp4"/>
Add any other encoding properties as XML attributes.
Yes, I think this is essentially where we will end up as soon as we
can't exploit the command line directly for a requirement. I would
start there, but we probably don't have time to create and test the xml
generator before release.
Thanks,
James
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos. Get
unparalleled scalability from the best Selenium testing platform available.
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel
