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>
