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

Re: Track fragments

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Tue, 23 Feb 2010 08:30:02 +1100
Message-ID: <2c0e02831002221330u7a594eb8xe6db4ab32893f4e5@mail.gmail.com>
To: Eric Carlson <eric.carlson@apple.com>
Cc: Davy Van Deursen <davy.vandeursen@ugent.be>, DENOUAL Franck <Franck.Denoual@crf.canon.fr>, public-media-fragment@w3.org
On Tue, Feb 23, 2010 at 3:15 AM, Eric Carlson <eric.carlson@apple.com> wrote:
> On Feb 17, 2010, at 3:42 PM, Silvia Pfeiffer wrote:
>> On Thu, Feb 18, 2010 at 2:49 AM, Eric Carlson <eric.carlson@apple.com> wrote:
>>> On Feb 17, 2010, at 5:00 AM, Silvia Pfeiffer wrote:
>>>>>> 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
>>>>>> containers.
>>>>> Once you get the full header of an MP4 file, obtaining the byte ranges
>>>>> corresponding to particular tracks should not be problem and is comparable
>>>>> to way it is done in the time dimension.
>>>> That's interesting and good to know. Curious to see that working.
>>>  You see this working today whenever you open a movie with disabled tracks in any client that uses QuickTime on OSX 10.6. QuickTime only reads data when it needs to be scheduled for display, so disabled tracks are never retrieved.
>> Not retrieved from the server? That's impressive. Good to know it can
>> be done, so it's not unreasonable to have it in the spec.
>> I'm curious: Is the retrieval based on byte ranges?
>  Yes, the retrieval is based on byte ranges. The code higher up in the stack doesn't know, or care, whether the data is remote or local, it only knows the file offset of the media data for any time in the movie. When the code that schedules playback sees that data for a given time is needed, it asks the IO subsystem to read from some offset in the file. The IO subsystem that reads data from the network *always* uses byte range requests, making it effectively the same as the code that reads data from the file system from the perspective of the higher level playback engine.
>  Thus whether the movie plays continuously from start to finish, or the user seeks randomly during playback, makes no difference to the higher level code.
>> So, does the existing client-based media fragment URI approach match the one in
>> QuickTime?
>  What exactly is the "client-based media fragment URI approach"?

It's exactly what you describe: the media file allows the client (or
the client's media framework) to map media fragments (time offsets,
tracks, regions) to byte ranges and retrieve the byte ranges.

Received on Monday, 22 February 2010 21:30:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:44 UTC