Re: [Mlt-devel] jack, lua

[Dan D. <da...@de...>]

On Sat, Aug 28, 2010 at 3:25 AM, Philipp Überbacher
<hol...@la...> wrote:
> Excerpts from Dan Dennedy's message of 2010-08-28 02:27:16 +0200:
>> On Fri, Aug 27, 2010 at 3:11 AM, Philipp <hol...@la...> wrote:
>> > Hi,
>> > I read that MLT has jack support and lua bindings, the question is, to
>> > what degree?
>> >
>> > I wonder how feasible it would be to use MLT as backend for something
>> > like a DAW, but before I dive deeper into the MLT documentation I think
>> > it's a good idea to ask a couple of questions.
>> >
>> > 1) Can everything be done from lua?
>>
>> MLT event handlers are not available - requires additional work on
>> swig bindings. However, MLT events are not heavily used. For example,
>> see OpenShot; it does not yet require any events.
>
> Hi Dan,
> thanks for the answer.
> I don't think that MLT at this time is suitable for what I had in mind.
>
> I had a look at openshot, looks nice and simple, and I heard it gets the job
> done reliably. No events yet doesn't seem to be a show stopper.
>
>> > 2) Is it possible to record with MLT using jack?
>>
>> Jack is implemented as a MLT audio filter where the sends and receives
>> are optional. So, you can receive only. Also, another instance of the
>> filter could send only for Jack output. If you use both, then it truly
>> acts as a filter - e.g. sending through Jack Rack and receiving the
>> results.
>
> Ok, if I understood that correctly. The filter part is a bit confusing.
> I started to read the documentation: producer -> filter -> consumer.
> Usually with jack you have in_ports -> do_something -> out_ports.

Sorry, my point was that jack is flexible and so is MLT with respect
to Jack.  It is where the filter is placed in MLT and how the ports
are connected to other jack clients that determines what you can do.

>> > 3) How does jack in MLT behave? Does it stuff like automatic
>> > connection/disconnection in some cases?
>>
>> You can set properties on the MLT filter to tell it to setup
>> connections. Stereo only at the moment, I believe.
>
> It's usually not a good idea when a program automatically connects or
> disconnects from jack, but I guess it's at the programmers discretion,
> so it's available for the rare cases where it is wanted.

Yes, MLT always registers input and output ports, but does not connect
them to another client unless the app developer or user chooses to.

> Stereo only is a limitation.

I take this back. It does support an arbitrary number of channels.

>> > 4) Does it support jack transport, and to which degree?
>>
>> No. MLT filters should not try to affect the position or transport.
>> The application which uses MLT should implement that.
>
> Ok, this is a bit problematic since jack transport and other things work
> through the API afaik.

I do not understand. Are you saying you need MLT to do it because you
do not have lua bindings to the Jack API?

>> > 5) How does it behave in low latency situations?
>>
>> I do not think well; no special care has been taken, e.g. avoid memory
>> allocations during audio filter chain processing. The Jack support was
>> initially added to support _prototyping_ a Jack Rack setup, which you
>> can save to a file. Then, for production-oriented running, you would
>> supply the jackrack XML file, which is processed as a stack of LADSPA
>> filters instead of routing through Jack. That was the workflow that
>> inspired the original implementation, at least. It is not necessarily
>> limited to that, but I think it needs testing and improvement for
>> general usage.
>>
>> I think another issue is that MLT does not provide audio sample level
>> precision for audio editing operations. There is always a frame
>> whether there is video or not (dummy video is generated). The number
>> of audio samples for the duration of the frame (e.g. 40ms for 25 fps)
>> is stored on each frame object that propagates through the system.
>> With that said, if someone wants to try to improve it, I am not
>> opposed.
>
> Those would be rather big problems for my purpose. I quite simply don't

I agree.

> have the skills yet to make the required changes to MLT.

I understand.

> As said before, I heard openshot gets
> the video job done reliably, and that's most important, so you seem to
> be on a good track. I wish you best of luck with MLT.
>
> Regards,
> --
> Philipp
>
> --
> "Wir stehen selbst enttäuscht und sehn betroffen / Den Vorhang zu
> und alle Fragen offen." Bertolt Brecht, Der gute Mensch von Sezuan
>
>
-- 
+-DRD-+