Forgive the technical naivete of this question, but (although I see the advantages of using mediapackage ids) if we switch to using mediapackage id's, do we not lose the universality of the SMIL format? Seems to me that one advantage of using SMIL is that other players (that know nothing of matterhorn mediapackages) could make use of our "playlists". Again, apologies if you see this as a silly or irrelevant concern...it just jumped out at me.
Judy p.s. Of course, once mediapackages themselves become a universal standard for storing videos, as Pawel suggests in a different thread, there's nothing to worry about, right?;-) On Jun 20, 2012, at 3: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: > > 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. > > 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. > > I am looking forward to anyone's thoughts on this. > > 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] > _______________________________________________ _______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
