W3C home > Mailing lists > Public > public-media-fragment@w3.org > December 2010

Re: ACTION-202: draft the paragraph that the group will propose to HTML5 regarding how the control of media fragment URI should be done

From: RaphaŽl Troncy <raphael.troncy@eurecom.fr>
Date: Wed, 08 Dec 2010 10:00:15 +0100
Message-ID: <4CFF491F.30701@eurecom.fr>
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
CC: Media Fragment <public-media-fragment@w3.org>
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?


> (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 

> (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 :-)

> 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?


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 09:04:01 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:45 UTC