Open
Bug 1026330
Opened 10 years ago
Updated 2 years ago
fastSeek should always be fast
Categories
(Core :: Audio/Video: Playback, defect)
Tracking
()
NEW
People
(Reporter: cpearce, Unassigned)
References
(Blocks 1 open bug)
Details
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•10 years ago
|
||
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•10 years ago
|
||
To have a more consistent seek behavior, we may need to have a common demuxer to find the previous or next key frame.
Updated•9 years ago
|
Component: Audio/Video → Audio/Video: Playback
Updated•9 years ago
|
Assignee: nobody → jyavenard
Updated•8 years ago
|
Assignee: jyavenard → nobody
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•