Re: [Kdenlive-devel] mlt in kdenlive

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

On Monday 17 October 2005 10:06 am, marco wrote:
> Hi dan dennedy

Hi, before going much further... I hope you guys are using MLT from CVS HEAD 
and not an outdated release tarball?!

> can you give me a short desc. for valerie and miracle.
> i want to know can we use it in the video editor ?
> can it (miracle) be used as a "media holder" for the files , or is it only
> for playing a file or list of files ?.

Miracle(Max) is an execution engine that features multiple, distinct 
processing units and a handy protocol (DVCP). It was a core requirement for 
the company that funded its development because "video servers" are now a 
commonplace item in a broadcast facility. Valerie is a library to make usage 
of the control protocol more convenient. The protocol can be simply in-memory 
string passing or remoted via TCP/IP--this is where it is convenient to the 
physical layout of broadcast facilities.

I know this description is rather vague, but I think there is quite a bit of 
flexibility there to be applied in creative ways to interesting problems. 
These client/server and DVCP protocol capabilities are also rather easy to 
embed into custom applications. One can study shotcut in MLT CVS for an 
example. 

Finally, for most purposes, miracle is simply a playback video server, but it 
also contains the processing features of a non-linear editor because of the 
MLT framework. However, at this time, it does not provide an RPC interface to 
MLT, which is something Charlie and I have discussed.

> and what is the difference to valeire, it seem to me it makes nearly the
> same then mircale.

Valerie completents Miracle(Max) by providing a client programming interface 
so your code does not need to work directly with protocol at the string 
level. Valerie makes programming a client easy.

> best would be that miracle or valerie can hold a westley-xml file that can
> be edited, and loads all files, so we dont need to reopen it for every use.

MLT is stateful and holds an object model of the authored project. I am glad 
we are having this discussion; I wanted to get to it soon. Previously , Jason 
Wood and I had discussed whether it is more beneficial to maintain a 
in-memory document model (DOM) inside the editing tool separate from the 
processing engine. Jason argued for it. However, I think it is unnecessarily 
redundant. MLT has quite a nice document object model and manipulation 
routines.Charlie has been enhancing them as he worked on Shotcut and now 
Jahshaka. This means much of the low level track and playlist management is 
in MLT now.

I worry about the interactive capabilities and compatibility issues that may 
arise if kdenlive tries to maintain its own DOM and simply communicate with 
MLT via westley documents. I see two ways for kdenlive to approach MLT. One 
is to extend Miracle with RPC to access the MLT framework. Another approach 
is to just code the editor to directly use the framework and perhaps provide 
the capability to send the project to a miracle server via a westley 
document. I think the latter approach is easiest to start with and when RPC 
becomes available, it should to be easy to adopt through a proxy 
library--similar to how valerie complements miracle today .

Also, some thought should be given as to how to use a miracle as a render node 
and make it transparent.

> or would it possible to let miracle/valerie act as a producer for the files
> ?

I think are you refering to westley files here?
Miracle and Valerie are simply applications that use the MLT framework and 
expose its power just as the inigo tool does. Inigo is command line, 
miracle/valerie are client/server with a control protocol. Each provides a 
unique interface, but none is interactive graphical editing tool. Since none 
of these applications provide a direct enough interface to MLT, they do not 
make much sense to use for the producer of the files since they provide 
little DOM manipulation.

MLT, the framework, serialises and deserialises its DOM as westley. As such, 
it is the reference implementation for how to do this and for the precise 
semantics of westley. It seems to me that a separate implementation inside of 
kdenlive unecessarily risks compatibility issues and duplication of effort 
when the power already lies within MLT.

I hope I have not thoroughly confused you :-/