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

[whatwg] HTML5 video seeking

From: Ralph Giles <giles@mozilla.com>
Date: Wed, 16 Nov 2011 14:36:17 -0800
Message-ID: <4EC43AE1.6040602@mozilla.com>
Hash: SHA1

On 15/11/11 10:32 AM, Aaron Colwell wrote:

> Yeah it looks to me like starting at the requested position is the
> only option. I saw the text about media engine triggered seeks, but
> it seems like users would be very surprised to see the seeking &
> seeked events for the seek they requested immediately followed by a
> pair of events to a location they didn't request. I can envision
> the angry bug reports now. ;)

Yeah, it's definitely bending the rules. If you only intended to
support seeking to the nearest keyframe, setting media.seekable would
be an honest way to advertise that, but also violates least surprise.

> Thanks for the response. Looks like we are interpreting the text
> the same way.

Yes, my recollection of the earlier discussion aligns with your
summary and Chris Double's. It's expensive, but what one naively
expects the API to do.

Video splicing/mixing was a use case we wanted to support, and such
applications aren't really possible without frame-accurate seeking.
Thus, it's better to require it up front and possibly allow
applications to relax it later, as with Frank and Philip's 'strict'
attribute, than to disallow such applications by leaving this to
implementation variance.


Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

Received on Wednesday, 16 November 2011 14:36:17 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:09 UTC