Tight Loops, Smooth Streams: Responsive Congestion Control for Real-Time Video

To see how today’s production systems handle real-time video, we evaluate Google Congestion Control (GCC) [11], the rate control mechanism inside WebRTC, on a simple link. WebRTC is the engine behind browser-based real-time applications, including Google Meet and Microsoft Teams. We ran a recent version of WebRTC (M108 [16]) on an emulated link that alternates between $2\mathrm{Mbps}$ and $500\mathrm{Kbps}$ every 40 seconds. The minimum round-trip time (RTT) is $50\mathrm{ms}$, and the bottleneck buffer is large enough to avoid packet drops.

As shown in Fig. 2(a), GCC is sluggish when ramping up: at the start of the stream and again when the link recovers to $2\mathrm{Mbps}$ at $t=80$s, it takes 18 seconds to climb from $500\mathrm{Kbps}$ to $2\mathrm{Mbps}$, resulting in lower visual quality during that time (Fig. 2(b)). GCC is also slow to react to link drops: when the link rate falls to $500\mathrm{Kbps}$ at $t=40$s, frame latency spikes to over a second and takes 12 seconds to stabilize (Fig. 2(c)).

Contrast this behavior with traditional congestion control algorithms [7, 4, 8, 10] operating on backlogged flows that always have packets waiting to be sent. They respond to such network events much faster, typically over few RTTs. For instance, the “Backlogged Copa” lines in Fig. 2(a) shows that Copa [7] reacts quickly on the same time-varying link. This wide disparity raises the question: Why does state-of-the-art video rate control lag so far behind state-of-the-art congestion control?

In video rate controllers like GCC, the instantaneous rate on the wire is dictated by the frame sizes produced by the encoder (see Fig. 1(a)), unlike traditional CCAs, where the controller itself regulates the rate on the wire. GCC controls the video bitrate by adapting the encoder’s target rate, but the encoded frame sizes can be highly variable. The encoder achieves its target bitrate only on average–usually over several frames [21], and cannot immediately adapt to sudden changes. We illustrate this in Fig. 1(b) where we supply the VP8 encoder with a target bitrate that switches between $2\mathrm{Mbps}$ and $500\mathrm{Kbps}$ every 5s. Every time the bitrate goes up from $500\mathrm{Kbps}$ to $2\mathrm{Mbps}$, the encoder takes nearly 2 seconds to catch up. On the way down from $2\mathrm{Mbps}$ to $500\mathrm{Kbps}$, it takes about a second to lower the bitrate. The reason for this lag is that the size of an encoded frame depends on factors such as quantization parameters, the encoder’s internal state, and the motion in the video, and it is only known accurately after encoding [21]. The encoder tries to rectify over- and under-shootings by adjusting the quality of subsequent frames, thus, it shows significant per-frame variance around the average.

Because the encoder cannot match the target bitrate on a per-frame timescale, GCC cannot quickly reduce its rate when capacity drops. Instead, GCC has to be conservative and leave abundant headroom at all times. Even in the steady state, GCC limits utilization at about 85% and still experiences occasional latency spikes (Fig. 2(c)). Headroom lowers the risk of a latency spike during fluctuations but makes it difficult to track the available bandwidth accurately because it breaks the tight feedback loop from the network. For instance, GCC relies on delay gradients to estimate link rate, but when the link is underutilized, queues do not build and gradients provide no signal. As a result, GCC ramps up slowly to discover capacity. Recall that when GCC increases its target bitrate, the encoder takes a few seconds to catch up. GCC must wait for the video bitrate to increase before it knows if it is safe to increase it further, so the entire process takes 15–20 seconds to converge (Fig. 2(a)).

