On Jan 12, 2011, at 12:42 AM, Philip Jägenstedt wrote: > On Wed, 12 Jan 2011 09:16:59 +0100, Glenn Maynard <gl...@zewt.org> wrote: > >> On Wed, Jan 12, 2011 at 2:49 AM, Philip Jägenstedt <phil...@opera.com> wrote: >>> (Also, it might be useful to be able to chose whether seeking should be fast >>> or exact, as frame-accurate seeking is hardly necessary in most normal >>> playback situations.) >> >> In an audio engine I worked on I had a seek hint like that, to >> indicate whether the priority was accuracy or speed. It matters even >> more with video: when seeking with a seek bar, you may want to snap to >> keyframes, whereas bookmarks, "jump to chapter" features, etc. will >> often want to jump precisely. A fast seek option would be >> particularly useful for files with infrequent keyframes. >> > > For the record, this is the solution I've been imagining: > > * add HTMLMediaElement.seek(t, [exact]), where exact defaults to false if > missing > > * make setting HTMLMediaElement.currentTime be a non-exact seek, as that > seems to be the most common case > That is a very interesting idea!. Precise seeking in some video files can be quite slow, greater than a second is not unlikely on some devices. FWIW, the media playback framework on iOS has a seek method with parameters for the tolerance allowed before and after the seek time [1] to allow the programmer to choose.
eric [1] http://developer.apple.com/library/ios/#documentation/AVFoundation/Reference/AVPlayer_Class/Reference/Reference.html%23//apple_ref/occ/instm/AVPlayer/seekToTime:toleranceBefore:toleranceAfter: