Chromium Code Reviews Chromium Code Reviews
Issue
560223002:
[Cast] Limit frames in flight by duration, and not by number of frames. (Closed)
Description[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
Committed: https://crrev.com/5f2dd387974082aad17a8603308d1a6acc2bce8d
Cr-Commit-Position: refs/heads/master@{#295857}
Patch Set 1 #Patch Set 2 : rebase #Patch Set 3 : Fix PacketStorage DCHECK (64-->32 bits wraparound issue). #Patch Set 4 : Account for faster input than configured max FPS. #
Total comments: 6
Patch Set 5 : Reduce common functionality into FrameSender. #Patch Set 6 : Removed auto-eviction from PacketStorage, since that should never happen. #
Total comments: 14
Patch Set 7 : Tweaks addressing review comments on PS6. #
Total comments: 2
Patch Set 8 : Tweaks. #Messages
Total messages: 28 (8 generated)
|
