[whatwg] Issue when Video currentTime used for seeking.

[Biju Gm@il]

On Wed, Nov 12, 2008 at 3:24 AM, Chris Double <chris.double at double.co.nz> wrote:
> On Wed, Nov 12, 2008 at 6:36 PM, Biju Gm at il <bijumaillist at gmail.com> wrote:
>> toKeyFrame - optional, boolean, default false. if true indicates goto
>> the nearest keyframe of the value provided in secondsToSeek.
>> this is to improve performance while avoiding  bug
>> https://bugzilla.mozilla.org/show_bug.cgi?id=463358
>
> Good question. Should seeks go to the previous keyframe to the
> requested time,  the next keyframe after the time, the closest
> keyframe, or the exact frame requested?

The idea for toKeyFrame argument came from some flash video controls
ie, when we silde the duration slider, these flash controls flips
through frames quickly.
At that time it dont really matter exactly which frame, it can be
before or after
which ever is EASY to find.

> Regarding that bug, I think it should be going to the last keyframe
> then decoding up to the point of the requested frame so it can display
> non-garbage data.

I agree...

>> .seek() will return the time to which it is seek-ed to.
>
> What time is that exactly? Is that the time of  the actual frame the

There are 2 situations after execution of .seek()
1. the video not doing seeking or completed seeking
eg:-
a) .seek(0)   (a seek with 0 time) when the video is not already seeking)
b) .seek(+n) when video is already at end of file
these two cases it will return value same as .currentTime

2. the video is still seeking or not completed seeking
.seek(n) should return the "cumulative" time to which it is being seek-ed.

one issue I see here is, if the video duration is only 10 seconds and
seek was called for 100 seconds, what should seek()
I feel for consistency we should return 100, ie with or with out
metadata we will be able to provide same value.