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:35:57 +1100
Message-ID: <2c0e02831002171535n54504bcbt10cd6f05449f1dd4@mail.gmail.com>
To: Davy Van Deursen <davy.vandeursen@ugent.be>
Cc: DENOUAL Franck <Franck.Denoual@crf.canon.fr>, public-media-fragment@w3.org
On Thu, Feb 18, 2010 at 12:29 AM, Davy Van Deursen
<davy.vandeursen@ugent.be> wrote:
> On feb 17, 2010 at 14:00, Silvia Pfeiffer wrote:
>> Cc: DENOUAL Franck; public-media-fragment@w3.org
>> Subject: Re: Track fragments
>>
>> On Wed, Feb 17, 2010 at 11:58 PM, Davy Van Deursen
>> <davy.vandeursen@ugent.be> wrote:
>> > On feb 17, 2010 at 13:46, Silvia Pfeiffer wrote:
>> >> On Wed, Feb 17, 2010 at 11:08 PM, Davy Van Deursen
>> >> > On feb 16, 2010 at 20:33, Silvia Pfeiffer wrote:
>> >>
>> >> > 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
>> >> 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.
>>
>>
>> >> > 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?
>> >
>> > Currently, the server sends immediately back the required data.
>> > However, since our underlying implementation is based on byte range
>> > composition, it should be relatively easy to send a byte range
>> mapping to the client too.
>>
>> Out of curiosity: Did you use the headers that are in the current spec
>> or something earlier?
>
> In case of using the '?', no additional headers are involved in the
> response. But NinSuna also supports the HTTP Range header with time
> dimension. The proper content-range is also contained in the corresponding
> HTTP response (see also [1]). So this is actually an implementation of [2]
> for the time dimension.
>
> Best regards,
>
> Davy
>
> [1]
> http://www.w3.org/2008/WebVideo/Fragments/wiki/ImplementationExperiment#Segm
> ents_via_the_HTTP_Range_header
> [2]
> http://www.w3.org/TR/2009/WD-media-frags-20091217/#processing-protocol-Serve
> r-mapped

Sorry, I should have known - have read those docs before.
Cool to see it implemented and working!

I noticed one difference: As you used "time" instead of "t" on the
protocol level, we should adapt the spec to use that, too, IMO. More
readable anyway.

Cheers,
Silvia.
Received on Wednesday, 17 February 2010 23:36:49 GMT

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