Video systems like WebRTC support simple probing mechanisms [49] that send padding traffic to test for extra bandwidth. For instance, GCC fires a periodic timer (e.g., every $5\mathrm{s}$) and injects padding packets to probe capacity. Such coarse probing cannot deliver precise rate control, which requires RTT-scale feedback. As shown in Fig. 17(a) (Appendix A), GCC behaves almost the same on the alternating link with or without this probing. We show that probing must be synchronized with the congestion controller to be effective.

As shown in Fig. 2(a), a backlogged flow using a state-of-the-art CCA, like Copa, can adapt to network capacity on RTT timescales while also controlling network queueing delay. A key reason is that such CCAs maintain a tight feedback loop, deciding on every RTT – and even on every ACK – how many packets to keep in flight [27]. Vidaptive’s core idea is to make video stream appear like a backlogged flow to the CCA to leverage their high throughput, low delay, and fast convergence. In Fig. 2, Vidaptive, using Copa for congestion control, achieves the same throughput and network delay as a backlogged Copa. Vidaptive ramps up quickly when bandwidth increases, delivering higher image quality than GCC (Fig. 2(b)). It also avoids GCC’s latency spikes (Fig. 2(c)) by reacting fast to bandwidth drops.

Vidaptive sends packets on the wire according to the congestion controller’s feedback loop. When the encoder overshoots the capacity, Vidaptive queues excess video packets and only sends them when congestion control allows (e.g., based on the congestion window and in-flight packets for window-based CCAs). When the encoder undershoots the available capacity, Vidaptive sends “dummy packets” to maintain the sending rate requested by the controller.²²2This dummy traffic could also be repurposed for helpful information such as forward error correction (FEC) packets [43, 37, 29] or keyframes for faster recovery from loss. We leave such enhancements to future work and focus solely on the impact of dummy traffic on video congestion control. This design preserves the CCA’s feedback loop, so it continues to behave as if it were serving a backlogged flow. Our evaluations show that, contrary to the common belief that dummy traffic “seldom works for real-time video” [57], careful use of it in our design improves video bitrate while keeping latency low.

By decoupling the congestion controller’s fine-grained feedback loop from the encoder’s variable output, Vidaptive can accurately track time-varying bottleneck rates independent of video traffic  –  something GCC and other rate controllers, which rely on video traffic for estimation, cannot do. Still, we must align the video bitrate with the controller’s sending rate to ensure good quality and latency.

Despite estimating the link rate accuracy, controlling the frame latency is challenging due to encoder and link rate variability. We show why using a simplified idealized example (Fig. 3). At time $t$, let the CCA’s measured link capacity be $C(t)$. Assume that we set the encoder’s target bitrate to $C(t)$ and it immediately outputs a frame of size $C(t)\mathrm{\Delta }+\sigma (t)$, where $\mathrm{\Delta }$ is the frame interval and $\sigma (t)$ captures output variability. If no other data is in flight, the frame transmission time $T(t)$ satisfies the following:

Fig. 3 shows frame size as the area under the capacity curve. Network fluctuations can push $T(t)$ beyond acceptable limits. This issue stems from traditional video codecs: once a frame is encoded it cannot be changed. The sender then has two choices: send the oversized frame and cause delay, or drop it and restart with a keyframe, which usually produces an even larger frame [21].

Consequently, it not possible to increase the video bitrate without affecting the tail latency. Pushing the target bitrate too close to link capacity risks latency spikes during sudden capacity drops. For example, a frame that takes $33\mathrm{ms}$ to transmit on a $2\mathrm{Mbps}$ link needs $132\mathrm{ms}$ if the rate suddenly falls to $500\mathrm{Kbps}$, leading to an unavoidable increase in latency.

To bound latency, we must reserve headroom and allocate only a fraction of measured capacity to video. Vidaptive does this by setting the encoder’s target bitrate to $\alpha (t)\cdot C(t)$, where . Vidaptive has an online algorithm that tracks frame transmission times and adapts $\alpha (t)$ so the latency stays within a desired bound. Doing so, Vidaptive handles both network and encoder variability (i.e., $\sigma (t)$) simultaneously. Another interesting advantage of this algorithm is that users can tune their desired latency upper bound and allow for a tradeoff between video quality (size of the frames) and latency by tuning $\alpha$.

