[whatwg] HTML5 video: frame accuracy / SMPTE
chris at pearce.org.nz
Fri Jan 21 20:23:36 PST 2011
On 22/01/2011 3:23 p.m., Gregory Maxwell wrote:
> On Fri, Jan 21, 2011 at 8:19 PM, Chris Pearce<chris at pearce.org.nz> wrote:
>> On 22/01/2011 7:31 a.m., Gregory Maxwell wrote:
>>> It's usually the decoding, not the file access that kill you. Firefox
>>> seeking on low resolution clips is very snappy index or not. But try a
>>> 1080p clip encoded with a 10 second maximum keyframe interval...
>> This is true. If you want fast frame accurate seeking, particularly over the
>> internet, it's best to not encode with such a large keyframe interval. This
>> is a problem caused by a webdev's inappropriate encoding choice, not by a
>> bad API choice.
> One second of decoding time is already a fairly slow seek. Surely you
> aren't suggesting that people should be using one-to-sub-second
> keyframe intervals?
Most Ogg media out there has a keyframe interval of 2 seconds, which
seems reasonable to me.
With *indexed* Ogg media, when seeking into unbuffered ranges, the seek
usually completes within 2-4 seconds. This is comparable speed to
seeking into unbuffered media on YouTube's Flash video. Were I live in
the world it is anyway.
People don't seek very often when playing media. It doesn't seem
unreasonable to wait *a few* seconds for a seek into an unbuffered range
With non-indexed Ogg media where you must perform a bisection search
over HTTP, performance will obviously be slower, but that's why we
developed the Ogg index in the first place. Perhaps your comparing
Firefox's performance to Cortado on non-indexed media?
>> Seeks would only be "slow" in the case where keyframes were infrequent. In
>> many cases a "snap to keyframe" seek would be inaccurate enough to be
>> annoying with infrequent keyframes. I can only imagine the bugs we'll get
>> filed if we make it the default!
> Inaccurate seeking is pretty much universal in media-player
> applications. ::shrugs:: I haven't conducted an exhaustive survey
> across systems, but on my desktop firefox is the only tool that does
> frame accurate seeking by default. Totem doesn't, VLC doesn't, Mplayer
The seek precision in those players you list is limited by the input
mechanism; their GUI seek bars. Whereas we're (re)specifying an API
which accepts a more precise floating point number.
There's nothing stopping the various browsers using the approximate seek
mechanism in their controls.
More information about the whatwg