That seems a very elegant approach to me. 2012/6/20 Tobias Wunden <[email protected]>
> Hi Judy, > > that's a valid concern! Maybe we can take the approach of adding a new xml > nespace andnin addition to the url add an atribute for the id: > > <video src="url.mp4" mh:element="975-5393-..." ... > > Tobias > > On 20.06.2012, at 18:59, Judy Stern <[email protected]> wrote: > > 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] > _______________________________________________ > > > _______________________________________________ > 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] _______________________________________________
