[whatwg] <video> element feedback

On Mar 23, 2007, at 3:49 PM, Silvia Pfeiffer wrote:

> Hi Eric,
>
> On 3/24/07, Eric Carlson <eric.carlson at apple.com> wrote:
>>
>>  Even without a server component, #2 and #3 do not require the UA to
>> download the full file if it can use byte range requests for random  
>> access
>> and the file format has time to offset tables (eg. the 'moov'  
>> resource in a
>> QuickTime movie or ISO-based file, the 'movi' LIST chunk in an AVI  
>> file,
>> etc).
>
> I agree partially.
>
> You're right - it doesn't need to download everything.
>
> But there are two catches:
>
> 1) The UA doesn't know what byterange a timecode or timerange maps to.
> So, it has to request this information from the server, who has access
> to the file. For QuickTime movies, the UA would need to request the
> offset table from the server and for AVI it would need to request the
> chunking information.
>
> 2) Just streaming from an offset of a video file often breaks the file
> format. For nearly all video formats, there are headers at the
> beginning of a video file which determine how to decode the video
> file. Lacking this information, the video files cannot be decoded.
> Therefore, a simple byterange request of a subpart of the video only
> results in undecodable content. The server actually has to be more
> intelligent and provide a re-assembled correct video file if it is to
> stream from an offset.
>
     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.

   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.

   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.

eric

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20070323/daf9fe1c/attachment.htm>

Received on Friday, 23 March 2007 16:33:39 UTC