Vidaptive uses a delay-controlling window-based congestion control algorithm to determine when to send packets³³3We exclude buffer-filling CCs such as TCP Cubic from our focus due to their tendency to build large queues and increased latency.. The congestion window (cwnd) limits the maximum number of in-flight bytes between the sender and the receiver. The sender keeps track of the number of bytes in flight and only sends out new packets if the amount in-flight is less than cwnd. Vidaptive can use any CCA that controls delay effectively. Our focus is not on designing a new CCA; fortunately, several excellent algorithms already exist. We use two recently proposed algorithms, Copa [7] and RoCC [4] in our implementation. Most of our results use Copa, which keeps a tight check on the network delay, reacts to changes quickly, and maintains high utilization. Vidaptive’s sending behavior is identical to its underlying CCA (§2.2), so it inherits these properties as well as the flow-level fairness characteristics of the CCA.

Beside enforcing the cwnd constraint, the sender also paces the packet transmissions at the CCA’s sending rate (CC-Rate), computed as the cwnd divided by smoothed RTT (a weighted moving average of RTT samples). Since the encoder’s output bitrate may overshoot the available capacity (§2.1), the Pacer is responsible for avoiding a sudden burst of packets.

Our goal is to reshape the video traffic as a backlogged flow to enable the CCA to track changes in available bandwidth quickly and accurately (§2.2). To this end, we generate “dummy packets” if the CCA is ready to send a packet as if the stream as backlogged, but no video packets are available in the Pacer. Dummy packets are strictly lower priority and are sent judiciously and with respect to delays; they are only sent if the Pacer queue is empty and congestion control detects free bandwidth. To limit unnecessary traffic, dummy packets are withheld if the next frame is expected soon – specifically, within 25% of the inter-frame time ($8.25\mathrm{ms}$ for $30\mathrm{FPS}$) in our implementation. The benefit of this mechanism is that if the network is about to drop, the dummy packets sent a few milliseconds before a frame will cause a higher queuing delay in the network. On the other hand, if the network rate increases, skipping a few milliseconds of traffic does not noticeably slow the controller’s reaction.

Finally, dummy packets are disabled once the video reaches its maximum achievable bitrate ($12\mathrm{Mbps}$ in our experiments).⁴⁴4Our analysis of the 1080p videos within our dataset showed that the peak bitrate typically reached was around $12\mathrm{Mbps}$, so for this collection of videos, $12\mathrm{Mbps}$ represents the upper limit of bitrate. . Beyond this point, extra traffic would not improve video quality or reveal useful bandwidth information.

The encoder can overshoot and produce oversized packets (§2.1). To control the latency, Vidaptive monitors how long packets sit in the pacer queue before being sent. If the oldest packet waits longer than a certain pause threshold ($\tau$), we pause encoding of frames, and only resume it only once the pacer queue has drained. We set $\tau$ = $33\mathrm{ms}$ by default in our implementation for a camera rate of $30\mathrm{FPS}$, thereby pausing encoding if packets from the previous frame remain unsent. The intuition is that there is no point in encoding a new frame that would have to sit in the Pacer queue, waiting for an old frame to finish transmission. Instead, we always encode and transmit fresh frames when they have a high chance of reaching the receiver with acceptable latency. Note that a high delay through the Pacer queue reflects congestion at the bottleneck link. If we ignore CC-Rate and transmit the packets stuck in the Pacer queue (as currently implemented in WebRTC), they would still have to wait at the bottleneck link, and clearing them would take longer when the link bandwidth improves.

