[Kdenlive-devel] XML representation for effects.

Mon Mar 8 15:11:04 UTC 2004

On Mon, 2004-03-08 at 11:43, Jason Wood wrote:
> On Sunday 07 March 2004 17:08, Rolf Dubitzky wrote:
> >
> > If you look into a kino file, you find that each input is wrapped in a
> > seperate <seq> tag. As far as I understand SMIL, this is not necessary.
> > Actually the <seq> tags should go into a <body> tag to make valid SMIL.
> > (You can even skip the <seq> tag alltogether, since <body> is a special
> > form of <seq> without parameters. But that is not our prolem.
> 
> I'm not sure about putting multiple things inside a single seq tag, but maybe 
> it is just me (I just find the kino way of using seq tags easier to 
> visualize). But I am happy to go with this if it is correct SMIL.

seq = sequential time container
par = parallel time container
It is that simple, and they can be arbitrarily nested along with media
objects. Kino puts everything inside a seq because the UI treats
everything as a "scene" abstraction. Therefore, when a clip is added, it
is by default as scene, but eventually it could be combined with other
clips within a "scene" (=seq).

> > I think this proposal is pretty close to SMIL and is still pretty easy to
> > implement and can do everything we need.
> >
> > What do you think? Did I miss something? These are alot of changes, but I
> > guess it's better to make them all at once and make kdenlive and piave talk
> > to each other again asap.
> 
> No, looks fine to me. I would appreciate any comments from Dan if he has any 
> though :-)

Sigh, now for some troubling news :-/. After all my trumpeting, we might
abandon SMIL. I think you already know--at least Jason--that we were
contracted to develop a new video playout server that can all do all
sorts of realtime effects and output uncompressed over SDI. We could not
use piave because the customer wanted a pure C implementation with the
option to license the core framework BSD. The license issue as well as
other factors ruled out consideration of other things like gstreamer or
xine as well. Therefore, we created yet another new media framework. 

Frankly, I feel what the two of us have accomplished in 3 months rather
astonishing; however, we were paid to work on it fulltime and our
survival instincts have caused us to overwork ;-). I implemented XML
serialisation and deserialisation of the state of the "service network"
(our analogous term for "filter graph") in a fashion that is very
immediate to the implementation. I did this intentionally for
performance and debugging reasons (KISS).

Now, as we evaluate Kino integration, we wonder if it makes sense to
maintain a document state and implementation separate from the state of
the service network and its serialisation syntax? FWIW, I think we have
the basis of a good SMIL player engine and I may end up implementation a
SMIL deserialiser as well. 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20040308/b19c7e34/attachment.sig>