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

[whatwg] HTML5 video: frame accuracy / SMPTE

From: Glenn Maynard <glenn@zewt.org>
Date: Fri, 21 Jan 2011 17:11:56 -0500
Message-ID: <AANLkTin6JKLxma7FsOZbd-7oyQ6r9A-zi9S9oiO3E7ds@mail.gmail.com>
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.


On Fri, Jan 21, 2011 at 5:05 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> One question about inexact seeking is what should the client do when
> the current playtime is closer to the requested time than what the
> inexact seek would provide?

The above would also answer your question: seeking would be unaffected
by the current play cursor.

-- 
Glenn Maynard
Received on Friday, 21 January 2011 14:11:56 UTC

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