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

Dear Frank,

Thanks for your inputs! Indeed, we need to carefully specify how Range
requests are handled when multiple dimensions are used. I have added
this item on our upcoming F2F meeting, that will be virtual [1]. By the
way, we will have the same policy for this virtual F2F meeting, i.e.
open to observers. Will you or other representatives from Canon be
available on Thursday 17/09 and Friday 18/09 (10:00-12:00 CET) for
tele-conferencing?

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

Is it really reasonable to assume that the tracks will not have all the
same duration (i.e. the duration of the whole video)?

Is it unreasonable to claim that the semantics of
#t=10,20&track='oneTrack' is: "I want an excerpt of this video from the
second 10 till the second 20 and I want just the track entitled
'oneTrack' during this time range? And by our spec:
#t=10,20&track='oneTrack' and #track='oneTrack'&t=10,20 should return
the same thing ...

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

Like Yves said, given that spatial addressing usually requires 
transcoding, we might serve it as a sub-resource (?) rather than a pure 
fragment (#). More to come ... stay tuned :-)
Cheers.

   Raphaël

[1] http://www.w3.org/2008/WebVideo/Fragments/wiki/FourthF2FAgenda

-- 
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, 2 September 2009 16:20:14 UTC