[whatwg] HTML5 video: frame accuracy / SMPTE

[Chris Pearce]

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 
to complete.

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?

> [snip]
>> 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
> doesn't.

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.

Chris Pearce.