Skip to content

NETFLIX Tier 1

Read original ↗

Netflix — Smarter Live Streaming at Scale: Rolling Out VBR for All Netflix Live Events

Netflix Live Encoding + Live CDN (Renata Teixeira, Zhi Li, Reenal Mahajan, Wei Wei) document the 2026-01-26 fleet-wide cutover of all Netflix Live events from CBR to capped VBR (QVBR). The post is one of the first public Netflix retrospectives on a live-streaming encode-pipeline change and walks three orthogonal consequences: (1) the efficiency + quality wins VBR delivers at Netflix scale, (2) the stability hazard VBR introduces because aggregate server traffic stops being a faithful proxy for how "full" a server is, and (3) the bitrate ladder re-tuning needed to match CBR quality rung-by-rung after the mode switch. Implementation substrate: AWS Elemental MediaLive's QVBR setting. Fleet delivery substrate: Open Connect.

Summary

Until 2026-01-26, every encoded Live stream at Netflix ran at a configured nominal bitrate with actual bytes/sec close to that target second-by-second — CBR. A 1080p / 5 Mbps stream sent ≈5 Mbps of data whether the scene was a static talking-head or a fast-moving crowd shot. This made capacity planning easy: if a server could carry ≈100 Gbps of Live traffic and each stream averaged ≈5 Mbps, the server could safely admit ≈20,000 concurrent sessions, and aggregate traffic moved only when concurrency moved.

But CBR is "spending the same bits on the waiting room as on the confetti shot" — visibly wasteful on easy scenes and visibly insufficient on hard ones. VBR flips the encoder objective from "target bitrate" to "target quality": bitrate rises when content is hard to compress and falls when content is easy. AV1's per-scene flexibility is an obvious fit. Netflix's Live pipeline implements this via QVBR in MediaLive, a cap- constrained variant of VBR that lets the bitrate swing freely under a hard ceiling.

Measured wins across multiple live-event A/Bs vs CBR at matched quality: ≈5% fewer rebuffers per hour, ≈15% fewer bytes transferred on average, ≈10% lower traffic at the peak minute. The per-event framing matters — WWE RAW is used as the worked example: on the same 8 Mbps nominal stream, CBR holds the bitrate wobble narrow around 8 Mbps, while VBR drops below 1 Mbps on the waiting-room scene and peaks well above 8 Mbps on the confetti shot.

The wins come with two structural problems Netflix had to solve before the cutover.

Problem 1 — aggregate traffic stops being a faithful capacity signal. Under CBR, "current Gbps on the wire" was a good proxy for how full a server was, and traffic-steering logic safely admitted new sessions while headroom existed. Under VBR, a 5 Mbps stream that's temporarily down-encoding at 2 Mbps fools the steering logic into seeing a half-empty server; if the steering logic keeps admitting sessions, then when the confetti shot arrives and every stream jumps to 7–8 Mbps simultaneously, the link or NIC can saturate, latency climbs, packets drop, and devices stall or downshift quality. Fix: reserve capacity against the stream's nominal bitrate, not its instantaneous bitrate — treat every admitted VBR session as if it could return to its nominal rate, which by construction matches what the CBR steering logic used to assume. This restores admission-control behaviour to CBR-equivalent while letting the bytes-on-wire benefit from the VBR efficiency gain.

Problem 2 — CBR and VBR at the same nominal bitrate are not the same average bitrate, so blindly reusing the CBR ladder loses quality on low rungs. The encoder spec isn't target bytes, it's target quality; a VBR encode at nominal 8 Mbps often averages well below 8 Mbps, especially on simpler scenes. Netflix's offline VMAF analysis and A/B confirmation showed ≈1 VMAF point loss on the bottom rungs of the ladder when CBR settings were reused verbatim. Fix: VMAF rung-by-rung ladder matching — bump the VBR nominal bitrate on each rung just enough to close a more-than-≈1-VMAF-point gap vs the CBR rung. Higher-bitrate rungs (the 8 Mbps example in the post) were left unchanged; the lifts landed on the bottom rungs. Result: VBR ladder matches CBR quality rung-by-rung yet still emits lower overall traffic because the per-second bitrate drops during easy scenes.

