W3C home > Mailing lists > Public > public-html@w3.org > February 2010

waiting and seeking events in media element seek algorithm

From: Simon Pieters <simonp@opera.com>
Date: Mon, 01 Feb 2010 11:22:24 +0100
To: "public-html@w3.org" <public-html@w3.org>
Message-ID: <op.u7f1rmscidj3kv@zcorpandell.linkoping.osa>
http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#seeking

"8. If the media element was potentially playing immediately before it  
started seeking, but seeking caused its readyState attribute to change to  
a value lower than HAVE_FUTURE_DATA, the user agent must queue a task to  
fire a simple event named waiting at the element."

We don't want to do this sync in the seek algorithm, because we can't  
easily tell whether readyState will change at this point. Instead we  
suggest that waiting be fired as part of this requirement:

"When a media element that is potentially playing stops playing because  
its readyState attribute changes to a value lower than HAVE_FUTURE_DATA,  
without the element having ended playback, or playback having stopped due  
to errors, or playback having paused for user interaction, or the seeking  
algorithm being invoked, the user agent must queue a task to fire a simple  
event named timeupdate at the element, and queue a task to fire a simple  
event named waiting at the element."

(which needs modification to cover the seeking case)


Also,

"9. If, when it reaches this step, the user agent has still not  
established whether or not the media data for the new playback position is  
available, and, if it is, decoded enough data to play back that position,  
the user agent must queue a task to fire a simple event named seeking at  
the element."

We think it's better to always fire seeking, because we won't easily be  
able to tell whether the new position is available.

-- 
Simon Pieters
Opera Software
Received on Monday, 1 February 2010 10:22:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:01 GMT