<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<br><div><div>On Mar 23, 2007, at 3:49 PM, Silvia Pfeiffer wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Hi Eric,<br><br>On 3/24/07, Eric Carlson <<a href="mailto:eric.carlson@apple.com" com_apple_mail_added="yes">eric.carlson@apple.com</a>> wrote:<br><blockquote type="cite"><br></blockquote><blockquote type="cite"> Even without a server component, #2 and #3 do not require the UA to<br></blockquote><blockquote type="cite">download the full file if it can use byte range requests for random access<br></blockquote><blockquote type="cite">and the file format has time to offset tables (eg. the 'moov' resource in a<br></blockquote><blockquote type="cite">QuickTime movie or ISO-based file, the 'movi' LIST chunk in an AVI file,<br></blockquote><blockquote type="cite">etc).<br></blockquote><br>I agree partially.<br><br>You're right - it doesn't need to download everything.<br><br>But there are two catches:<br><br>1) The UA doesn't know what byterange a timecode or timerange maps to.<br>So, it has to request this information from the server, who has access<br>to the file. For QuickTime movies, the UA would need to request the<br>offset table from the server and for AVI it would need to request the<br>chunking information.<br><br></blockquote><blockquote type="cite">2) Just streaming from an offset of a video file often breaks the file<br>format. For nearly all video formats, there are headers at the<br>beginning of a video file which determine how to decode the video<br>file. Lacking this information, the video files cannot be decoded.<br>Therefore, a simple byterange request of a subpart of the video only<br>results in undecodable content. The server actually has to be more<br>intelligent and provide a re-assembled correct video file if it is to<br>stream from an offset.<br><br></blockquote><div> Yes, the UA needs the offset/chunking table in order to calculate a file offset for a time, but this is efficient in the case of container formats in which the table is stored together with other information that's needed to play the file. This is not the case for all container formats, of course.</div><div><br class="webkit-block-placeholder"></div><div> The UA would first use byte range requests to download the header. If the information is stored somewhere other than the beginning of the file, it may take several byterange requests to find it, but this is not much less efficient with ISO-derived or RIFF type formats. Once is has the headers, it will able to calculate the offset for any time in the file and it can request and play the media for *any* time range in the file.</div><div><br class="webkit-block-placeholder"></div><div> This scheme has the added benefit of not requiring the header to be downloaded again if the user requests another time range in the same file.</div><div><br class="webkit-block-placeholder"></div><div>eric</div><div><br></div></div></body></html>