Title: Adaptive Bitrate Live Streaming over HTTP-FLV: A Practical System Perspective
Authors: Le Zhang, Tong Meng (ByteDance); Bingcong Lu (ByteDance; Shanghai Jiao Tong University); Jinghao Yuan, Lu Chen, Huanting Liu, Lei Xiao, Nailiang Wu, Zhou Sha, Changqing Yan, Jianrong Zhang, Jianxin Kuang (ByteDance); Li Song (Shanghai Jiao Tong University)
Introduction
Adaptive bitrate streaming dynamically adjusts video bitrate to network conditions. Existing research mainly focuses on segmented protocols such as HLS and DASH, where clients can switch bitrate at aligned segment boundaries. TikTok Live uses HTTP-FLV to continuously transmit a media stream through a single request without natural segment boundaries. When a client requests a new bitrate stream, the old stream may continue to be transmitted, causing the two streams to compete for bandwidth and increasing the risk of stalls. This paper summarizes nearly two years of TikTok Live’s experience deploying ABR over HTTP-FLV, compares client-executed and server-executed bitrate switching, and introduces server-side congestion feedback and CDN consistent hashing. The solutions were evaluated through online A/B tests covering billions of viewing sessions.
Key idea and contribution:
The system follows an end-to-end HTTP-FLV delivery architecture: a live stream is mixed by RTC servers, enters multiple CDNs, is converted into multiple bitrate variants at the origin, and is continuously delivered by edge nodes to viewers (Figure 2). The paper keeps bitrate decisions at the client while moving bitrate-switch execution and transport-state collection to the edge server.
-
Server-executed switching: After the client selects a target bitrate, it sends a switching request with a session token to the edge server. The server uses media timestamps and cache state to determine an available keyframe boundary, then sends the old and new bitrate content sequentially over the same QUIC stream. The client no longer pulls two streams simultaneously, reducing bandwidth competition on the access link; the switch point is determined by the server that has access to the actual media data.
-
Server-side network feedback: The edge server’s congestion-control module directly obtains bandwidth, RTT, and packet-loss information. CCTK periodically writes these states into QUIC control frames and sends them to the client for ABR bitrate selection. This removes the need for the client to estimate network conditions independently and makes the decision input closer to the state observed by the sender.
-
Consistent hashing for origin fetches: Multiple edge nodes may request the same live stream from upstream at the same time, causing duplicate origin fetches and fragmented cache state. The system maps requests for the same bitrate variant to a fixed intra-cluster delegate according to the stream name. The delegate aggregates upstream requests and shares the cached data, preserving more available content for bitrate switching and reducing CDN origin-fetch overhead.
Evaluation
The paper evaluates the system through online A/B tests in multiple countries and regions. In a representative switching experiment lasting two weeks and involving more than two billion viewing sessions per day, server-executed switching improves down-switch success and smooth-switch ratios by 1.6% and 35.5%, respectively, and reduces average stall duration per down-switch by 13.3%; up-switch stall duration also falls by 13.2%. Server execution provides a larger improvement for down-switching under constrained bandwidth (Figure 7).
After full ABR deployment, the average video stall ratio decreases by 4.7%, stall frequency decreases by 3.3%, and average video bitrate increases by 10.8%. ABR therefore reduces interruptions while using more available bandwidth, avoiding the persistently low bitrate that a fixed-rate strategy may choose to control stalls (Figure 9).
The QoE improvement is also reflected in engagement: daily viewing time per user increases by 0.2% with 95% statistical significance. The paper notes that this corresponds to at least several thousand additional viewing hours per day globally (Figure 12). These results matter because they show that changing where bitrate switching is executed can improve QoE and engagement without replacing the client-side ABR decision itself.
Q&A
Q1: Near the end, you mentioned Media over QUIC, or MoQ. Is the industry moving toward MoQ? What are the trade-offs, and would your solution need to be redesigned for MoQ?
A1: I’ll focus on the ABR scenarios. In the current definition of control messages, subscription, and publication procedures in MoQ, a client sends a subscription request for a single track and then receives that track. This supports both closed-ended subscriptions, which specify a finite range of media content, and open-ended subscriptions, in which the client continues receiving newly generated media as long as the track remains active.
The closed-ended option is closer to the existing implementation in HLS and DASH, where the client requests a finite range of media. The open-ended option is closer to HTTP-FLV, where the client sends one subscription request and then receives continuous media. If we retain a conventional client-controlled ABR setup with open-ended subscriptions, the bandwidth inefficiency discussed in the presentation can still occur.
An interesting direction is to combine closed-ended and open-ended subscriptions. When network conditions are generally good, a client could use an open-ended subscription. When the network is highly variable, it could use a closed-ended subscription to avoid redundant media transmission. The requested range could also be shortened when network conditions become more variable. These are some initial thoughts, and we are still in the preliminary stage of working them out internally.
Personal thoughts
The paper’s key insight is that bitrate selection and switch execution should be treated as two connected system problems. HTTP-FLV has no segment boundaries, so the edge server uses keyframes, timestamps, and cache state to determine the actual switch point, then combines this with QUIC congestion feedback and CDN origin-fetch aggregation to turn the client’s decision into stable media delivery. The large-scale online results show that protocol limitations often need to be addressed jointly by edge transport and CDN organization.
The reported gains are closely tied to HTTP-FLV’s continuous delivery model, the multi-CDN architecture, and the existing ABR design. When using segmented protocols or a different CDN topology, the extent to which server-executed switching, CCTK feedback, and consistent hashing retain their benefits remains to be established.