Forward work stated: (a) feed upcoming segment sizes into device-side ABR algorithms so the player can react to actual VBR behaviour in the next few seconds rather than relying on nominal labels; (b) apply a measurement-informed "discount" on nominal-bitrate capacity reservation to free up additional headroom without sacrificing stability.

Key takeaways

  1. Netflix cut all Live events from CBR to capped VBR on 2026-01-26. "On January 26, 2026, we flipped an important switch for Live at Netflix: all Live events are now encoded using VBR (Variable Bitrate) instead of CBR (Constant Bitrate)." (Source: sources/2026-04-02-netflix-smarter-live-streaming-vbr-at-scale)

  2. VBR's efficiency wins across multiple A/B tests, at matched quality, vs CBR. "Across multiple A/B tests on different Live events, we observed about 5% fewer rebuffers per hour, while transferring roughly 15% fewer bytes on average and around a 10% reduction in traffic at the peak minute." Three-axis production win: smoother playback (–5% rebuffers/hr), cheaper delivery (–15% avg bytes), lower peak burden (–10% peak traffic). Peak-minute traffic is the Open Connect capacity-planning metric, so the peak reduction has direct CDN-provisioning value. (Source: sources/2026-04-02-netflix-smarter-live-streaming-vbr-at-scale)

  3. CBR is wasteful on easy scenes and insufficient on hard ones — VBR targets quality, not bitrate. "A talking-head segment in a studio or a simple animation is much easier to compress than a sequence of rapid camera moves and fast-moving athletes in front of a highly detailed crowd. With CBR, both the easy and the hard segments get the same bitrate. In simple scenes, we spend more bits than we need; in complex scenes, we sometimes don't spend enough." Clean canonical framing of why CBR's simplicity is a pricing-model mismatch for real content. (Source: sources/2026-04-02-netflix-smarter-live-streaming-vbr-at-scale)

  4. The implementation is capped VBR, specifically MediaLive QVBR. "The more general idea is often referred to as capped variable bitrate, or capped VBR… In our live pipeline, we currently use AWS Elemental MediaLive, where this 'capped' VBR is implemented using the QVBR (Quality-Defined Variable Bitrate) setting." Capped-VBR is the production-safe variant: unbounded VBR can spike arbitrarily on hard scenes; QVBR caps the instantaneous rate so worst-case traffic stays bounded, preserving the fleet-safety property. First canonical wiki instance of MediaLive in a Netflix role and of capped VBR / QVBR. (Source: sources/2026-04-02-netflix-smarter-live-streaming-vbr-at-scale)

  5. VBR breaks "current Gbps = how full the server is" capacity-planning logic. Under CBR, "a 5 Mbps stream is effectively that: on a per-minute basis, traffic is remarkably flat. A server that is comfortably handling, say, ten thousand such sessions now is likely to still be comfortable in a minute, barring a wave of new joins." Under VBR, the same 5 Mbps stream may currently emit 2 Mbps (or less) on an easy scene, tricking steering logic into admitting more sessions — which then overload the link when the scene gets hard. "If the server has admitted many additional sessions during the preceding low-bitrate period, the aggregate traffic can suddenly exceed what the network link or NIC can sustain. Latency rises, packets are dropped, and devices start to experience stalls or quality downshifts. In extreme cases, this pattern of 'bitrate dips followed by spikes' can destabilize parts of the system." First canonical wiki statement of the admission-control-proxy-invalidation hazard specific to variable-bitrate traffic. Generalises beyond video: any admission controller that uses current throughput as a proxy for capacity is hazardous when load is multi-modal or correlated. (Source: sources/2026-04-02-netflix-smarter-live-streaming-vbr-at-scale)

  6. The fix: reserve capacity against nominal bitrate, not current bitrate. "Our fix was to change how we decide whether a server can take more sessions. Instead of basing that decision only on current traffic, we reserve capacity based on each stream's nominal bitrate, not just what it happens to be using at that moment. Even if a VBR stream is currently in a very cheap, low-bitrate phase, we still treat it as something that can quickly return to its nominal rate. This keeps our traffic-steering behavior consistent between CBR and VBR and avoids the key failure mode where a server accepts too many sessions during a long low-bitrate period and then becomes overloaded when bitrate rises again." Canonical patterns/nominal-bitrate-admission-control instance — reserve-against-headroom-label rather than reserve-against-current-usage. Preserves the benefit (fewer bytes average + fewer bytes peak) while keeping the CBR-equivalent safety property for fleet steering. (Source: sources/2026-04-02-netflix-smarter-live-streaming-vbr-at-scale)

  7. "Same nominal bitrate" does not imply "same average bitrate" between CBR and VBR. "Both encodes have the same nominal bitrate, but the figure shows how differently they behave. The CBR encode stays clustered around 8 Mbps with frequent short spikes, while the VBR encode often drops far below that level and only spikes up when the content gets complex. That's more efficient, but it also means that 'same nominal bitrate' does not imply 'same average number of bits' anymore — so simply reusing our CBR settings risks giving VBR less bitrate on average and losing some quality." The nominal-bitrate semantic shift is the quiet load-bearing datum: the same label means different things under different encoder objectives, and every downstream consumer (player ABR, capacity reservation, ladder construction) needs updating. (Source: sources/2026-04-02-netflix-smarter-live-streaming-vbr-at-scale)

  8. Offline VMAF + A/B both caught the same ≈1-VMAF-point quality drop on low rungs; the fix was rung-by-rung bitrate bumps. "Offline analysis with VMAF (a perceptual video quality metric) confirmed the concern from the WWE example: time-averaged quality dropped slightly on a few streams, especially at the lowest bitrates. Early A/B tests showed the same pattern: overall VMAF about one point lower than CBR, with most of the gap at the bottom of the ladder… we compared CBR and VBR encodes rung by rung and looked at per-stream VMAF. Wherever VBR fell more than about one VMAF point below CBR, we increased its nominal bitrate just enough to close the gap. Higher-bitrate streams, where VBR quality was already very close to CBR, were left largely unchanged, including the 8 Mbps stream from the figure." Canonical patterns/vmaf-rung-matched-ladder-tuning instance — offline-VMAF + production-A/B agreed; targeted lift on the affected rungs kept overall efficiency gain intact. (Source: sources/2026-04-02-netflix-smarter-live-streaming-vbr-at-scale)

  9. Forward work: feed segment-size signal to device ABR. "We are testing how to use the actual sizes of upcoming segments in our adaptive bitrate algorithms on devices, instead of relying only on nominal bitrates. This should help devices pick streams that better match how VBR will behave in the next few seconds, not just how a stream is labeled on paper." Under nominal-bitrate-indexed ABR, the player's throughput estimate vs. label comparison is systematically misleading for VBR — a 5 Mbps-labeled stream currently cheap enough to fit on a 3 Mbps link looks unsafe, and vice versa. Passing the actual next-few-segment sizes to the player recovers the match between ABR's decision input and the stream's real near-future bitrate. (Source: sources/2026-04-02-netflix-smarter-live-streaming-vbr-at-scale)

  10. Forward work: apply a measurement-informed "discount" on nominal-bitrate capacity reservation. "We are experimenting with making our capacity reservation less conservative. Today we reserve based on nominal bitrates to keep servers safe; by carefully applying a 'discount' informed by real VBR behavior, we hope to free up additional headroom without sacrificing stability." Nominal-bitrate admission is safe but conservative: it reserves for worst case, which almost never materialises across all streams simultaneously. A calibrated discount (probabilistic aggregation: what's the 99th-percentile aggregate across N VBR streams?) would trade a small amount of safety margin for more admitted sessions per server. Classic statistical-multiplexing optimisation on top of the conservative baseline. (Source: sources/2026-04-02-netflix-smarter-live-streaming-vbr-at-scale)

Architectural numbers

Datum Value Scope
Live CBR → VBR cutover date 2026-01-26 All Live events
Fewer rebuffers per hour (VBR vs CBR) ≈5% Across multiple Live event A/Bs
Bytes transferred on average ≈15% less VBR vs CBR
Peak-minute traffic ≈10% less VBR vs CBR
VMAF drop at bottom rung pre-tuning ≈1 point VBR @ CBR ladder vs CBR baseline
Nominal bitrate on worked WWE RAW example 8 Mbps Per-rung example
CBR server admission model ≈20,000 concurrent sessions 100 Gbps server × 5 Mbps/stream
Encoder vendor / setting AWS Elemental MediaLive / QVBR Live encoding pipeline
CDN substrate Open Connect Fleet delivery

Systems introduced

  • systems/aws-elemental-medialive — AWS managed live video encoder used by Netflix's Live pipeline; QVBR setting is the capped-VBR implementation underpinning this rollout.

Systems reused / extended

  • systems/netflix-open-connect — delivery substrate for Live traffic; peak-minute-traffic reduction (≈10%) directly reduces fill + serve burden on OC appliances + peering ISPs.
  • systems/av1-codec — not named directly in this post but structurally adjacent: AV1's grain-parameter / layered coding architecture is the content-complexity-aware codec direction that VBR rate-control fully exploits.

Concepts introduced

Patterns introduced

  • patterns/nominal-bitrate-admission-control — reserve capacity against the stream's nominal bitrate, not current bitrate, when admitting VBR sessions. Restores CBR-era admission-control safety while keeping the VBR efficiency win.
  • patterns/vmaf-rung-matched-ladder-tuning — when switching encoder rate-control modes, compare rung-by-rung VMAF between the old and new ladders and lift the new nominal bitrate on any rung that loses > ≈1 VMAF point.
  • patterns/cbr-to-vbr-live-rollout — end-to-end live-pipeline rate-control migration playbook: cap the VBR, re-tune the ladder via rung-by-rung VMAF matching, upgrade admission control to reserve against nominal.

Concepts extended

  • concepts/rebuffering-rate — second canonical Netflix datum on rebuffering-rate deltas from an encode-pipeline change (first was AV1 at 45% fewer vs AVC/HEVC); this post adds the ≈5% fewer rebuffers/hour VBR-vs-CBR datum at matched quality.
  • concepts/visual-quality-metric — VMAF used as the rung-by-rung decision metric for ladder re-tuning; concrete ≈1-VMAF-point-loss trigger for nominal-bitrate lift.
  • concepts/adaptive-bitrate-streaming-dash — the forward-work direction of feeding upcoming segment sizes to ABR sharpens this concept: the ABR input vocabulary is changing from nominal labels to measured near-future sizes.

Caveats

  • Production numbers are percentages only, not absolutes. ≈5% / ≈15% / ≈10% are relative to CBR baselines that Netflix does not publish. Absolute rebuffers/hour, bytes/title, and Gbps/server are held as competitive data.
  • A/B scope not fully disclosed. "Multiple A/B tests on different Live events" — no per-event breakdown, no region-segmented numbers, no time window.
  • QVBR cap value + per-rung nominal bumps not disclosed. The worked 8 Mbps example is illustrative; the actual production ladder + per-rung cap + per-rung VBR nominal bumps are not given.
  • Admission-control implementation not specified. "We reserve capacity based on each stream's nominal bitrate" — the code-level change to the steering logic, the refresh cadence, and the interaction with active re-steering during an event aren't walked through.
  • Segment-size-aware ABR is a future direction, not shipped. The DASH manifest format already supports segment byte-size indices (SegmentTemplate @$time$ / @$size$ attributes exist), so the architectural question is what device-side ABR algorithms do with that input.
  • Statistical-multiplexing discount is experimental. "Experimenting with… a 'discount' informed by real VBR behavior" — no production deployment, no safety margin disclosed.
  • Not a device-decoder post. AV1 decoder readiness, HDR10+ interaction, layered-coding implications for Live aren't discussed here; see sources/2025-12-05-netflix-av1-now-powering-30-of-netflix-streaming for those axes.
  • The post does not break out Live per-event scale. Jake Paul vs Tyson ("tens of millions of concurrent viewers" per the 2025-12-05 AV1 post) is the implicit upper bound, but the VBR rollout itself isn't correlated against event-size.

Source

Last updated · 319 distilled / 1,201 read