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
<[email protected]> 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
<[email protected]>wrote:
On Wed, 19 Jan 2011 05:01:14 +0100, Rob Coenen <[email protected]>
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
