- From: Dave Singer <singer@apple.com>
- Date: Mon, 6 Oct 2008 17:04:34 -0700
- To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Cc: Media Fragment <public-media-fragment@w3.org>
At 10:54 +1100 7/10/08, Silvia Pfeiffer wrote: >On Tue, Oct 7, 2008 at 10:26 AM, Dave Singer <singer@apple.com> wrote: >> At 9:16 +1100 7/10/08, Silvia Pfeiffer wrote: >>>> For example, in a media file that has an index and is >>>> in time-order, a user-agent wanting a time-based subset may be able to >>>> use >>>> byte-range requests to get the index, and then the part(s) of the file >>>> containing the desired media. (We do this today for MP4 and MOV files). >>> >>> Yes, byte-ranges are possible. However, the Web server is the only >>> component in the system that knows about converting a time offset to a >>> byte range. Therefore, you have to first communicate with a URI >>> reference to the server which subsegment you would like to have, the >>> server can then convert that to byte ranges, return to the UA which >>> byte range he has to request, and then we can do a normal byte-range >>> request on the full URI. >>> >>> When you say that you do this today for MP4 and MOV files, how do you >>> communicate the fragment to the Web server? >> >> MP4 and MOV files have tables in the moov atom which give complete time and >> byte-offset indexing for every video and audio frame. Atoms are also sized. >> You can gamble, ask for 1K at the start of the file; if it's laid out for >> incremental playback, the moov atom will be the first or second atom; >> you've got its size now, and can download the rest. If it wasn't, you have >> the size of those atoms and can skip past them and ask for the next. Once >> you have the moov atom, you know exactly what bytes you need to go anywhere >> in time (and yes, even sync points are marked, so you know how far to back >> up if someone does a random access). If video and audio are interleaved in >> time order, the data you need will be all contiguous. > >This still does not solve the client-server problem. Say, a UA wants >to play back a MOV file from sec 45-88. The UA does not know how to >map that to a byte offset and therefore to a byte-range request. that's what i telling you; it does. it can find the index, typically in one request. given the index, it can figure it out... >the >UA has to ask the server for this information. no, really this woks >The server can ask the >local MOV file for the byte mapping from the time mapping by analysing >the tables in the moov atom as you described. Then it can tell the UA >this information which in turn can do a byte-range request. > >What we are talking about with a temporal media fragment request >through a URI is the very first step: the UA needs to request from the >Web server the media fragment. not always... > > >> This is, of course, very difficult for VBR un-indexed files. Pretty easy, >> of course, for CBR files. > >As long as it is all handled by the Web server, it's no different in >process. The mapping to byte ranges may be as complicated as possible >- the UA and the network don't care, they just handle whatever they >are being told by the Web server. > sure, if we extend http to cover time-range requests -- David Singer Apple/QuickTime
Received on Tuesday, 7 October 2008 00:06:26 UTC