[Kdenlive-devel] mlt in kdenlive
dan at dennedy.org
Tue Oct 18 05:20:32 UTC 2005
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
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 :-/
More information about the Kdenlive