To M73: MSE: Reduce amount of frame flushing for common ByPts scenario

Previously, when buffering by PTS, almost all audio frames emitted by
FrameProcessor would be emitted singly, incurring significant overhead
of frequent SourceBufferStream::Append() calls of single frames versus
collections of frames, even when these audio frames really are

This change allows the duration of the current frame to be used as a
proxy for (roughly) half of the SourceBufferStream's buffering fudge
room, with the other half already built into the FrameProcessor's
MseTrackBuffer highest_presentation_timestamp(). Because
SourceBufferStream updates its (non-decreasing) fudge room at the start
of Append() servicing, this relaxation in FrameProcessor should not
introduce failures in adjacency checks during SBS::Append() (and
underlying SourceBufferRangeByPts) processing, while allowing simple
continuous-in-DTS (within MSE coded frame processing spec'ed adjacency
logic) and continuous-in-PTS (within our SourceBufferStream's fudge
room) keyframes to not be unduly Appended one-at-at-time to
SourceBufferStream. Note, this change is not specific to audio frames;
video keyframes also satisfying such continuity are also queued for bulk
flushing later in FrameProcessor.

Relevant unit tests now verify the specifics of group start signalling
and the sequence of append calls by FrameProcessor.

TEST=Multiple updated and new FrameProcessorTests

Change-Id: Ifcfe9fc2062888b1c835380871be355a45b0babe
Reviewed-by: Dan Sanders <>
Commit-Queue: Matthew Wolenetz <>
Cr-Commit-Position: refs/heads/master@{#627070}(cherry picked from commit d2ad5ce3165b485156ffff771a3e860b1ab78ad4)

Change-Id: I37f2fa8abe0bc54bca5eb0c248a4d2bed7115769
Reviewed-by: Matthew Wolenetz <>
Cr-Commit-Position: refs/branch-heads/3683@{#130}
Cr-Branched-From: e51029943e0a38dd794b73caaf6373d5496ae783-refs/heads/master@{#625896}
4 files changed