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

RE: Track fragments

From: Davy Van Deursen <davy.vandeursen@ugent.be>
Date: Wed, 17 Feb 2010 13:58:22 +0100
To: "'Silvia Pfeiffer'" <silviapfeiffer1@gmail.com>
Cc: "'DENOUAL Franck'" <Franck.Denoual@crf.canon.fr>, <public-media-fragment@w3.org>
Message-ID: <004001caafd0$e38f2cf0$aaad86d0$@vandeursen@ugent.be>
On feb 17, 2010 at 13:46, Silvia Pfeiffer wrote:
> Cc: DENOUAL Franck; public-media-fragment@w3.org
> Subject: Re: Track fragments
> 
> Hi Davy,
> 
> On Wed, Feb 17, 2010 at 11:08 PM, Davy Van Deursen 
> <davy.vandeursen@ugent.be> wrote:
> > On feb 16, 2010 at 20:33, Silvia Pfeiffer wrote:
> >>
> >> For MPEG and Ogg, how do you determine the byte ranges 
> >> corresponding to the track fragment request? Are you asking the server
for help?
> >> (i.e. doing one of the other client-side approaches we have
> specified
> >> in the spec) ?
> >
> > Actually, I was talking about the server (and more specifically 
> > about the internal implementation); I wasn't considering clients 
> > here. Thus, byte range mappings are determined by the server. I 
> > guess that is the reason for the confusion: you can resolve the 
> > media fragment in a smart client (which is able to obtain byte range 
> > mappings without external help) or a smart server can resolve the 
> > media fragment (i.e.,
> the NinSuna case) for you.
> 
> Yup, I think you have a very smart query-base media fragment server 
> there.
> 
> I was indeed only talking about fragment-based track fragment retrieval.
> 
> > 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.

> 
> > 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.

Best regards,

Davy

-- 
Davy Van Deursen

Ghent University - IBBT
Department of Electronics and Information Systems - Multimedia Lab
URL: http://multimedialab.elis.ugent.be/dvdeurse
Received on Wednesday, 17 February 2010 12:58:22 GMT

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