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

Re: Track fragments

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Thu, 18 Feb 2010 10:42:12 +1100
Message-ID: <2c0e02831002171542m71e687edhb98b7ee7283ed98@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 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? So, does the
existing client-based media fragment URI approach match the one in
QuickTime?

Cheers,
Silvia.
Received on Wednesday, 17 February 2010 23:43:12 GMT

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