- 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>
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 UTC