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

ACTION-245: Implementation of Media Fragments from Dailymotion

From: RaphaŽl Troncy <raphael.troncy@eurecom.fr>
Date: Wed, 14 Dec 2011 13:49:13 +0100
Message-ID: <4EE89B49.20109@eurecom.fr>
To: Media Fragment <public-media-fragment@w3.org>
CC: Pierre Yves Kerembellec <pyke@dailymotion.com>
Dear all,

Regarding my ACTION-245, I engaged a conversation with some architects 
at Dailymotion, and this is the result of our findings:

1/ Partial implementation of Media Fragments URI in their flash player.

Currently, Dailymotion is able to parse URI such as 

Some explanations:
is a player page, i.e. an HTML page that contains a video to be played, 
in this case by a flash player;
   - A js script on this page is in charge to take the value of the 
parameters and gives instructions to the Flash player to start playing 
the video from the second 37 in this case (and stop playing at second 46);
   - The URI parsed expects to have NPT time codes.

Changes to be made to be compliant with our specification:
   - Dailymotion uses the query parameter (?) but is happy to do the 
same processing with a fragment parameter (#);
   - Dailymotion is happy to parse a URI scheme such as "t=a,b" rather 
than "start=a,end=b" and do a similar processing.

Bonus: if the player page is actually an HTML5 page containing a <video> 
element, then we imagine that the same js script propagates the media 
fragment URI to the @src attribute of this <video> element, instead of 
instructing a flash player to do so. In this case, a modern browser, 
such as Firefox 11, which is media fragments URI aware would do an 
adequate processing.

2/ Partial implementation of Media Fragments Recipes in their server.

Currently, Dailymotion has a partial implementation of the "Server 
mapped byte ranges" reciped described at 

For example, if you catch the requests made when putting in your browser 
this URL, 
you will see:


which triggers the request:

Host	proxy-56.dailymotion.com
User-Agent	Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0.1) Gecko/20100101 
Accept	text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language	en,en-us;q=0.8,fr;q=0.5,fr-fr;q=0.3
Accept-Encoding	gzip, deflate
Accept-Charset	ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection	keep-alive
Cookie		...

and the following response (200 OK) from the server:

Date	Wed, 14 Dec 2011 12:40:00 GMT
Server	Apache
Accept-Ranges	bytes, seconds
X-Accept-TimeURI	npt, smpte-24, smpte-24-drop, smpte-25, smpte-30, 
X-Edge-Version	1.7.3
Etag	9037352b189c963eb973e5bb93540867
Last-Modified	Tue, 06 Dec 2011 11:43:10 GMT
Content-Length	4784581
Connection	close
Content-Type	video/mp4

Changes to be made to be compliant with our specification:
   - A normal request is performed at the moment and a 200 OK answer is 
sent back because of the use of the query parameter. If the fragment 
would be used, then one could imagine doing a Range request with a 206 
Partial Content response.
   - The X-Accept-TimeURI header is used because Dailymotion has read 
but this has been dropped since.
   - The Content-Range and the Content-Range-Mapping headers are not yet 
provided in the answer but they could be added.

Please, let us know what do you think.
Best regards.


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, 14 December 2011 12:49:50 UTC

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