- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Wed, 8 Dec 2010 21:22:35 +1100
- To: Raphaël Troncy <raphael.troncy@eurecom.fr>
- Cc: Media Fragment <public-media-fragment@w3.org>
Sent from airport :) Sent from my iPhone On 08/12/2010, at 8:00 PM, Raphaël Troncy <raphael.troncy@eurecom.fr> wrote: > Dear Silvia, > > Thanks for this text. I do have some minor comments inlined. > >> (1) Temporal Media Fragments >> >> As per: http://www.w3.org/TR/media-frags/#naming-time >> >> Relevant to: audio& video >> >> Recommended approach to support temporal media fragments: byte range >> requests, see http://www.w3.org/TR/media-frags/#URIfragment-user-agent >> >> Two uses: >> >> 1. URL in address bar >> >> When a media fragment URL is pasted into a Web browser address bar and >> the browser is able to decode the media resource, the user should see >> a video or audio file that starts playing from the fragment start time >> and stops at end time. Also, since the browser will display controls, >> we need to introduce markers on the controls for the fragment, see >> http://www.youtube.com/watch?v=LfRRYp6mnu0 for an example >> implementation. >> >> The means towards interpreting the fragment should be by starting to >> download the resource, then, as it is confirmed that it is a media >> resource, download will stop and byte range requests will be applied. > > Should we precise here the two sub-cases: > - the container format is fully indexable (e.g. MP4, Ogg or WebM) and the UA is able to issue normal byte ranges requests by itself; > - the container format is not indexable (e.g. AVI) and the UA can issue range requests expressed in seconds and ask for help to a media fragment compliant server to tell the UA what is the mapping between the seconds and byte ranges > > Or do you think it goes too much into details? Nothing to do with detail. The only codecs supported by web browsers are ones that do byte ranges. So, no, no need to mention it. > > [snip] > >> (2) Spatial Media Fragments >> >> As per: http://www.w3.org/TR/media-frags/#naming-space >> >> Relevant to: images& video >> >> Recommended approach to support spatial media fragments: CSS-like, >> i.e. hide unwanted pixels >> >> A spatial media fragment URI can be used in the URL address bar or in >> the @src attribute of video/img element. >> >> The user will expect a cropped (spliced) image/video display of the resource. > > Naive question: is it easy for a client to perform cropping on an entire video? > They do it easily with CSS. I don't think it would be hard. >> (3) Track Fragments >> >> As per: http://www.w3.org/TR/media-frags/#naming-track >> >> Relevant to: audio& video >> >> Recommended approach to support track fragments: hide unwanted tracks >> >> A track media fragment URI can be used in the URL address bar or in >> @src attribute of video/img element. One example use case has been >> shown at https://labs.ericsson.com/developer-community/blog/beyond-html5-conversational-voice-and-video-implemented-webkit-gtk > > You meant video/audio for track, not img :-) Yup. > >> The user will expect that only the enumerated tracks (audio, video >> etc) will be displayed. > > Yes. Should we also talk about combination of those dimensions? > We can ... Though it seems fairly obvious. S. > Raphaël > > -- > Raphaël Troncy > EURECOM, Multimedia Communications Department > 2229, route des Crêtes, 06560 Sophia Antipolis, France. > e-mail: raphael.troncy@eurecom.fr & raphael.troncy@gmail.com > Tel: +33 (0)4 - 9300 8242 > Fax: +33 (0)4 - 9000 8200 > Web: http://www.eurecom.fr/~troncy/
Received on Wednesday, 8 December 2010 10:23:07 UTC