Hybrid ABR: MPC, Festive, CS2P, the Real-World Defaults

Why this matters

If you have ever watched a video that started at low quality, climbed sensibly to 1080p, and then refused to drop back down when your Wi-Fi briefly hiccuped, you were watching a hybrid algorithm at work. The pure throughput-based family (covered in Throughput-Based ABR Algorithms) over-reacts to short network dips; the pure buffer-based family (covered in Buffer-Based ABR: BOLA in Depth) climbs too slowly at the start and ignores a falling line. Hybrid ABR sits between them: it watches both signals, it can predict, and it can plan. Product, engineering, and CDN finance all care because hybrid algorithms drive most of today's premium streaming experience and most of the CDN bits delivered — and the choice of MPC vs Festive vs a vendor-proprietary blend shows up in rebuffer ratio, video start time, and bits per viewer-minute on every dashboard.

What "hybrid" actually means

A throughput-based ABR algorithm picks the next chunk by measuring how fast the network has been delivering bytes. A buffer-based ABR algorithm picks the next chunk by reading how many seconds of pre-loaded video the player is holding. A hybrid ABR algorithm picks the next chunk by combining at least two signals — most often the recent throughput and the current buffer depth — and feeding them into a single optimisation objective. The objective itself is the third signal: a number that says "this rung is better than that one because it improves the viewer's quality of experience, after counting the cost of switching, of starving the buffer, and of overshooting the line".

Calling it "hybrid" is therefore a small lie of convenience. The family is really optimisation-based ABR — algorithms that frame bitrate selection as a constrained optimisation and solve it explicitly at every segment, instead of mapping a single signal to a rung. MPC, Festive, CS2P, and their cousins differ in three places: which signals they read, which model they use to predict the next few seconds, and which objective function they maximise. Everything else is detail.

The defining test for whether an algorithm is "hybrid" is simple: pause the player, look inside the rule that picks the next rung, and ask how many independent input signals it uses. One signal — throughput rate or buffer depth — and the algorithm belongs to one of the single-signal families. Two or more signals combined under a named objective function — and you are looking at a hybrid.

A tiny example before the math

A six-rung ladder of 300, 750, 1500, 2500, 4000, 6000 kbps, 4-second segments, a viewer whose player buffers up to 30 seconds. The line is delivering 4 Mbps on average but oscillates between 2 Mbps and 6 Mbps over each 5-second window. Buffer is at 12 seconds.

A throughput-based algorithm averages the last few measurements and reports "about 4 Mbps", then picks rung 4 (2500 kbps). When the line dips to 2 Mbps for the next two seconds, the algorithm sees the new measurement and downgrades to rung 2 (750 kbps). Two seconds later the line returns to 6 Mbps and the algorithm jumps back to rung 5 (4000 kbps). The viewer sees three quality changes in 8 seconds.

A buffer-based algorithm reads buffer = 12 s, applies its threshold map, picks rung 3 (1500 kbps). When the line dips, the buffer drops slightly; the algorithm still picks rung 3. When the line recovers, the algorithm still picks rung 3. The viewer sees no quality changes, but also no rung 4 or rung 5 — even when the line could have sustained them.

A hybrid algorithm reads the buffer (12 s), reads the recent throughput (4 Mbps average, with high variance), and asks an optimisation: over the next four segments, which rung sequence maximises viewer quality of experience? The optimisation factors in (a) the cost of a rebuffer if the line drops, (b) the cost of a quality switch, (c) the utility of a higher rung. The answer for this trace might be: hold rung 4 for three segments, accept a small switch to rung 3 on the bottom of the dip, return to rung 4. The viewer sees one switch in 8 seconds, at a higher average quality than either single-signal algorithm achieved.

That is the entire selling point of the hybrid family. Everything below is how the three named algorithms compute that answer.

Figure 1. The hybrid ABR pipeline. Throughput estimate plus buffer depth plus QoE objective combine into a single rung decision per segment.

Where the family sits in ABR history

Adaptive bitrate streaming was a single-signal field for its first half-decade. Apple's HLS reference implementation (2009) and Netflix's first OpenConnect rules (2011) both used throughput-only estimators. The buffer-only family arrived in 2014 with BBA (Huang et al., Stanford and Netflix) and matured with BOLA (Spiteri et al., 2016). Between those two milestones, three papers published in 2012, 2015, and 2016 — Festive, MPC, and CS2P — opened a third path.

