On 12-06-20 04:08 AM, Tobias Wunden wrote: > Hi Rüdiger, > > it seems that SMIL may indeed be a good fit for what we are looking for. One > question that came to mind is:
I dislike SMIL, mainly because it is a pain to work with. The time values are stored in an easy to read, but hard to work with format, and it's all in XML which makes it far more difficult to work with for things like JAXB. That being said, it's pretty much the only one that I've seen so unless we want to make our own it's probably the best bet. > Should we use the mediapackage's track id or even the track's flavor instead > of the filename? We may have different tracks in a mediapackage with the > given name, and it should be considered that it's not only the player that is > evaluating the SMIL instructions but also other services, for example those > that are creating reencoded versions of the video(s) based on the playlist. +1 to this. > Another thought (tying into the same topic) is that there may be institutions > that would like to pull in attachments as well (I remember Len from Harvard > talking about how they would like to pull up images of slides during video > playback that would most probably be attached to the mediapackage as > attachments). This again indicates to me that the mediapackage element id may > be a good thing to use rather than filenames. The problem with this is that it makes exporting the resulting video very difficult, especially if it's pulling up files which can't be displayed as video frames (eg: triggering a download of a pdf?). > I am looking forward to anyone's thoughts on this. FWIW, the toolkit that I have developed for this as part of my thesis is using a custom format (which I hadn't gotten back to Ruediger about). It's deliberately limited to the scope of my thesis, but if I get around to merging it back in at some point I will update it to work with whatever the group as a whole is using. G > Tobias > > On 18.06.2012, at 13:44, Ruediger Rolf <[email protected]> wrote: > >> Hi list, >> >> as we have encountered on the Harvard Un-Conference there are currently some >> groups working on video editing functions. The bandwith of the ideas that >> came up during the discussions was from compositions of video segments that >> are remixed in the browser, over services that re-encode the video based on >> the playlist up to streaming servers that exclude parts of the video without >> the player even knowing this. >> >> I feel the strong need that we agree on a common exchange format of the >> needed video edit list. From my point of view it would be the best to use an >> open standard for this and so SMIL 3.0 Tiny Profile [1] seems to be a good >> choice. >> >> As an example a "playlist" for a single stream video might look like this: >> >> <?xml version="1.0"?> >> <smil xmlns="http://www.w3.org/2001/SMIL20/Language";> >> <body> >> <seq> >> <video src="lecturer.mpg" clipBegin="00:01:44.360" >> clipEnd="00:04:06.720"/> >> <video src="lecturer.mpg" clipBegin="00:38:54.480" >> clipEnd="00:50:08.240"/> >> <video src="lecturer.mpg" clipBegin="00:59:56.640" >> clipEnd="01:13:51.720"/> >> <video src="lecturer.mpg" clipBegin="00:31:28.440" >> clipEnd="00:49:30.280"/> >> </seq> >> </body> >> </smil> >> >> >> If we have a dual stream video it might look like this: >> >> <?xml version="1.0"?> >> <smil xmlns="http://www.w3.org/2001/SMIL20/Language";> >> <body> >> <seq> >> <par> >> <video src="lecturer.mpg" clipBegin="00:01:44.360" >> clipEnd="00:04:06.720"/> >> <video src="vga.mpg" clipBegin="00:01:44.360" clipEnd="00:04:06.720"/> >> </par> >> <par> >> <video src="lecturer.mpg" clipBegin="00:38:54.480" >> clipEnd="00:50:08.240"/> >> <video src="vga.mpg" clipBegin="00:38:54.480" >> clipEnd="00:50:08.240"/> >> </par> >> <par> >> <video src="lecturer.mpg" clipBegin="00:59:56.640" >> clipEnd="01:13:51.720"/> >> <video src="vga.mpg" clipBegin="00:59:56.640" >> clipEnd="01:13:51.720"/> >> </par> >> <par> >> <video src="lecturer.mpg" clipBegin="00:31:28.440" >> clipEnd="00:49:30.280"/> >> <video src="vga.mpg" clipBegin="00:31:28.440" clipEnd="00:49:30.280"/> >> </par> >> </seq> >> </body> >> </smil> >> >> In general it might be useful to create a (REST)-service that delivers the >> SMIL file that the current service needs. So in the player we need one of >> the distribution copies (streaming or not), while we would need a link to >> the source files for a re-emcoding and we might need a link to the file in >> the file-system on the streaming server. >> Specialized output formats like simple JSON lists that the REST-endpoint >> creates might be a valid export format for the player too. >> >> So I'm open for comments on this issue. What do others think about this >> proposal? Are there alternative formats to SMIL that are worth considering? >> >> Regards >> Rüdiger >> >> [1] http://www.w3.org/TR/smil/smil-tiny-profile.html >> >> -- >> >> ________________________________________________ >> Rüdiger Rolf, M.A. >> Universität Osnabrück - Zentrum virtUOS >> Heger-Tor-Wall 12, 49069 Osnabrück >> Telefon: (0541) 969-6511 - Fax: (0541) 969-16511 >> E-Mail:[email protected] >> Internet:www.virtuos.uni-osnabrueck.de >> _______________________________________________ >> Matterhorn mailing list >> [email protected] >> http://lists.opencastproject.org/mailman/listinfo/matterhorn >> >> >> To unsubscribe please email >> [email protected] >> _______________________________________________ > > _______________________________________________ > Matterhorn mailing list > [email protected] > http://lists.opencastproject.org/mailman/listinfo/matterhorn > > > To unsubscribe please email > [email protected] > _______________________________________________
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