To estimate the frame transmission time, we measure the frame service time: the interval from when the first packet of a frame arrives at the front of the pacer until its last packet is sent out on the network. The frame service time depends on both CC-Rate and frame sizes. As a result, it is impacted by fluctuations in both the encoder’s output and in the CC-Rate. These fluctuations are out of our control and can be viewed as exogenous noise. However, we can influence the expected frame sizes by controlling the encoder’s target bitrate. The crux of our method is to pick the target bitrate in a way that controls the distribution of frame service times. Vidaptive measures the frame service time for each frame in the Pacer.

Consider $N$ frames over a duration $D$, each with a service time $d_i$ for $i\in 1,2,\mathrm{\dots },N$. The distribution of $d_i$ informs us about the frame latencies. If the camera’s frame rate is $f_{max}$ (typically $30\mathrm{FPS}$), the frame interval is $\mathrm{\Delta }=\frac{1}{f_{max}}$ (typically $33\mathrm{ms}$). For maximum efficiency, service times should be close to, but less than, $\mathrm{\Delta }$, so that the last packet of a frame is sent just as the next frame is encoded. For example, if the ${80}^{th}$ percentile of the $d_i$ distribution is larger than $\mathrm{\Delta }$, then 20% of the frames take more than a frame interval (see Fig. 3). These frames increase the delay of subsequent frames and may trigger latency safeguard (§3.2), which skips frames. A heavy-tailed distribution of $d_i$ values directly translates into high tail latency of video frames.

Suppose the encoder is given a target bitrate $\alpha \cdot \text{CC-Rate}$, where . A larger $\alpha$ produces larger frames and longer service times $d_i$, so $d_i$ is function of $\alpha$. Our goal is to find $\alpha$ to control the latency, or:

where $\lambda \in {ℝ}_{(0,1]}$ is the chosen percentile for latency control. In plain terms, the goal is to align the $\lambda$-th percentile of service times with the desired target $P$. Real-time applications typically use a high $\lambda$ (e.g., $\lambda =0.9$) to bound latency tail. For example, $\lambda =1$ focuses on worst-case latency. The parameter $P$ expresses the tradeoff between quality and latency. Choosing $P$ closer to $\mathrm{\Delta }$ drives frame service times to $\mathrm{\Delta }$, increasing the video bitrate to near capacity. This increases video quality at the cost of potentially higher latency. When $P$ is picked smaller than $\mathrm{\Delta }$ (e.g., $P=\frac{\mathrm{\Delta }}{2}$) the target bitrate values are chosen conservatively, resulting in lower latency and potentially lower quality.

Ideally, we would solve Equation 2 over future frames. But modeling $d_i$ for unseen frames is difficult because it depends on both future video content (e.g., motion) and future changes in CC-Rate. Instead, we choose $\alpha$ based on the observed service times of recent frames.

Suppose we have frame service times $d_i$ for $i\in \{1,2,..,N\}$ measured over the last $D$ seconds. We want to know what value of $\alpha$ would have achieved Equation 2 for these frames? If $t{r}_i$ is the target bitrate used to encode frame $i$, had frame $i$ been encoded by $\alpha \cdot \text{CC-Rate}$ instead, the frame service time would have been

We refer to $\widetilde{d_i}(\alpha )$ as the counterfactual service time for frame $i$. This estimate assumes that frame size is proportional to the target bitrate (and hence proportional to $\alpha$) and that changing the target bitrate would not have changed CC-Rate.⁵⁵5This holds because Vidaptive decouples CC-Rate from the encoder. Using these counterfactual service times, we can now find $\alpha$ in Equation 2.

Fig. 5 shows an example of this counterfactual problem for $\lambda =0.9$. Fig. 5(a) shows the frame service time samples and their ${\lambda }^{th}$ percentile (red line). The samples that are less than $P=\mathrm{\Delta }$ are colored in blue, and those larger than $P$ (which would cause higher latency) are colored in red. Fig. 5(b) shows the distribution of $d_i\frac{\text{CC-Rate}}{t{r}_i}$ (called as normalized $d_i$) and its ${\lambda }^{th}$ percentile (denoted by $x$). Here, $\alpha$ is set to $\frac{P}{x}$. Fig. 5(c) shows the counterfactual frame service time values, $\widetilde{d_i}$, had $\alpha$ been used to encode them. The scaled-down $\widetilde{d_i}$ values reduce the number of outliers above $P$ (decreasing the latency).

