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)

x86_64
Gonk (Firefox OS)
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: cpearce, Assigned: bechen)

References

Details

Attachments

(1 file)

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.
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.
(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.
Component: Audio/Video → Audio/Video: Playback
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.

Attachment

General

Created:
Updated:
Size: