- From: Philip Jägenstedt <philipj@opera.com>
- Date: Mon, 24 Jan 2011 11:32:31 +0100
On Mon, 24 Jan 2011 02:36:15 +0100, Robert O'Callahan <robert at ocallahan.org> wrote: > On Sun, Jan 23, 2011 at 12:03 AM, Philip J?genstedt > <philipj at 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
Received on Monday, 24 January 2011 02:32:31 UTC