Festive (CoNEXT 2012) showed that a player picking the highest rung its throughput estimate could afford was unfair to other players sharing the same bottleneck — the greedy player monopolised bandwidth, others were starved, and aggregate quality of experience across all players fell. Festive added a stability term and a randomised scheduling delay that, taken together, produced visibly fairer behaviour across competing players on a shared link. It was the first algorithm to treat the bitrate choice as a multi-objective optimisation: pick a high rung, but also be fair, but also be stable.

MPC (SIGCOMM 2015) generalised that insight into a formal control problem. The paper defined a quality of experience function that summed three terms across a finite horizon: viewer-perceived quality (a function of the rung), a switching penalty (proportional to the change in rung between consecutive segments), and a rebuffering penalty (proportional to the seconds the player stalls). It then framed bitrate selection as model predictive control — at every segment, the player predicts throughput for the next N chunks, enumerates rung sequences over that horizon, and picks the sequence whose first chunk maximises the QoE function. MPC is the family's mathematical core and the algorithm every subsequent paper compares itself to.

CS2P (SIGCOMM 2016) focused on the input MPC depends on: the throughput prediction. CS2P used a hidden Markov model trained on twenty million sessions from iQIYI to predict throughput more accurately than a moving average could — 40-50% lower median prediction error initially, 14% better aggregate QoE when paired with a buffer-based downstream algorithm. CS2P is rarely deployed alone; it is the prediction layer that feeds MPC and similar optimisation rules.

The three together established the hybrid playbook every premium streamer still uses: predict throughput well, optimise over a short horizon, weight quality against switching and rebuffer.

How MPC actually computes a rung

Skip this section if you only need the engineering picture. Read it if you have to debug an MPC implementation.

The QoE function

For each rung sequence over the next N segments, MPC computes:

QoE = Σ q(b_k)  −  λ_s · Σ |q(b_k) − q(b_{k−1})|  −  λ_r · Σ rebuffer_seconds_k
       k=1..N            k=2..N                       k=1..N

Where:

• b_k is the bitrate of the k-th segment in the candidate sequence.
• q(b_k) is a perceived-quality function. Common choices: identity (q(b) = b, treating bitrate itself as a proxy for quality), logarithmic (q(b) = ln(b), capturing diminishing returns), or VMAF-derived (a number from 0 to 100 that better matches viewer perception).
• λ_s is the switching weight. A higher value penalises quality changes harder; typical production values sit between 1 and the average per-rung quality difference.
• λ_r is the rebuffer weight. A much higher value than λ_s — typically 5x to 10x — because a rebuffer is the single most damaging event in viewer experience.
• rebuffer_seconds_k is the predicted number of seconds the player will spend stalled after downloading segment k, given the throughput forecast and the buffer state.

The first sum rewards quality. The second sum penalises switching. The third sum penalises stalls. The algorithm picks the rung sequence (not just the next rung) whose total QoE is highest, then plays the first rung of that sequence and re-plans on the next segment.

The throughput prediction

MPC needs a forecast of throughput for the next N segments. The original paper used a simple harmonic mean of the last five measurements. CS2P replaced this with a hidden Markov model. Kairos (arXiv 2503.14271, March 2025) replaced it again with a streaming-aware predictor that explicitly models the relationship between buffer state and observed throughput. The choice of predictor is the single most important practical decision in deploying MPC: a bad prediction makes the optimisation solve the wrong problem.

The horizon

N is typically 4 or 5 segments — about 16 to 20 seconds with 4-second segments. Longer horizons explore more rung sequences but compound prediction error. Shorter horizons react faster but plan worse. The 2015 paper showed empirically that N = 5 captures most of the gain.

The robust variant

The original paper presents two versions: FastMPC (deterministic, uses the point throughput forecast directly) and RobustMPC (treats the forecast as an interval, picks the rung sequence whose worst-case QoE is highest). RobustMPC outperforms FastMPC on networks with high prediction error — which is most networks. dash.js's hybrid rule borrows from RobustMPC's defensive optimisation.

The compute cost

The naïve algorithm enumerates M^N rung sequences (M rungs per segment, N segments in the horizon). For a six-rung ladder and a five-segment horizon, that is 7,776 candidate sequences per segment. dash.js precomputes these into a lookup table, which is why early documentation talked about "offline computation"; modern implementations enumerate dynamically because modern devices can.

Festive: the fairness and stability hybrid

