[whatwg] <video> element feedback

[Michael Dale]

Eric Carlson wrote:
>     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.
There is no reason why both methods can't be supported. If people wanted 
to use annodex for seeking they could just write a js function that will 
remap the src of the video element on seek overriding the UA http offset 
seek method.
The UA http offset method evoked by stream_id#time as the src would be 
more or less equivalent to the calling stream_id.seek(time); 

All that is required of video element is that it be open to annodex 
content and not freak out when the src element has a request string and 
the timestamps for the video stream don't start with zero.

VLC does what you describe (arbitrary seeking when playing over http). 
VLC does this fairly well for arbitrary codec/containers but its 
performs varies per codec/container in accuracy and the amount of 
request/time it takes to jump to the desired location... But I think UA 
local seeking will work fine for most usage scenarios where end users 
are writing html and want to highlight a given section of a single clip 
on a page.

Having the server handle it with annodex dramatically shortens the time 
it takes to jump to the requested offset. This is important for sequence 
together segments from lots of different files. Or if you want to let 
the end user download a segment of the video which they can edit and use 
locally. For example with metavid we have 7-8 hour streams and letting 
people grab just a 1 min section that they can use locally is important 
and having the video element support playback of these segments is also 
important :)

--michael