[whatwg] HTML5 video: frame accuracy / SMPTE

[Philip Jägenstedt]

I don't think any rounding should be done, at least not in a way that is  
then observable through currentTime. Each frame has a start time, so if  
the seeked time falls right between two frames, I'd expect the first of  
them to show for half of its duration before the second one shows.

My guess is that in most media frameworks, it will be output sampling rate  
of the sound card that sets the real limit on how accurate seeking can be,  
so for example I would expect that currentTime would be rounded to the  
nearest 1/48000th of a second in a 48 KHz audio stream. Other than that, I  
don't think there should be any limits to how accurate seeking can be, it  
is a quality-of-implementation issue.

(We'll likely run into cases where different browsers think that the same  
time corresponds to different video frames/audio samples, which we'll have  
to iron that out in due course.)

Philip


On Fri, 21 Jan 2011 19:01:43 +0100, Andrew Scherkus  
<scherkus at chromium.org> wrote:

> Based on the discussion on the WebKit bug [1] I wanted to quickly make  
> sure
> we're all on the same page with respect to seeking.
>
> My fix for Chromium was rounding up/down to the nearest frame however I
> agree that seeking should always land within the duration of a frame as
> opposed to rounding.  I'll land a fix for this later today.
>
> Andrew
>
> [1] https://bugs.webkit.org/show_bug.cgi?id=52697
>
> On Wed, Jan 19, 2011 at 12:54 AM, Philip Jägenstedt  
> <philipj at opera.com>wrote:
>
>> On Wed, 19 Jan 2011 05:01:14 +0100, Rob Coenen <coenen.rob at gmail.com>
>> wrote:
>>
>>  I'm really happy to see that Chromium has landed a fix for  
>> frame-accurate
>>> seeking, making SMPTE timecode compliant operations with HTML5 video
>>> possible.
>>> The fix for Firefox is underway (
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=626273 ) and I have filed
>>> bugs
>>> at both Webkit/Safari ( https://bugs.webkit.org/show_bug.cgi?id=52697)
>>> and
>>> Microsoft Internet Explorer 9 (
>>> https://connect.microsoft.com/IE/feedback/details/636755 )
>>>
>>> BTW I tried with Opera 11, but it would only allow me to seek to full
>>> seconds, not frames?
>>>
>>
>> Thanks for pointing this out, it turns out that when seeking I was
>> accidentally truncating to seconds when converting the double to the
>> internal time representation (uint64 nanoseconds). Remember kids, the  
>> cast
>> operator takes precedence over multiplication! Anyway, this is now  
>> fixed and
>> will be in a future Opera release.
>>
>> --
>> Philip Jägenstedt
>> Core Developer
>> Opera Software
>>


-- 
Philip Jägenstedt
Core Developer
Opera Software