[Cast] Limit frames in flight by duration, and not by number of frames.
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}
Showing
Please register or sign in to comment