W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2008

[whatwg] Issue when Video currentTime used for seeking.

From: Eric Carlson <eric.carlson@apple.com>
Date: Wed, 12 Nov 2008 08:02:26 -0800
Message-ID: <B5892135-B371-4FF9-B880-FF35C2097F42@apple.com>

On Nov 11, 2008, at 11:24 PM, Chris Double 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?
>
   Seeks should end up as close to the requested time as possible, the  
behavior wrt keyframes should be an implementation detail. I say "as  
close as possible" because it is not always possible to know the file  
location of an exact time unless all of the media data up to that time  
has already been downloaded.

> 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. But is there a requirement to be able to identify
> keyframes from JavaScript? I suspect not but don't know.
>
   I agree that it doesn't make sense to try to identify keyframes  
from JavaScript. I can't imagine that it will be commonly used, and  
with (at least some) streaming formats a media engine has no  
information about keyframe location or availability.

eric
Received on Wednesday, 12 November 2008 08:02:26 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:07 UTC