- From: Simon Pieters <simonp@opera.com>
- Date: Wed, 10 Feb 2010 13:01:09 +0100
- To: "Ian Hickson" <ian@hixie.ch>, "Eric Carlson" <eric.carlson@apple.com>, "Robert O'Callahan" <robert@ocallahan.org>
- Cc: "public-html@w3.org" <public-html@w3.org>
On Wed, 10 Feb 2010 03:50:27 +0100, Ian Hickson <ian@hixie.ch> wrote: > 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? See below. > 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. It's only clamped if currentTime is set past duration -- not past buffered. So it would still throw when trying to seek past buffered for servers that don't support range requests. On Wed, 10 Feb 2010 04:42:49 +0100, Robert O'Callahan <robert@ocallahan.org> wrote: > In our case, if the server doesn't support HTTP byte-range requests (or > uses > a non-HTTP protocol such as FTP) then we can only allow seeking within > regions of media data which are in cache. Indeed. I can also imagine that seeking is just possible for the cached bits while being offline. > 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. -- Simon Pieters Opera Software
Received on Wednesday, 10 February 2010 12:01:28 UTC