Sometimes skip-to-next-keyframe engages when we don't need it to; when if we just kept decoding a bit more, we'd be able to play all or at least more frames.
We tend to engage skip-to-next-keyframe more eagerly when switching streams, or exiting buffering. I'm not referring to what to do when the CPU/decoder is too slow to decode a video... There's not a lot we can do to win in that situation.
For fragmented files (only) Have MP4Reader ignore the aSkipToNextKeyframe flag and instead only skip if the current playback position is behind the next keyframe. This means we'll only drop frames that we can't actually play.
Since this requires knowledge of where the next keyframe is, it's not generalizable to other Readers, like the WebM and Ogg Readers, until their demuxers are changed to allow that to be exported. So this change only has affect for the MP4Reader while using the MoofParser.
A gtest. We can't land this until bug 1118593 is fixed, as MP4Demuxer::GetNextKeyframeTime() only works if we're using the MoofParser's SampleIterator, and we don't do that for CENC encrypted content since that fails on some files.
Will follow up with the gtest patch once edwin lands bug 1118597 (I meant bug 1118597 instead of bug 1118593 in comment 2).
ni? cpearce so I don't forget to land the test.
ni? rillian so we don't forget to uplift.
Requesting approval for this patch only.
[User impact if declined]: Video playback stalls on slower systems.
[Describe test coverage new/current, TBPL]: green on inbound.
[Risks and why]: This affects non-MSE mp4 playback. The main risk is that the new heuristic will play a sequence of still frames when it would have previously played smooth video.
Attachment #8551533 - Flags: approval-mozilla-beta?
Attachment #8551533 - Flags: approval-mozilla-aurora?
> bug 1118597 instead of bug 1118593 in comment 2).
> ni? cpearce so I don't forget to land the test.
Backed out for checktest failures.