Festive's contribution is less about the math and more about the system behaviour. The algorithm:

• Estimates throughput using a harmonic mean of the last 20 segments, which gives more weight to slower samples (a property the geometric mean lacks) and better handles bursty networks.
• Chooses a target bitrate as the highest rung the harmonic-mean throughput can sustain, modulated by a stability term that resists switching away from the current rung unless a higher-rung choice has been "winning" the comparison for at least k consecutive segments.
• Introduces a randomised scheduling delay between chunk requests. Without this delay, multiple players sharing the same bottleneck synchronise their requests and starve each other in turn (the "ON-OFF" pattern). The randomised delay desynchronises them.

The fairness gain across competing players is the algorithm's most cited property. The stability gain — fewer quality switches per minute — is the practical reason it survived into hybrid blends. Most modern hybrid implementations borrow Festive's harmonic-mean throughput estimator and stability counter without calling them out.

CS2P: the throughput-prediction layer

CS2P does not pick a rung. It predicts throughput. Specifically, it does three things:

1. Cluster sessions by static features (ISP, geographic region, time of day, device type). The intuition: sessions sharing these features have similar throughput profiles.
2. Predict initial throughput for a new session from its cluster — the answer is "what is the typical throughput a new session in this cluster sees in its first few seconds?"
3. Update the prediction mid-session using a hidden Markov model trained on the cluster's session histories. The HMM models the latent network state (e.g., "good", "moderate", "congested") and the observed throughput as emissions from those states.

The HMM lets CS2P predict not just the next-second throughput but the next-N-second distribution. That distribution then feeds into MPC, which uses it in the QoE optimisation. The combined CS2P + MPC pipeline beat plain MPC by 14% on the iQIYI dataset. The paper is the proof that better prediction matters more than better optimisation once your optimisation is reasonable — a lesson the neural ABR family (Pensieve, Comyco, Kairos) later operationalised.

A worked example with numbers

Set up: same ladder (300, 750, 1500, 2500, 4000, 6000 kbps), 4-second segments, buffer = 12 s, MPC horizon = 4 segments, λ_s = 1, λ_r = 8, throughput forecast = [4.0, 3.5, 4.2, 4.0] Mbps for the next four segments.

The algorithm enumerates rung sequences of length 4. Three candidates:

Candidate A — hold at rung 4 (2500 kbps) all four segments.

• Quality sum (identity): 2500 + 2500 + 2500 + 2500 = 10,000 kbps.
• Switch penalty: 0 + 0 + 0 = 0.
• Rebuffer: chunks at 2500 kbps × 4 s = 10 Mb each. Predicted throughputs 4.0, 3.5, 4.2, 4.0 Mbps. Download times: 2.5, 2.86, 2.38, 2.5 s. Net buffer change per segment: 4 − download_time = 1.5, 1.14, 1.62, 1.5 s. Buffer never falls below 12; no rebuffer.
• QoE = 10,000 − 0 − 0 = 10,000.

Candidate B — climb to rung 5 (4000 kbps) after one segment, hold.

• Quality sum: 2500 + 4000 + 4000 + 4000 = 14,500.
• Switch penalty: |4000 − 2500| + 0 + 0 = 1500.
• Rebuffer: chunks at 4000 kbps × 4 s = 16 Mb each. Download times: 2.5, 4.57, 3.81, 4.0 s. Net buffer changes: 1.5, −0.57, 0.19, 0. Buffer evolves: 13.5, 12.93, 13.12, 13.12. No rebuffer.
• QoE = 14,500 − 1,500 − 0 = 13,000.

Candidate C — jump to rung 6 (6000 kbps) immediately, hold.

• Quality sum: 6000 × 4 = 24,000.
• Switch penalty: |6000 − 2500| + 0 + 0 + 0 = 3500.
• Rebuffer: chunks at 6000 kbps × 4 s = 24 Mb. Download times: 6.0, 6.86, 5.71, 6.0 s. Net buffer changes: −2.0, −2.86, −1.71, −2.0. Buffer evolves: 10, 7.14, 5.43, 3.43. No rebuffer yet, but the algorithm projects the trend.
• QoE = 24,000 − 3,500 − 0 = 20,500 on paper, but RobustMPC's interval forecast widens the throughput band and predicts rebuffer in segment 5; the rebuffer penalty then dominates and Candidate C falls out.

