RE: Range syntax

Hi all,

Concerning

Content-Range: xywh 160,120,320,240/4:00:00
Content-Range: xywh:pixel 160,120,320,240/4:00
Content-Range: xywh:percent 25,25,50,50/4:00

I think that for Content-Range, it would be more coherent to have the same unit between the range and the instance length:
ie: Content-Range: <spatialarea> ' ' <topleftx> ',' <toplefty>',' <width>',' <height>
                '/' <total width>','<total_heigth>

Content-Range: xywh 160,120,320,240/320,240 (instead of 4:00:00)
Content-Range: xywh:pixel 160,120,320,240/320,240
Content-Range: xywh:percent 25,25,50,50/??? (100,100 not really useful!)
But using this:
1- we loose the duration information
2- what is the instance-length when using 'track' unit (Content-Range: track 'video'/4:00)
--
            Franck.




From: public-media-fragment-request@w3.org [mailto:public-media-fragment-request@w3.org] On Behalf Of Silvia Pfeiffer
Sent: vendredi 11 septembre 2009 00:16
To: Jack Jansen
Cc: Yves Lafon; Davy Van Deursen; public-media-fragment@w3.org
Subject: Re: Range syntax


On Fri, Sep 11, 2009 at 12:05 AM, Jack Jansen <Jack.Jansen@cwi.nl<mailto:Jack.Jansen@cwi.nl>> wrote:

On 9 sep 2009, at 14:36, Yves Lafon wrote:
On Wed, 9 Sep 2009, Yves Lafon wrote:
All,
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.

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).

One of the issue for the first case is when smpte is used, as the beginning of the resource might not be zero. In that case, it would be hard to define the duration in the Content-Range: case.
Jack, Davy, what's your opinion on this?

I'm in favor of the simple solution, i.e.


       Content-Range: smpte-30-drop 1:22:33-2:33:44.1/4:00:00
There seems to be little added value in allowing mixing of time formats (everyone: please speak up if you think there is), and aside from the Accept-Ranges advertisement it would break there's also the burden of more difficult parsing.


I agree - I wouldn't mix time formats in one request - it's not something we do in the URL addressing either.

We could take a different approach where we specify the type of addressing as well as the format, e.g.

Content-Range: time:smpte-30-drop 1:22:33-2:33:44.1/4:00:00

(or just "t" instead of "time") and similarly

Content-Range: time:npt 82:33-153:44.1/4:00:00

then the default could be just

Content-Range: time 82:33-153:44.1/4:00:00

which implies npt (analogous to the URI specs).

This works well for the other dimensions, too:

Content-Range: xywh 160,120,320,240/4:00:00
Content-Range: xywh:pixel 160,120,320,240/4:00
Content-Range: xywh:percent 25,25,50,50/4:00

Content-Range: track 'video'/4:00

Content-Range: id 'chapter-1'/4:00


Cheers,
Silvia.