- From: Simon Pieters <simonp@opera.com>
- Date: Mon, 01 Feb 2010 11:22:24 +0100
- To: "public-html@w3.org" <public-html@w3.org>
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 UTC