The algorithm picks Candidate B, downloads the first segment at rung 4 (2500 kbps), then re-plans next segment with the updated throughput observation. The viewer sees a deliberate climb, not a panicky jump.

This is the MPC signature: a few seconds of look-ahead, an explicit penalty for switching, a strong penalty for rebuffer, and a fresh re-plan every segment. Most hybrid algorithms in production are some variation of this core.

Where hybrid wins

Four deployment shapes match the hybrid family's strengths.

Shape 1 — Premium VoD with quality SLAs. Long-form content on residential lines where the operator measures rebuffer ratio, average bitrate, and quality-switch rate as first-class KPIs. Hybrid algorithms beat single-signal algorithms across the metric triple. Netflix, YouTube, Disney+, Amazon Prime Video, and Hulu all run some variant of hybrid in production; the State of Streaming Q4 2024 shows median rebuffer ratios under 0.4% on premium services, which neither pure throughput nor pure buffer reliably hits.

Shape 2 — Networks with predictable patterns. Home fibre, wired enterprise, fixed wireless. CS2P's clustering and HMM thrive on networks where session-to-session similarity holds. On highly volatile mobile or satellite traces, the predictor breaks down and the hybrid degenerates toward its underlying optimisation — still good, but not the marquee gain.

Shape 3 — Use cases where switch rate is a tracked metric. Apps where the product team has decided "fewer visible quality changes" is a brand quality. Hybrid algorithms with explicit switching penalties (λ_s > 0) outperform single-signal algorithms by 2-5x on switches per minute at the same average bitrate.

Shape 4 — Players where the bitrate ladder is well-shaped. Per-title and per-shot ladders (see Building a Bitrate Ladder) give hybrid algorithms a clean utility function to optimise. A poorly-shaped ladder — too many redundant rungs, gaps too wide near the top — wastes hybrid's planning effort.

Where hybrid loses

Four failure modes account for almost every production complaint about hybrid ABR. Each has a fix.

Failure 1 — Bad throughput prediction. When the predictor is wrong, MPC solves the wrong optimisation. On highly volatile networks (5G handoffs, congested public Wi-Fi, satellite weather), the prediction error swamps the planning gain and a hybrid can perform worse than a simple buffer-based rule. Fix: switch predictors (CS2P or Kairos) or fall back to RobustMPC's interval forecast, which trades best-case performance for worst-case guarantees.

Failure 2 — Compute cost on low-end devices. Naïve MPC enumeration grows as M^N. On a five-rung ladder with a five-segment horizon, that is 3,125 candidates per segment — fine for a modern phone, painful for a 2018-era smart TV. Fix: precompute a lookup table indexed by (buffer level, throughput estimate, current rung) and read it at runtime. dash.js's DYNAMIC rule ships exactly this pattern.

Failure 3 — Parameter tuning hell. A hybrid has at least three tunable weights (quality utility shape, λ_s, λ_r), a horizon length N, and the underlying throughput predictor's own parameters. Tuning these without A/B infrastructure is guesswork. Fix: ship the published defaults from the MPC paper and the dash.js DYNAMIC rule first, run A/B at scale, only then tune for your specific traffic.

Failure 4 — Low-latency targets. Hybrid algorithms with horizons N ≥ 4 implicitly assume the buffer is deep enough to absorb a planning error. With LL-HLS or LL-DASH targets of 2-3 seconds, the buffer cannot absorb anything and the horizon must shrink to 1-2 segments, which strips most of the planning advantage. Fix: switch to L2A or LoL+ for low-latency, which are designed for shallow buffers.

Figure 2. The deployment shapes hybrid ABR was designed for, and the ones it stumbles in.

Tuning levers — the knobs that actually matter

If you ship a hybrid-ABR player and need to tune it, four knobs do most of the work.

Knob 1 — λ_s (switching weight). Penalty for each kbps of quality change between consecutive segments. Higher λ_s means smoother quality with lower average bitrate; lower λ_s tracks the network tighter at the cost of more visible switches. Default in the MPC paper: 1.0 (with quality in kbps). Production rules use values from 0.5 to 3.0.

Knob 2 — λ_r (rebuffer weight). Penalty for each second of predicted stall. Always much higher than λ_s — a rebuffer is the worst event in QoE. Default in the MPC paper: 4.3 (chosen empirically). Production rules use 5 to 10 depending on how aggressively the operator weights stall avoidance.

