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

Re: Track fragments

From: Eric Carlson <eric.carlson@apple.com>
Date: Mon, 22 Feb 2010 08:15:37 -0800
Cc: Davy Van Deursen <davy.vandeursen@ugent.be>, DENOUAL Franck <Franck.Denoual@crf.canon.fr>, public-media-fragment@w3.org
Message-Id: <E1F35DA2-5BEF-480F-95A7-C9C41FF292CF@apple.com>
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>

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"?

eric
Received on Monday, 22 February 2010 16:16:10 GMT

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