- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Thu, 18 Feb 2010 00:00:45 +1100
- To: Davy Van Deursen <davy.vandeursen@ugent.be>
- Cc: DENOUAL Franck <Franck.Denoual@crf.canon.fr>, public-media-fragment@w3.org
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? Cheers, Silvia.
Received on Wednesday, 17 February 2010 13:01:39 UTC