$\alpha$ controls the headroom between the encoder’s target bitrate ($\alpha \cdot \text{CC-Rate}$) and the estimated network rate (CC-Rate). Vidaptive automatically adjusts $\alpha$ to cope with variability caused by both changing video content and fluctuating network rates. Fig. 6 illustrates this behavior in three scenarios, all with $\lambda =0.9$ and $P=33$ ms.

Fig. 6(a) shows the values of $\alpha$ and the ratio of frame service time to $\mathrm{\Delta }=33ms$. In steady conditions, $\alpha$ has a stable value of $\sim 1$ and the P90 of the frame service times is below $33\mathrm{ms}$. Next, we test Vidaptive on the same link with a high-motion video [54] in Fig. 6(b). The encoded frame sizes and the frame service times are now much more variable. Consequently, $\alpha$ adapts to the variable encoder output by switching to a lower value to control the tail of frame service times. Finally, we run Vidaptive on a $1.5\mathrm{Mbps}$ link that experiences 10s of high variability in Fig. 6(c). Before the fluctuations start at 10s, frame service time values are well below $\mathrm{\Delta }$ with $\alpha \sim 1$. During the noisy period (10s–20s), when the frame service times increase, $\alpha$ decreases to improve the P90 of frame service time and reduce video bitrate. When the link steadies after the 20s, $\alpha$ resets to its high value.

We built a testbed, implemented in C++, on top of WebRTC [16] that runs a headless peer-to-peer video call between two endpoints. The sender program emulates a camera by reading video frames from an input file and the receiver records the received frames to an output file. To match video frames between the sender and the receiver for visual quality and latency measurements, a unique 2D barcode is placed on each frame [21]. We emulate different network conditions between the sender and receiver by placing the receiver behind a Mahimahi shell. All experiments are run for $2\min$ on a link with a one-way delay of $25\mathrm{ms}$.

To assess the performance of Vidaptive, we focus on two key metrics: frame quality and frame latency. For frame quality, we use Video Multimethod Assessment Fusion (VMAF [38]), comparing received frames to their original sources. Additionally, we report Structural Similarity Index Measure (SSIM [47]), and report the Peak Signal-to-Noise Ratio (PSNR [24]) in Appendix Fig. 20. We measure frame latency by the duration from frame read at the sender to frame display at the receiver. We set the display time for undelivered frames to the presentation time of the next frame displayed [21]. In addition, we report the total video bitrate and frame rate at the receiver.

We evaluate each scheme on a set of 15 cellular traces bundled with Mahimahi [39] and also use synthetic traces to illustrate the convergence behavior in Appendix C. For the cellular traces, we use a large bottleneck buffer size that does not incur packet loss. We also evaluate each scheme on three Pantheon’s calibrated network emulation traces [52]. These traces were tuned to mimic real Internet paths. They have limited buffers (and thus incur congestion-induced loss) as well as stochastic packet loss.

We use a dataset of 20 different 1080p videos, each playing at 30 frames per second. The dataset is curated from YouTube and spans different levels of motion intensity across sports, cooking, video conferencing, nature documentaries, live performances, and screen sharing. Unless specified otherwise, all experiments are conducted on the complete set of videos from this dataset. Audio is disabled throughout the experiments. See Tab. 1 in appendix for detail.

We benchmark Vidaptive against several established congestion control algorithms to highlight its performance for real-time video over variable links. First, we consider the Google Congestion Control (GCC) algorithm, the standard for many real-time applications [11, 48]. The GCC protocol has changed since publication [11]; we used the latest implementation in the M108 [16] version of WebRTC. Additionally, we compare Vidaptive to Performance-oriented Congestion Control (PCC), another rate-based approach [17]. We include analysis against Copa, a state-of-the-art delay-based congestion control algorithm [7]. All algorithms are implemented within the same framework.

In Fig. 7, we compare Vidaptive against GCC, PCC, and Copa on the cellular traces bundled with Mahimahi [41]. The figure shows cumulative distribution functions (CDFs) for VMAF, SSIM, and frame latency across all traces and frames. Compared to GCC and PCC, Vidaptive consistently delivers higher visual quality. It raises the average VMAF to 53.5% (vs. $\sim$39% for GCC and PCC) and the median (P50) VMAF to 58.2% (vs. 36.8% for GCC and 33.4% for PCC). For SSIM, Vidaptive improves the average to $14\mathrm{dB}$ (vs. $12\mathrm{dB}$) and the median to $13.8\mathrm{dB}$ (vs. $12\mathrm{dB}$). These quality increase is thanks to Vidaptive’s effective link utilization.

Although Copa achieves higher VMAF and SSIM scores than Vidaptive, it suffers from significantly higher latency (e.g., an average of 2.9 seconds), making it impractical for real-time video. The issue is that, with video traffic, Copa is application-limited for most of the time. Copa is designed for backlogged flows and does not interact well with video streams: during periods of video silence, it observes no queuing delay and grows its congestion window to its maximum cap, even though no packets are in flight. When the network rate later drops, this inflated window causes excessive queuing and delay. In contrast, Vidaptive also uses Copa as its underlying CCA, but reshapes the video source to behave backlogged, thus preserving Copa’s responsiveness and effectively controlling latency.

Vidaptive significantly improves tail frame latency, particularly beyond the ${75}^{\text{th}}$ percentile. These higher percentiles correspond to conditions with severe link variability and outages, where Vidaptive reacts faster thanks to its tight congestion-control feedback loop. At the ${95}^{\text{th}}$ percentile, for example, Vidaptive reduces frame latency by $2246\mathrm{ms}$ relative to GCC, cutting it from $3941\mathrm{ms}$ to $1695\mathrm{ms}$. It also improves average latency by $351\mathrm{ms}$ ($383\mathrm{ms}$ vs. GCC’s $734\mathrm{ms}$). Compared to PCC, Vidaptive lowers both the average latency ($383\mathrm{ms}$ vs. $521\mathrm{ms}$) and the median latency ($65\mathrm{ms}$ vs. $81\mathrm{ms}$). Vidaptive has a slightly higher median latency than GCC ($65\mathrm{ms}$ vs. $48\mathrm{ms}$), caused by Vidaptive ’s always-on probing, which maintains a small standing queue to preserve tight feedback. Prior work shows that latencies well under $100\mathrm{ms}$ are generally imperceptible to users [14, 15], so this small increase has little practical impact.

Fig. 8 summarizes the tradeoffs between video quality and latency by plotting the average VMAF and P95 frame latency of Vidaptive across all videos for each cellular trace. Each point corresponds to a trace. Overall, Vidaptive consistently improves either quality, latency, or both compared to all baselines.

Against GCC, Vidaptive delivers higher VMAF in 80% of traces and reduces P95 latency in half of them; in the remaining half, it increases P95 latency by less than $100\mathrm{ms}$, a negligible penalty given the quality gains [15]. Compared to Copa, Vidaptive reduces P95 latency by about one second across all traces. Relative to PCC, Vidaptive lowers P95 latency in 86% of traces (13 out of 15) and achieves higher VMAF in 14 out of 15 traces.

We further evaluate Vidaptive on three calibrated emulated paths from Pantheon [52], which approximate real Internet routes. Unlike the Mahimahi cellular traces, these paths have constant capacity with Poisson packet delivery, but introduce loss and shallow tail-drop queues. We test on three representative traces – “Nepal to AWS India (Wi-Fi)” [3], “Mexico to AWS California (Cellular)” [2], and “AWS Brazil to Colombia (Cellular)” [1] – using five videos.

Fig. 9 shows that Vidaptive achieves substantially higher quality than GCC, with a median VMAF of 44% vs. 15% and an average of 40% vs. 29%, while both reach a P95 of 79%. Against PCC, Vidaptive achieves higher VMAF across all percentiles.

In terms of latency (Fig. 9), Vidaptive reduces P95 latency by $933\mathrm{ms}$ (1739 $\to$ 806) and average latency by $89\mathrm{ms}$ (362 $\to$ 273) compared to GCC, at the cost of a modest $19\mathrm{ms}$ increase in median latency (137 $\to$ 156). This small rise is consistent with our cellular-trace results and reflects the shallow standing queue that Copa, Vidaptive ’s underlying CCA, maintains to track bandwidth. Compared to both PCC and Copa, Vidaptive achieves strictly lower latency at all percentiles.

To show that Vidaptive can work with other delay-sensitive window-based CCA, we replaced Copa with RoCC [4]. Fig. 13(a) shows the VMAF and Fig. 13(b) shows the latency CDFs of Vidaptive (RoCC) compared to GCC. Vidaptive (RoCC) follows similar trends as Vidaptive (Copa) and improves the quality in all percentiles compared to GCC. Compared to GCC, Vidaptive (RoCC) increases the median latency from $48\mathrm{ms}$ to $77\mathrm{ms}$ while reducing the P95 of latency from $3.9\mathrm{s}$ to $1.9\mathrm{s}$. Compared to GCC, Vidaptive (RoCC) increases the median VMAF from 36 to 56 and the average VMAF from 39% to 53%. Copa overall has a lower latency than RoCC, so we choose it as the default CCA in Vidaptive.

To understand the impact of different components in Vidaptive’s design, we evaluate the benefits of adding dummy traffic at the transport layer (§3.1), having the latency safeguards (§3.2), and running the encoder bitrate selection approach described in §3.3. Fig. 14 shows the distribution of metrics over all the traces and five videos for different system variations. $P$ is selected as $33\mathrm{ms}$ for the rest of experiments.

In “Copa,” we replace GCC with a window-based congestion control algorithm but keep the remaining modules similar to GCC. Copa is more aggressive than GCC in utilizing bandwidth, improving the average link utilization and video bitrate by almost $3\times$. However, this aggressiveness causes an average P95 latency of 9 seconds. The frame rate for all schemes using Copa as CCA reduces because Copa’s window-based mechanism, unlike GCC, blocks frame transmissions when network is congested.

In “Vidaptive w/o Dummy,” we removed dummy traffic (§3.1) from Vidaptive. Fig. 14(b) shows that removing the dummy traffic reduces the average video bitrate from $2\mathrm{Mbps}$ to $1.4\mathrm{Mbps}$ and its P95 from $5.1\mathrm{Mbps}$ to $2.8\mathrm{Mbps}$. However, the average P95 latency and the frame rate do not change significantly compared to Vidaptive: the average P95 latency decreases by only 5.6% when dummy traffic is removed (from $1894\mathrm{ms}$ to $1788\mathrm{ms}$). This slight increase results from CCA keeping a small queue in the network when it uses dummy traffic that causes a bigger spike (and P95 latency) when the network degrades abruptly. This result indicates that the dummy traffic has a negligible impact on latency but it improves the video bitrate by helping CCA maintain its loop to discover bandwidth faster.

In “Vidaptive w/o Latency,” we disable the latency safeguards on top of Vidaptive. Disabling latency knobs hurts the P95 latency (Fig. 14(c)) and increases it compared to Vidaptive ($1894\mathrm{ms}$ vs. $6087\mathrm{ms}$ on average and $8.6\mathrm{s}$ vs. $26\mathrm{s}$ in P95). Since the latency safeguards pause encoding of frames, the overall frame rate and video bitrate increases without them.

