Re: waiting and seeking events in media element seek algorithm

On Mon, 29 Mar 2010, Philip Jägenstedt wrote:
> 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.

The use case is not having flickering UI (blinking the word "seeking...") 
if it's not necessary. If it would be helpful, I can make the spec more 
explicitly queue the task to fire "seeking" and then abort the send if by 
the time the task is ready, the seek is complete, or some such.

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