W3C home > Mailing lists > Public > public-media-fragment@w3.org > February 2010

Re: Track fragments

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Wed, 17 Feb 2010 23:46:50 +1100
Message-ID: <2c0e02831002170446p48eda930q11382c14a0031a1c@mail.gmail.com>
To: Davy Van Deursen <davy.vandeursen@ugent.be>
Cc: DENOUAL Franck <Franck.Denoual@crf.canon.fr>, public-media-fragment@w3.org
Hi Davy,

On Wed, Feb 17, 2010 at 11:08 PM, Davy Van Deursen
<davy.vandeursen@ugent.be> wrote:
> On feb 16, 2010 at 20:33, Silvia Pfeiffer wrote:
>> For MPEG and Ogg, how do you determine the byte ranges corresponding
>> to the track fragment request? Are you asking the server for help?
>> (i.e. doing one of the other client-side approaches we have specified
>> in the spec) ?
> Actually, I was talking about the server (and more specifically about the
> internal implementation); I wasn't considering clients here. Thus, byte
> range mappings are determined by the server. I guess that is the reason for
> the confusion: you can resolve the media fragment in a smart client (which
> is able to obtain byte range mappings without external help) or a smart
> server can resolve the media fragment (i.e., the NinSuna case) for you.

Yup, I think you have a very smart query-base media fragment server there.

I was indeed only talking about fragment-based track fragment retrieval.

> In
> case of the former, I do agree that there are problems with Ogg regarding
> track selection (note that a solution for MP4 was discussed here by Dave
> Singer [1]).

Dave only talks about the time dimension there, too. I am not sure MP4
could more easily deal with tracks retrieved through byte range
requests than Ogg does. But I don't know enough about the moov

> In case of the latter, I did not experience any problems with
> both Ogg and MP4 regarding time and track fragments.

So, the client sends a
http://example.com/video.ogg?track="track1","track2", then the server
resolves that to time ranges, sends back that mapping to the client
and the client does the byte range requests? Or does the server just
immediately send back the required data, with a newly created header?

>> Since you are recreating the headers of the container format and
>> copying byte ranges after that, are you actually creating a new
>> resource, so doing the "query" case rather than the "fragment" case?
> From an implementation point of view, you can send the whole resource to the
> UA, or you can create a new one (technically speaking), because headers are
> changing. However, for the UA, it will look like only a fragment of the
> original resource.

Sure, it still is a media fragment, but a query-based one. That's fine, too.

I was only trying to explore the possibilities of having client-side
only track fragments delivered.

>> For me, a URI fragment approach means that if the customer changes in
>> his address bar from http://example.com/video.ogv#track=track1 to
>> http://example.com/video.ogv#track=track2 , the browser does not throw
>> away what it has previously buffered and does not reload the whole
>> thing - it only fills byte range gaps in its buffer that it has left
>> beforehand since they were not requested to be displayed. Changes of
>> URI fragments are not supposed to initiate new page loads.
> But this depends on the underlying implementation of the browser no? Also,
> It seems not trivial to me to create such an implementation because you not
> only need to fill byte range gaps, but headers are also changing when new
> data is added to a media file.

With the time dimension, we decided that it was possible to have it
all based on byte range requests in the client only. No new
functionality, just using plain old byte range requests to fulfill a
request such as http://example.com/video.ogv#t=20,30 . The full header
would be downloaded with all information and then only the byte ranges
that relate to t=20,30, which can be decoded with the available header

The same could be applied to tracks: download the whole headers, then
determine which byte ranges belong to the specified track(s) and just
retrieve those. I was just pointing out that there would likely be
many such requests and it would likely be not as efficient as what you
are doing: namely a query-based retrieval of a new composed resource
that only has the requested tracks.

I think in the spec we can still leave all of the options open, but
the query approach becomes suddenly more interesting, since it is more
likely to be implemented than the client-base approach.

Received on Wednesday, 17 February 2010 12:47:43 GMT

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