Re: waiting and seeking events in media element seek algorithm

On Mon, 29 Mar 2010 12:23:16 +0800, Ian Hickson <ian@hixie.ch> wrote:

> On Mon, 29 Mar 2010, Philip Jägenstedt wrote:
>>
>> Looks better, but the way the seeking event is fired is a bit strange.
>>
>> First, why the condition "the user agent has still not established
>> whether or not the media data for the new playback position is
>> available"? This has to do with buffering, and is already indicated by
>> the waiting event.
>>
>> The second condition, that "the user agent has still not [...] decoded
>> enough data to play back that position" is strange. It seems that the
>> only way seeking could *not* be fired is if the seek is to the current
>> position. If that's the intention, why not state so explicitly? However,
>> unless the audio/video is paused, it's impossible to intentionally seek
>> to the current position, so I think we should simply *always* fire the
>> seeking event. This is what Opera 10.50 does.
>
> The idea is to only fire 'seeking' if seeking is going to take long  
> enough
> that the seek is going to effectively "skip". If the UA can do it so fast
> that it just plays the first frame of the next step immediately, then
> there's no point firing 'seeking' and showing the "seeking" UI.

"skip"? Do you mean if there is a detectable delay before the new frame  
shows up? What's the use case for this? The waiting event for the network  
serves this purpose if the delay is because of the network. For decoding,  
however, it's quite difficult to know how long it's going to take before  
it's done, so we will simply always fire it. Is there any browser that  
does things differently or plans to? The spec could certainly be clearer  
on what a UA behavior is allowed here.

-- 
Philip Jägenstedt
Core Developer
Opera Software

Received on Monday, 29 March 2010 07:04:44 UTC