W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2011

[whatwg] HTML5 video: frame accuracy / SMPTE

From: Philip Jägenstedt <philipj@opera.com>
Date: Sat, 22 Jan 2011 10:23:50 +0100
Message-ID: <op.vppdp0r0sr6mfa@nog>
On Fri, 21 Jan 2011 23:11:56 +0100, Glenn Maynard <glenn at zewt.org> wrote:

> On Fri, Jan 21, 2011 at 4:40 PM, Philip J?genstedt <philipj at opera.com>  
> wrote:
>> I'm fine with any terminology, as long as it allows implementations to  
>> seek
>> to some other time than currentTime if it's (much) faster to do so.
>> GStreamer has the flags GST_SEEK_FLAG_ACCURATE and  
>> GST_SEEK_FLAG_KEY_UNIT,
>> if that's any inspiration.
>
> Should there be any consistency requirements for fast seeking?
>
> Suppose you have a format that's high-bitrate but cheap to decode.
> Accurately seeking is fast if the data is already buffered, but slow
> if not, since it's limited by bandwidth and not CPU.
>
> An implementation might decide to snap to a keyframe if the needed
> data isn't yet buffered, so it doesn't spend several seconds
> downloading all of the data; but if it the data is already buffered,
> to seek precisely.
>
> This could have unexpected side-effects.  Should this be allowed?  I'd
> suggest that fast seeking should always be consistent with itself, at
> least for a particular video instance.

I don't think that any consideration should be given to what is already  
buffered and not, as it's always faster to seek to what's buffered so that  
would simply make it impossible to seek into the unbuffered parts. Also,  
it'd require the demuxer (which is where seeking happens) to have  
knowledge of the transport layer.

-- 
Philip J?genstedt
Core Developer
Opera Software
Received on Saturday, 22 January 2011 01:23:50 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:29 UTC