- From: Raphaël Troncy <Raphael.Troncy@cwi.nl>
- Date: Wed, 09 Sep 2009 13:56:54 +0200
- To: Yves Lafon <ylafon@w3.org>
- CC: public-media-fragment@w3.org
Hi Yves, > I has two ideas for solving this one. > The first one is very straighforward and reuse the units we already > defined: > Range: npt=12:23.2s-13 > Range: smpte-30-drop=1:22:33-2:33:44 > > ie: Range: <timeformat> '=' <start time> - <end time> > > And the same logic for Content-Range: > > Content-Range: npt 12:22.5-13.01/25.1 > Content-Range: smpte-30-drop 1:22:33-2:33:44.1/4:00:00 > > ie: Content-Range: <timeformat> ' ' <real start time> '-' <real end time> > '/' <total duration> > > Note that the use of '=' and ' ' is aligned with the Byte range definition. I like very much this option. As you said, this is aligned with a current Byte range request. > The other option would be to say that it's a time unit, and precise the > unit later: > > Range: time=npt:12:22.7-npt:13 > => > Content-Range: time=npt:12:22.5-npt:13.01/npt:25.1 > > This one has the advantage of being more flexible, but less robust to > the introduction of new units (as they can't be advertised using > Accept-Ranges). With this option, one could then express a Range request, for example, for a time interval where the start time would be expressed in npt and the end time in smpte-30. Is this what you call 'flexibility'? I'm afraid that it also adds extra-complexity which is not really required. As you say, this solution has also the drawback of we cannot use Accept-Ranges. Question: is it possible to have multiple values for the Accept-Ranges header? I can see that: Accept-Ranges: none Accept-Ranges: bytes are valid! Is: Accept-Ranges: npt smpte-30 smpte-25 valid too? Should it be white space separated? 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.cwi.nl/~troncy/
Received on Wednesday, 9 September 2009 11:57:44 UTC