1026330 - fastSeek should always be fast

Status: NEW

(Core :: Audio/Video: Playback, defect)

Description

[Chris Pearce [:cpearce (Not reading bugmail)]]

According to the WhatWG spec, fastSeek() should be fast:

http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#dom-media-fastseek

"9. If the approximate-for-speed flag is set, adjust the new playback position to a value that will allow for playback to resume promptly."

In bug 1022913 we changed fastSeek() to fallback to decode to the seek target if a fastSeek ends up terminating before the current playback position, in order to avoid surprising UX.

We should really seek to the keyframe after the current playback position in this case, so that fastSeek() is always fast. This bug covers making that change.

Comment 1

[Blake Wu [:bwu][:blakewu]]

In OmxDecoder with using Android's demuxer, it can be set to seek to the next key frame or the previous key frame @http://androidxref.com/4.4_r1/xref/frameworks/av/include/media/stagefright/MediaSource.h#68. 
So if this is forward case, we can set it to be SEEK_NEXT_SYNC and for rewind, set it to be SEEK_PREVIOUS_SYNC.

Comment 2

[Blake Wu [:bwu][:blakewu]]

To have a more consistent seek behavior, we may need to have a common demuxer to find the previous or next key frame.