In “Vidaptive w/o Bitrate Selection,” we disable the encoder bitrate selection of Vidaptive (module choosing $\alpha$ in §3.3). Without this mechanism, the CCA’s link estimate is directly given to the encoder, which results in a higher video bitrate and latency in highly variable links. When CC-Rate is fed directly to the encoder, it attempts to produce frames that take $33\mathrm{ms}$ to be sent at the current link rate. However, if the link rate drops, such an encoded frame takes more than $33\mathrm{ms}$ to be transmitted. This, in turn, triggers the latency safeguards that drop the next frames to prevent the latency from increasing. As a result, the frame rate in “Vidaptive w/o Bitrate Selection” is lower than Vidaptive.

Finally, in “Vidaptive”, the system aims to find the right target video bitrate for the encoder as described in §3.3. Because this system balances frame latency and frame quality, the video bitrate is slightly lower than “Vidaptive w/o Latency” and “Copa” but achieves better latency. The utilization is comparable across all schemes with dummy traffic since it pads any encoder output to match the link rate.

Another system variation is disabling the dummy traffic and removing the pacer. Instead of controlling the frame service time, this system applies the bitrate selection scheme described in §3.3 on the measured one-way frame latencies. We call this “Latency Optimizer”. It picks the next target bitrate based on the measured frame latencies and corresponding target bitrates. Fig. 15 compares the Latency Optimizer, Vidaptive, and GCC for $\lambda =0.5$ and $\lambda =0.9$. For $\lambda =0.9$. “Latency Optimizer” opts to control P90 of measured latencies, and although the latency values are low, the quality drops significantly even compared to GCC. For $\lambda =0.5$, “Latency Optimizer” targets a median latency of $33\mathrm{ms}$, but the tail latency increases compared to Vidaptive and GCC without meaningful gains in quality. This approach fails because bitrate selection alone reacts too slowly to rapid link variations (issue similar to §2.1): it relies on latency samples that arrive only once every $33\mathrm{ms}$, making it sluggish to raise the bitrate when bandwidth increases and equally slow to cut bitrate during sharp capacity drops.

Salsify’s design takes advantage of a specialized video codec that allows it to discard already-encoded frames when necessary. Since the peak performance of this encoder was 24 FPS at 720p, we focus specifically on videos of this size and frame rate. Fig. 16 shows the CDF of VMAF and latency across all the frames. Although Salsify exhibits a higher quality (Fig. 16(a) and Fig. 16(c)), it also experiences much higher latency compared to Vidaptive (Fig. 16(b)). The median latency for Salsify is $119\mathrm{ms}$, and the average latency is $1211\mathrm{ms}$ across all the frames ⁶⁶6We are evaluating Salsify on a larger set of traces than Salsify’s paper.. However, Vidaptive has a median latency of $67\mathrm{ms}$, $77\mathrm{ms}$, $117\mathrm{ms}$ and average latency of $468\mathrm{ms}$, $535\mathrm{ms}$, and $622\mathrm{ms}$ for $P=20,33,66$ respectively. Fig. 16(d) shows the P95 latency distribution across all the videos and traces. Salsify experiences seconds higher P95 latency than Vidaptive.

Fig. 16(e) shows the frame rate for Salsify and Vidaptive. Salsify’s primary means of latency control is dropping frames, which manifests itself in lower frame rate. As $P$ increases in Vidaptive, we also have to skip more frames to keep the latency in control.

We also evaluated the effect of different parameter choices in Appendix B. As $\lambda$ (the latency percentile used in §3.3) increases, both video bitrate and latency decrease. Increasing the pacer pause threshold ($\tau$ in §3.2) leaves the video bitrate unchanged, but raises the P95 latency and lowers the frame rate.