Closed
Bug 1120243
Opened 10 years ago
Closed 9 years ago
MediaCodecReader does not skip demux when doing skip-to-next-keyframe
Categories
(Core :: Audio/Video: Playback, defect)
Tracking
()
RESOLVED
INVALID
People
(Reporter: cpearce, Assigned: bechen)
References
Details
Attachments
(1 file)
3.30 KB,
patch
|
Details | Diff | Splinter Review |
The MediaCodecReader has the same problem that the MediaOmxReader has in its skip-to-next-keyframe implementation; when skipping-to-next-keyframe the MediaCodecReader actually *decodes* to the next keyframe, it does not seek the video stream to the next keyframe and resume decoding from there, which is what it's supposed to do. This means skip-to-next-keyframe will be slow, and actually make performance *worse*.
I noticed this while reviewing bug 1114910. All I think needs to happen is we need to set mVideoTrack.mSeekTimeUs=aTimeThreshold before calling FillCodecInputData(mVideoTrack) in MediaCodecReader::DecodeVideoFrameSync().
We probably also need to add a flag to mVideoTrack (which we also set in the skip-to-next-keyframe path of DecodeVideoFrameSync()) so that when we perform the seek for skip-to-next-keyframe, we call MediaSource::ReadOptions::setSeekTo() we pass in SEEK_NEXT_SYNC.
I blogged about skip-to-next-keyframe here:
http://blog.pearce.org.nz/2014/12/firefox-video-playbacks-skip-to-next.html
Reading and understanding that blog post will help you understand how skip-to-next-keyframe should be implemented.
Assignee | ||
Comment 1•10 years ago
|
||
Perfrom seek with SEEK_NEXT_SYNC when the flag skip-to-next-keyframe is true, I'm going to measure the performance we improve or not about patch.
Assignee | ||
Comment 2•10 years ago
|
||
(In reply to Benjamin Chen [:bechen] from comment #1)
> Created attachment 8582846 [details] [diff] [review]
> bug-1120243.v01.patch
>
> Perfrom seek with SEEK_NEXT_SYNC when the flag skip-to-next-keyframe is
> true, I'm going to measure the performance we improve or not about patch.
Regardless the bug due to this patch (hang), the seek operation usually takes about 20~40ms. It makes the performance worst. I guess it is because the time threshold is smaller than 20~40ms.
Updated•10 years ago
|
Component: Audio/Video → Audio/Video: Playback
Assignee | ||
Updated•9 years ago
|
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•