Introducing MLT

Charles Yates charles.yates at pandora.be
Mon Apr 5 13:38:49 BST 2004


Hi Ronald,

On Sun, 2004-04-04 at 21:08, Ronald S. Bultje wrote:
> Hi Charles (& Dan),
> 
> On Sun, 2004-04-04 at 03:29, Charles Yates wrote:
> [..]
> 
> The standard question: given your goals and implementation similarities
> to existing frameworks, why did you choose to write a new one from
> scratch? The company that I work for happily uses the GStreamer
> framework for all of our video effects, mostly because it reduces costs
> (framework is there already, so I didn't have to spend a year of
> manhours in writing a new one) compared to re-creating our own. Also,
> LGPL is favoured over GPL here (but that's not a company policy but a
> developer [=me] policy). Apart from that, I see little differences.

Well, we did consider gstreamer, NMM and xinelib for the project at the
beginning. 

There were a number of factors that we felt, perhaps wrongly, counted
against them. In the case of gstreamer, I guess I would (verbosely :-))
summarise our thoughts as follows:

1. we had a spec from our customer which didn't tally with the current
functionality provided by gstreamer - to provide some of the features,
we would have to go deep into the (not insignificant) gstreamer code
base - we felt this would take us too long, and was too risky given the
customers insistence on a quick turnaround (well, they always insist on
that, right? ;-)). 

2. in order for us to ensure compatability with gstreamers functionality
and our customers requirements, both myself and Dan would have to become
very active players in gstreamer's ongoing development - aside from the
time loss required to become proficient in the gstreamer project, being
new players in an existing large team puts us (and our customer) at a
huge disadvantage - there is always inertia present in any large
project. I object to forking as a general rule, but the size of the code
base made that impractical anyway.

3. gstreamer seems to be in a state of flux and seems to change APIs and
structure quite frequently (at least, that is the perceived view) - we
felt it was too risky (and unprofessional) to provide a solution which
would involve modification, no matter how infrequently, to meet the
requirements of another projects API (obviously, we can't avoid that in
the plug-ins, but that's a different issue - changes there don't or
shouldn't affect his integration with the MLT API). Regardless of the
veracity of this statement wrt your project in the future, we considered
it an unacceptable risk.

4. customers insistence on minimal dependencies, optimised throughput
(essentially targeting SDI hardware for output) and simplicity of design
where also guiding factors.

(Note that point 3 is one of the main reasons that induced the customer
to steer clear of development in Windows and MS APIs in the first
place...).

I would add that the MLT framework has been relatively stable since the
first month of the project - there have been tweaks here and there of
course, but the core has changed little. Obviously, we would have
benefited from the existing gstreamer implementations, but, to be
honest, other than the potential overlap with FX, there was little else
in common (closed source codecs for input, closed source outputs).

Our goal was not to compete with the gstreamer project - we simply felt
that we needed to take an alternative approach.

I have discussed my attitude to OSS frameworks previously in the
linux-graphics-dev mailing list (see the 'Video plugin format?' thread)
- in there I stated that one ruling framework is not necessarily the
most desirable solution. Different solutions for different tasks work
well, especially if you can interchange freely between them. 

Ideally, I would love it if your 'services' (or a subset) could be
loosely integrated and selectable from our API, just as our services
would be exposed through yours (from an application developers point of
view, you choose an API which you feel comfortable with, but you're not
restricted [much] in what's available to you...).

Just to clarify, since it might not be immediately obvious to all -
consider our XML format [westley] - people could author via westley (by
hand, or using an mlt application or whatever) and load directly into a
gstreamer app... just as a serialised form of your graphs could be
loaded into an mlt application. 

> And the obvious second question: how does it compare to GStreamer? :).

Heh - well, it has a different scope - it would perhaps be fairer to
compare it with the gnonlin sub project. 

It is a deliberately TV/broadcast oriented and tailored solution -
obviously, it overlaps with gstreamer in functionality, but it isn't
gstreamer :-). 

Could it be used as a general framework? Probably, with adaptation of
course. Will it be? I don't know - personally, I'm more interested in
the market for which it was developed. Others might not see it that way
though.

(Sorry for all the [parenthesis] ;-)).

Cheers,

Charlie



More information about the kde-multimedia mailing list