- From: Ian Hickson <ian@hixie.ch>
- Date: Wed, 10 Feb 2010 02:50:27 +0000 (UTC)
- To: Simon Pieters <simonp@opera.com>, Eric Carlson <eric.carlson@apple.com>, Robert O'Callahan <robert@ocallahan.org>
- Cc: "public-html@w3.org" <public-html@w3.org>
On Tue, 2 Feb 2010, Simon Pieters wrote: > > http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#seeking > > "4. If the (possibly now changed) new playback position is not in one of > the ranges given in the seekable attribute, then the user agent must > raise an INDEX_SIZE_ERR exception (if the seek was in response to a DOM > method call or setting of an IDL attribute), and abort these steps." > > It's annoying to use try/catch every time you set currentTime. It's > nicer to check seekable and then set currentTime. However, even if you > check seekable there's no guarentee that currentTime won't throw because > the cache might be cleared between the check and the setting. Therefore > we think it's better to silently abort the algorithm instead of > throwing. How is .seekable affected by the cache? On Tue, 2 Feb 2010, Eric Carlson wrote: > > I agree, throwing for an out-of-range seek is unexpected if the > questions we have gotten from developers is any indication. I think it > makes more sense to clamp the time value to the maximum seekable time. On Tue, 2 Feb 2010, Simon Pieters wrote: > > Hmm, good point. It seems better to seek to the closest seekable time > than to do nothing. On Wed, 3 Feb 2010, Robert O'Callahan wrote: > > In Gecko, we avoid that kind of problem by being very careful to ensure > that asynchronous cache and codec state changes aren't visible to > scripts. (We haven't implemented 'seekable' yet, but my plan is, when a > script reads 'seekable' we compute the result, store it, and pin the > element's cache entries until the script runs to completion, so > subsequent reads of 'seekable' return the same result and seeking to > times in 'seekable' can't fail.) I think this is critical to make the > media API usable in a robust manner. Maybe the spec should say something > about that. I don't really understand how .seekable can change dynamically anyway, short of the moving window affecting it, but in that particular case the position is clamped, so it won't throw. On Tue, 2 Feb 2010, Eric Carlson wrote: > > This isn't possible lock the element's cache with all media engines, but > even it is was I don't think it would be good to spec that behavior. > Loading and buffering may happen on another thread, or in another > process, and the loader may have a hard limit on what it can buffer. For > example the "live" buffer on my DVR that is limited to the previous 30 > minutes, and the wall clock doesn't stop just because a script is > running. Indeed. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 10 February 2010 02:50:55 UTC