GitLab

FrameSender now decides whether to drop frames based on the media
duration in-flight (instead of the number of frames in-flight).  The
maximum allowed in-flight duration is the target playout delay plus the
one-way network trip time, the latter of which accounts for the time it
takes for an ACK to travel back from the receiver.

ShouldDropNextFrame() still limits by the number of frames in-flight,
but only so that a client cannot flood the FrameSender with frames at a
rate greater than the configured maximum frame rate.  Some burstiness is
allowed to mitigate false-positive detections.  In a typical session,
frames should never be dropped based upon the in-flight count.

This change also alters the design of PacketStorage where, instead of
being a fixed "large enough for anything" size, it only holds the frames
that are in-flight.  This is needed because we no longer limit by the
number of frames in-flight, and there's no way to determine what the
"large enough for anything" size has to be.  It's now the duty of
FrameSender to "cancel out" acknowledged frames, and of RtpSender to
release them from storage.

BUG=404813

Review URL: https://codereview.chromium.org/560223002

Cr-Commit-Position: refs/heads/master@{#295857}