Re: Range syntax

On Fri, Sep 11, 2009 at 12:05 AM, Jack Jansen <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.