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

Hi Raphaël,

>-----Original Message-----
>From: public-media-fragment-request@w3.org [mailto:public-media-
>fragment-request@w3.org] On Behalf Of Raphaël Troncy
>Sent: Wednesday, September 02, 2009 6:19 PM
>To: DENOUAL Franck
>Cc: 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 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)?

Yes it is. For example, within the MP4 format, the duration of the different tracks can vary. The global duration of the media resource is then equal to the duration of the track with the largest duration. Note that we currently work with MP4 files containing tracks having a different duration (obtained and recorded from live streaming sources), so it is not unthinkable that this is/will be used in practice. On the other hand, to keep things simple (at least in the first phase), I think we should avoid track-specific fragment specifications (e.g., give me second 10 to 20 from track 1 and 10 to 18 from track 2) and track-specific information (such as the duration of a specific track). Any opinions?

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

Although most of current coding formats does not support spatial segment extraction without transcoding, we should not assume that there will be no such coding formats developed in the future ...

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 Thursday, 3 September 2009 06:49:06 UTC