Knob 3 — Horizon N. Number of segments the algorithm plans ahead. Default: 5 (about 20 seconds with 4-second segments). Smaller N (2-3) for low-latency contexts. Larger N (7-8) only if the throughput predictor is very accurate, which is rare.

Knob 4 — Throughput predictor. Harmonic mean of last K segments (Festive's choice, K = 20) is the production baseline. Replace with CS2P's HMM if you have the session corpus to train it, with Kairos if you want the 2025 state of the art, or with a vendor predictor if you trust the vendor's calibration.

The table below shows defaults for three deployments.

Deployment	λ_s	λ_r	Horizon N	Throughput predictor
Premium VoD, residential fibre	1.0	5.0	5	harmonic mean, K=20
Mobile-first OTT	1.5	8.0	4	CS2P-style HMM if available, else harmonic mean
Live event, classic latency	2.0	10.0	3	harmonic mean, K=10

For LL-HLS and LL-DASH targets under 3 s, use L2A or LoL+ instead of MPC.

How hybrid compares with the other ABR families

Hybrid is one of four ABR families. Their trade-offs in one table.

Family	Primary signals	Strengths	Weaknesses	Where it ships
Throughput-based	Recent download rate	Simple, fast start, low compute	Jittery on bursty networks, blind to buffer	hls.js, iOS native, older dash.js, most smart TVs
Buffer-based (BOLA)	Buffer depth in seconds	Smooth, robust to jitter, mathematically grounded	Slow cold start, blind to bandwidth, needs deep buffer	dash.js (default since 2017), Shaka Player option
Hybrid (MPC, Festive)	Throughput + buffer + QoE	Best aggregate QoE in production, switch-rate control	Hard to tune, compute heavier, sensitive to predictor	Netflix, YouTube, premium streamers, dash.js DYNAMIC
Neural (Pensieve, Comyco)	Learned policy	Best in benchmarks	Heavy to train, retrains needed, opaque	Research, two or three top streamers

The pillar ABR Streaming Explained covers all four in context. The companion articles dig in: Throughput-Based ABR Algorithms, Buffer-Based ABR: BOLA in Depth, and Neural ABR (Pensieve, Comyco).

Common mistakes when shipping a hybrid-ABR player

Pitfall 1 — Tuning λ_s and λ_r without measuring QoE. The two weights interact non-linearly with the throughput predictor and the ladder shape. Cranking λ_s higher to "reduce switches" often increases average bitrate variance because the algorithm waits longer before reacting to a sustained network drop. Ship the defaults first; A/B test changes against rebuffer ratio, average bitrate, and switches per minute together.

Pitfall 2 — Trusting the throughput predictor blindly. Production lines exhibit prediction errors of 30-50% in the tails. MPC's plan is only as good as its forecast. RobustMPC, interval predictors, or fall-back to harmonic mean during high-variance windows are all valid defensive moves. Never ship MPC with a single point forecast and no fallback.

Pitfall 3 — Picking horizon N > 5 without infrastructure. Long horizons amplify prediction error. Five segments of look-ahead at 4-second segments is 20 seconds of plan, which is already 5x longer than the typical network coherence time on a residential line. Longer horizons rarely pay off outside of academic benchmarks.

Pitfall 4 — Disabling Festive's stability counter. A hybrid that switches as soon as a single segment "wins" the rung comparison oscillates visibly. Festive's stability counter requires k consecutive segments of a higher rung winning before switching up. This is a low-cost smoothing layer; do not turn it off in pursuit of "responsiveness".

Pitfall 5 — Benchmarking hybrid on stable wired traces. MPC's marginal gain over a simple buffer-based rule is small on a stable 100 Mbps line — both algorithms hit the top rung and stay there. The gain shows up on real-world traces with variability. Benchmark against the Pensieve, Puffer, or Conviva trace corpora, not against a single iperf run.

Where Fora Soft fits in

We have shipped video products since 2005, and we have inherited many dash.js and Shaka Player deployments where the team flipped from BOLA to the DYNAMIC hybrid rule and saw rebuffer ratio improve by 30-50% — and others where the team made the same flip and saw QoE worsen because their throughput predictor was tuned for a different access network. In OTT we default to hybrid for the long-form viewing window. In e-learning we default to BOLA for lectures (deep buffers, predictable behaviour) and switch to hybrid for live class sessions. In telemedicine and live conferencing we move off hybrid entirely toward L2A or LoL+ because the latency budget makes the planning horizon meaningless. The right algorithm depends on the use case's buffer headroom and the access network's predictability, not on what the latest paper claims.

What to read next

• Adaptive Bitrate Streaming Explained Without Buzzwords — the pillar article that places hybrid in context with the other three ABR families.
• Buffer-Based ABR: BOLA in Depth — the family hybrid borrows the buffer signal from.
• Neural ABR: Pensieve, Comyco, Kairos — the family that grew out of hybrid by replacing the optimisation with a learned policy.

CTA

• Talk to a streaming engineer — book a 30-minute scoping call with our streaming team.
• See our case studies — read how we built ABR for OTT, e-learning, telemedicine, and surveillance clients.
• Download: Hybrid ABR Tuning & Pitfalls Sheet — a one-page reference for the four hybrid tuning knobs, the three named algorithms, and the four common failure modes. Download the tuning sheet.

References

1. X. Yin, A. Jindal, V. Sekar, B. Sinopoli — A Control-Theoretic Approach for Dynamic Adaptive Video Streaming over HTTP, ACM SIGCOMM 2015, pp. 325–338. The original MPC paper. https://conferences.sigcomm.org/sigcomm/2015/pdf/papers/p325.pdf
2. J. Jiang, V. Sekar, H. Zhang — Improving Fairness, Efficiency, and Stability in HTTP-based Adaptive Video Streaming with FESTIVE, ACM CoNEXT 2012, pp. 97–108 (Best Paper Runner-up; extended in IEEE/ACM Transactions on Networking, 2014). https://dblp.uni-trier.de/rec/conf/conext/JiangSZ12.html
3. Y. Sun, X. Yin, J. Jiang, V. Sekar, F. Lin, N. Wang, T. Liu, B. Sinopoli — CS2P: Improving Video Bitrate Selection and Adaptation with Data-Driven Throughput Prediction, ACM SIGCOMM 2016, pp. 272–285. https://dl.acm.org/doi/abs/10.1145/2934872.2934898
4. ISO/IEC 23009-1:2022 — Information technology — Dynamic adaptive streaming over HTTP (DASH) — Part 1: Media presentation description and segment formats. Fifth edition. The controlling DASH standard the hybrid algorithms consume. https://www.iso.org/standard/83314.html
5. IETF RFC 8216 — HTTP Live Streaming, R. Pantos and W. May, May 2017. The HLS spec; hybrid rules can be layered on hls.js for HLS players. https://www.rfc-editor.org/rfc/rfc8216
6. Apple — HTTP Live Streaming (HLS) Authoring Specification for Apple Devices, revision 2025-09. §2 rendition-ladder guidance shapes the utility surface the hybrid optimisation operates on. https://developer.apple.com/documentation/http-live-streaming/hls-authoring-specification-for-apple-devices
7. DASH Industry Forum — dash.js DYNAMIC Rule documentation, 2024 revision. The reference for how the hybrid rule is configured in production dash.js. https://dashif.org/dash.js/pages/usage/abr/
8. DASH Industry Forum — L2A and LoL+ Rule documentation, 2024 revision. The low-latency hybrid alternatives shipped in dash.js. https://dashif.org/dash.js/pages/usage/abr/lol_plus.html
9. K. Spiteri, R. K. Sitaraman, D. Sparacio — From Theory to Practice: Improving Bitrate Adaptation in the DASH Reference Player, ACM Transactions on Multimedia Computing, Communications, and Applications, 2019. The paper documenting how dash.js blends hybrid and buffer-based rules in production. https://dl.acm.org/doi/10.1145/3336497
10. A. Bentaleb et al. — Low Latency Live Streaming Implementation in DASH and HLS, ACM Multimedia 2022. Documents L2A, LoL+, Stallion, Llama as low-latency successors to MPC. https://dl.acm.org/doi/10.1145/3503161.3548544
11. Z. Meng et al. — Video Streaming with Kairos: An MPC-Based ABR with Streaming-Aware Throughput Prediction, arXiv 2503.14271, March 2025. The current state-of-the-art MPC-style algorithm with a streaming-aware predictor. https://arxiv.org/abs/2503.14271
12. Bitmovin — Video Developer Report 2024. Survey data on hybrid-algorithm deployment share. https://bitmovin.com/video-developer-report
13. Conviva — State of Streaming Q4 2024. Industry benchmarks for rebuffer ratio, switches per minute, and start-up time on premium services running hybrid algorithms. https://www.conviva.com/state-of-streaming