- From: Glenn Maynard <glenn@zewt.org>
- Date: Fri, 21 Jan 2011 17:56:41 -0500
On Fri, Jan 21, 2011 at 5:19 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote: > It would, but it also results in some pretty perplexing and unfriendly > behavior... where the user hits the 5-seconds forward button and ends > up going 4-seconds backwards, only to press the button again and > repeatedly land on the same spot. For your particular example, you almost certainly want accurate seeking for "5-seconds forward", not fast seeking. (Keyframe-based seeking would even cause this to do nothing at all, if keyframes are 10 seconds apart.) On Fri, Jan 21, 2011 at 5:25 PM, Silvia Pfeiffer <silviapfeiffer1 at gmail.com> wrote: >> The language I'd prefer is "fast". ?Fast may be exact, or it might >> just be to the nearest keyframe, or something in between. It might >> just start you over at the beginning of the stream. > > That is putting a restriction on how the browser has to seek - > something I'd rather leave to the browser in the general case where > the Web developer doesn't care. "Fast" requires the browser to use the > fastest seeking method. "Best effort" may be the same one that is the > fastest, or it may be one that is slightly less fast, but more > accurate, because the browser thinks it can afford to do the exact > seek without substantial overhead. It's a hint, not a mandate. "Fast" doesn't mean that the browser must use the fastest method available, it means that the user prefers fast (and less precise) methods over slow, accurate ones. The browser is free to ignore it, even heuristically (eg. always do fast seeking on videos with keyframes less than 1-second apart). (I have a feeling all these seek modes are getting ahead of things and possibly overdesign, though I agree the seek mode should be an enum and not a boolean, for future expansion.) -- Glenn Maynard
Received on Friday, 21 January 2011 14:56:41 UTC