RE: Range syntax

Hi Yves,

> -----Original Message-----
> From: public-media-fragment-request@w3.org [mailto:public-media-
> fragment-request@w3.org] On Behalf Of Yves Lafon
> Sent: woensdag 9 september 2009 14:37
> To: Jack Jansen; Davy Van Deursen
> Cc: public-media-fragment@w3.org
> Subject: Re: Range syntax
> 
> 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?

Why would it be hard to define this duration? If the resource does not begin
at point zero, then this timing information must be present within the
resource. Therefore, the server will always be able to calculate the correct
duration of the returned fragment IMO.

Best regards,

Davy

--
Davy Van Deursen

Ghent University - IBBT
Department of Electronics and Information Systems Multimedia Lab
URL: http://multimedialab.elis.ugent.be

Received on Wednesday, 9 September 2009 20:12:11 UTC