- From: Biju Gm@il <bijumaillist@gmail.com>
- Date: Thu, 13 Nov 2008 07:49:02 -0400
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.
Received on Thursday, 13 November 2008 03:49:02 UTC