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

On Wed, 26 Aug 2009, DENOUAL Franck wrote:

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

Applying two different axis there is indeed challenging. Content-Range, if 
it provides only the time will provide the time information in reference 
to the whole resource, not the first fragment 
http://www.example.com/video.ogv#track='oneTrack', unless we capture this 
in the syntax of Content-Range... Even for the design of Content-Fragment, 
we have to be quite strict in the way de define things and define the 
meaning of the '50' in your example.

> 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 spatial fragment (implying transcoding in most cases), we are leaning 
toward not presenting them as fragment but as sub-resources. More on that 
in a subsequent email...

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

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

Received on Wednesday, 2 September 2009 13:32:56 UTC