W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2011

[whatwg] HTML5 video: frame accuracy / SMPTE

From: Philip Jägenstedt <philipj@opera.com>
Date: Thu, 13 Jan 2011 08:44:57 +0100
Message-ID: <op.vo8k47insr6mfa@kirk>
On Thu, 13 Jan 2011 01:23:57 +0100, Eric Carlson <eric.carlson at apple.com>  
wrote:

>
> On Jan 12, 2011, at 4:04 PM, Robert O'Callahan wrote:
>
>> On Wed, Jan 12, 2011 at 9:42 PM, Philip J?genstedt  
>> <philipj at opera.com>wrote:
>>
>>> For the record, this is the solution I've been imagining:
>>>
>>> * add HTMLMediaElement.seek(t, [exact]), where exact defaults to false  
>>> if
>>> missing
>>>
>>> * make setting HTMLMediaElement.currentTime be a non-exact seek, as  
>>> that
>>> seems to be the most common case
>>
>>
>> I think setting currentTime should be exact, since a) exact seeking is
>> simpler from the author's point of view and b) it would be unfortunate  
>> to
>> set currentTime to value T and then discover that getting currentTime  
>> gives
>> you a value other than T (assuming you're paused).
>>
>   I agree that precise seeking follows the principle of least surprise,  
> based partly on the bugs files against the <video> element on iOS where  
> this hasn't always been the behavior.

Changing the default at this point wouldn't really hurt since not all  
browsers are doing exact seeking anyway, right? I think that keyframe  
seeking is more often what you want and it'd be better to let the few who  
want frame-exact seeking jump through hoops than having everyone who makes  
a simple seeking UI discover that seeking is a bit slow and 20% of them  
figuring out that it can be fixed by using seek().

-- 
Philip J?genstedt
Core Developer
Opera Software
Received on Wednesday, 12 January 2011 23:44:57 UTC

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