Re: waiting and seeking events in media element seek algorithm

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.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'