W3C home > Mailing lists > Public > public-media-fragment@w3.org > August 2009

RE: ISSUE-11 (Duration-header): How the UA knows the full media duration when only a fragment is served?

From: DENOUAL Franck <Franck.Denoual@crf.canon.fr>
Date: Wed, 26 Aug 2009 15:01:31 +0200
To: Media Fragments Working Group WG <public-media-fragment@w3.org>
Message-ID: <40375B187E39BC4589F9C89097BD82A4251A2ACCFB@cressida.crf.canon.fr>
Dear fragmenters,

It seems that for simple temporal fragments, the "instance-length" field of the Content-Range header will do the job.
But if you consider a Track+Time fragment such as:
http://www.example.com/video.ogv#track='oneTrack'&t=10,20
you probably would like a display with the duration of "oneTrack" instead of the duration of "video.ogv". 
In this case, you'd probably need something like the "Content-Fragment" header from Conrad's proposal [1] extended with an "fragment-length" parameter :
Content-Range: time 00:10-00:20
Content-Fragment: track='oneTrack'/50 where 50 is the track duration (we infer a duration using range-unit info).


Concerning now spatial fragments and the ISSUE-5 raised by Jack [2]
ex: http://www.example.com/video.ogv#xywh=12,12,96,96

and given that "other-range-resp-spec"= *CHAR [3], do you think that a server could generate a Content-Range header as below:
Content-Range: xywh=10,10,100,100/256,256
This would provide the actual spatial area extracted by the server and the max sizes.

For fragments combining track + spatial,
http://www.example.com/video.ogv#track='oneTrack'&xywh=12,12,96,96
the server could send:
Content-Range: xywh=10,10,100,100
Content-Fragment: track='oneTrack'/128,128 where 'oneTrack' is a low resolution version (128*128 instead of 256*256). Here, the client is aware that "128,128" corresponds to a resolution since range-unit = xywh.

Does it make sense ?
--
	Franck.
[1] http://www.w3.org/2008/WebVideo/Fragments/wiki/HTTP_Examples#Track.2BTime_Fragment_URI

[2] http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/5

[3] http://www.ietf.org/id/draft-ietf-httpbis-p5-range-07.txt



> -----Original Message-----
> From: public-media-fragment-request@w3.org [mailto:public-media-fragment-
> request@w3.org] On Behalf Of Raphaël Troncy
> Sent: mercredi 19 août 2009 19:30
> To: Media Fragments Working Group WG
> Subject: Re: ISSUE-11 (Duration-header): How the UA knows the full media duration
> when only a fragment is served?
> 
> Dear all,
> 
> We have discussed the ISSUE-11 during the 19/08/2009 telecon [1]. Yves
> confirmed that a normal HTTP response (206) to a HTTP range request will
> do the job. The wiki page [2], which was incomplete, has been updated.
> More precisely, the content-range header in the response will have as
> value something in the line of:
> 
>    Content-Range: seconds 11.85-21.16/3600
> 
> indicating thus the total duration of the parent resource. The UA will
> be able to display the complete timeline of the resource.
> I have closed this ISSUE in the tracker.
> 
>    Raphaël
> 
> [1] http://www.w3.org/2009/08/19-mediafrag-minutes.html

> [2] http://www.w3.org/2008/WebVideo/Fragments/wiki/HTTP_implementation

> 
> Media Fragments Working Group Issue Tracker a écrit :
> > ISSUE-11 (Duration-header): How the UA knows the full media duration
> > when only a fragment is served?
> >
> > http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/11

> >
> > Raised by: Silvia Pfeiffer On product:
> >
> > An issue with any of our existing specs with fragments (#) that just
> > occurred to me is: if the retrieval action only retrieves the
> > specified segment, the browser has no way to figure out the length
> > (start/duration) of the original resource. Maybe we need to introduce
> > additional headers that would provide for that?
> 
> --
> 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, 26 August 2009 13:02:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 21 September 2011 12:13:34 GMT