[annodex-dev] sequence description list question
silviapfeiffer1 at gmail.com
Thu Jul 24 17:31:09 PDT 2008
On Thu, Jul 24, 2008 at 5:21 AM, Zohar Babin <zohar.babin at kaltura.com> wrote:
> The current Kaltura SDL can is described (partially) here:
Thanks. As I look at that, I can't help to wonder if you are doing
video (and video sequences) or if you are really doing multimedia
presentations. As soon as you put together images, effects,
transitions etc. you end up in a situation where indeed SMIL would be
appropriate. However, it depends on how far away from the "linear
video" concept you are going whether SMIL is appropriate for you.
> One of the main things that is solved by using ROE in the location tag
> is multiple streams for the same video/audio file (ie, ogg/flv/avi/3gp..
> versions or Spanish/English/Chinese... languages).
ROE is appropriate where you are just talking about a video and all
the documents that go around a video: audio track, audio tracks with
different languages, annotations for the video, captions, a ticker,
text overlays, logo watermarks (e.g.
different video angles etc. But it is not appropriate when you want to
describe a random multimedia presentation where the timeline does not
go linear from time t0 to time tn.
> By basing the SDL on an extended version of xspf we can achieve a
> standardized format of describing a sequence while also maintaining an
> "open for extensions" and robust xml description of the sequences.
> I think there are 2 main topics that xspf specs lack to be able to
> support Kaltura sequences like representations:
> 1. Multiple tracks (of audio/video/overlas etc.) (what's the reason for
> xspf to force only one tracklist?).
XSPF is a playlist format. It describes playlists of media files.
Where a media file has multitracks, it will take them. But it does not
enable you to describe these.
If you wanted that, maybe you need to create a xspf playlist of ROE files?
> 2. Support of arbitrary plugins with plugin specific saved data - each
> plugin can be implemented in different ways, just like a video can be
> encoded in different codecs. It's saved data should be free and open to
> be represented in any way the plugin developer chooses (ie, if it's
> binary use CDATA).
You want to specify the plugins in XML? Plugins are code, right? So
why not leave that outside the format specification? It's been good
practice in my experience to keep data formats separate from their
presentation description. I may misunderstand however what your
plugins are, so maybe describe a few examples?
More information about the annodex-dev