On Mon, 24 Jan 2011 02:36:15 +0100, Robert O'Callahan
<rob...@ocallahan.org> wrote:
On Sun, Jan 23, 2011 at 12:03 AM, Philip Jägenstedt
<phil...@opera.com>wrote:
Ah, thanks for clarifying. It might be a bit odd for the spec to forbid
being too clever, but I think that in practice always seeking to the
same
point is much easier, so that's what would be implemented. It would
indeed
be bad if one browser always managed to seek one frame ahead even when
using
fast seeking, and another always seeks to a nearby keyframe/key
unit/index
point/whatever.
Interop problems are going to arise with approximate seeking no matter
what
we do, which is why it shouldn't be the default.
OK, let's go with that, then.
You don't want seekApproximate(T) to always land on the same T'. For
example, if a player wants to "seek forward approximately N seconds" via
seekApproximate(currentTime + N), but the approximation to currentTime +
N
is fixed to be some T' less than or equal to currentTime, that would be
broken.
I would say that seekApproximate(T) should be specified to aim as close
as
possible to T while being "fast", but the only guarantee is that it seeks
somewhere after currentTime if T > currentTime, or somewhere before
currentTime if T < currentTime.
1. There's a race condition here, seekApproximate(currentTime+0.001) will
be quite random since currentTime changes while the script is running.
2. No media framework I've worked with seems to provide fast seeking with
any guarantee of direction, so it might be hard to actually implement this
way on many platforms, while fast seeking in general is very easy.
Other than that, I think it's a good idea!
--
Philip Jägenstedt
Core Developer
Opera Software
