RE: Track fragments

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

Received on Wednesday, 17 February 2010 13:29:47 UTC