forked from chromium/chromium
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
MSE: Add support for xHE-AAC nonkeyframe buffering
Updates FrameProcessor to: 1. Understand if it is currently handling a codec for which nonkeyframes are supported (specifically, only AAC with xHE-AAC profile in this CL.) 2. Enforce parse failure if a supported audio nonkeyframe sequence does not increase in PTS monotonically (as a major simplification to related buffering logic, and coherent with the supported underlying codec's restriction on decode order matching presentation order.) 3. Disallows an audio nonkeyframe from becoming a possible audio preroll buffer in HandlePartialAppendWindowTrimming. Updates SourceBufferStream and SourceBufferRange to: * Trust the upstream FrameProcessor to enforce (1) and (2), above. In particular, SourceBufferRange::GetBuffersInRange() and SourceBufferStream::TrimSpliceOverlap() no longer require all audio frames to be keyframes. This simplifies tracking whether or not each buffered frame is allowed to be a nonkeyframe (e.g. if it's AAC:xHE-AAC), since changeType uses the same SourceBufferStream and SourceBufferRanges across the bytestream or codec type changes. * Trivially make TrimSpliceOverlap a no-op if the beginning of the new buffers is a nonkeyframe. Otherwise, it would be infeasible to determine if the new buffers are coherently decodable when fed to the decoder after a possibly end-overlapped, previously buffered, frame. Includes (and tests) a further simplification: if an audio keyframe is fully outside the append window and the next continuous frame processed is a nonkeyframe, that previous audio keyframe is not used as preroll; it's dropped instead, and a keyframe at least partially within the append window is required to continue buffering. If this is an oversimplification, later CLs can attempt to more precisely handle this case. TEST=Includes new FrameProcessorTests. Manually tested with a private stream on Android P+ that seeking in a mixed keyframe/nonkeyframe MP4 xHE-AAC stream no longer caused decoder to emit logs about silence. BUG=1079034,1081952 Change-Id: I41010079041a14dca90e23660350d4cf2469bf2f Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2186205 Commit-Queue: Matthew Wolenetz <wolenetz@chromium.org> Reviewed-by: Dale Curtis <dalecurtis@chromium.org> Cr-Commit-Position: refs/heads/master@{#772400}
- Loading branch information
Showing
7 changed files
with
533 additions
and
38 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.