[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-multimedia
Subject:    Introducing MLT
From:       Charles Yates <charles.yates () pandora ! be>
Date:       2004-04-04 7:29:46
Message-ID: 1081063786.29843.2340.camel () desire ! dreaming
[Download RAW message or body]

Hi all,

I was talking to a KDE developer on IRC yesterday, and he suggested that
I wrote a quick mail introducing the multimedia framework that myself
and Dan Dennedy have been putting together over the past few months.
Blame markey for inviting this over long and shameless plug ;-).

The MLT project was commissioned by the largest satellite TV broadcaster
in India and was spec'd to provide real time fx processing and
broadcasting capabilities for use in their news programming.

Currently, they have been nice enough to allow the project to be
licensed under the GPL and they (UEL) are the license holders.

You can find more details about it at: http://mlt.sf.net

Current code is from CVS only - there should be a tarball available by
Wednesday.

The current plugin set features support for (most of) the a/v formats
supported by the current ffmpeg libavformat cvs, uses gdkpixbuf for
image loading, pango for text, libvorbis for ogg, a host of filters,
multitrack support, associated transitions, playout/rendering components
provided via sdl and you can (probably) render most stuff via avformat
or libdv too. 

The concentration has been on variable latency realtime playback (high
for broadcasting, low for previewing) and optional non-realtime for
rendering to mpeg, dv or whatever (the distinction being that realtime
will allow frame drops, while non-realtime won't). 

Frame accuracy and efficient rendering of FX have also been high on the
agenda, as has been the provision of an XML authoring sub-system and the
broadcasting components themselves.

Couple of caveats and gotchas though....

First off, the professional system uses closed source codecs which we
can't provide under the GPL (mpeg and DV codecs and file handlers coming
from mainconcept) - the support for these formats with avformat varies
from adequate to inadequate, but are largely functional. ffmpeg/avformat
has been coming along in leaps and bounds over the past few months, and
I don't expect this to be a long term issue.

Second, broadcasting environments need 'normalised' content - which
means scaled images, resampled audio and framerate fixing - we have
comprehensive support for PAL and rudimentary, partially tested support
for NTSC. You can override the scaling requirement with SDL, but the
other issues won't be so easily circumvented in the current code base.

As a knock on effect from that, seeking accuracy is restricted to 1/25th
or 1/29.97th of a second for both audio and video sources (which isn't
ideal for audio usage and stems from the customers preference of frame
based units throughout the system).

Last point is that there is a limit to how much two developers can do in
a 4 month period, and some decisions made for the sake of the tight
deadlines involved may not sit well with all.

Main point to stress - to get much of anything out of the system, you
will need to use libavformat from ffmpeg CVS (details can be found at
http://ffmpeg.sf.net) and this must be configured and installed with
--enable-shared. You'll probably need libdv CVS too
(http://www.sf.net/projects/libdv) and for resampling, we use
libsamplerate from http://www.mega-nerd.com/SRC/. Plug-ins can be
disabled if required.

Anyway, with the project now close to conforming to spec, both Dan and I
are keen to extend it for more robust and reliable use with a truly OSS
codebase.

If you've got this far, I've already taken up more of your time than I
should have - thanks, and you have my condolences :-).

Cheers,

Charlie



_______________________________________________
kde-multimedia mailing list
kde-multimedia@kde.org
https://mail.kde.org/mailman/listinfo/kde-multimedia
[prev in list] [next in list] [prev in thread] [next in thread]