How Tencent Scaled Video Playback to Billions: Architecture & Optimization Secrets

In 2016 QQ Space’s daily video playback surged from tens of millions to a billion, challenging reliability, performance, and user experience, prompting a comprehensive optimization effort.

The team achieved a playback success rate of 99.92%, reduced first‑buffer latency to 0.70 s, and lowered second‑buffer probability to 0.48%.

Key optimization areas include overall video component architecture, metric measurement, first‑buffer latency, playback success, and second‑buffer reduction.

Originally presented by Tencent R&D Director Wang Hui at QCon Beijing 2017, the talk outlines the journey.

The rapid growth of short‑video consumption worldwide inspired QQ Space to scale from 50 million daily plays in November 2015 to over 1 billion by December 2016.

The product iteration followed three critical steps:

Quick launch – rapidly delivering new short‑video experiences.

Cost optimization – addressing bandwidth and resource usage.

Experience optimization – achieving instant playback, eliminating buffering, and raising success rates.

Quick Launch

The team, responsible for both iOS and Android QQ and QQ Space apps, faced the challenge of maintaining four codebases. To improve efficiency, they introduced a shared video component.

Technical shortcomings included low playback success, lack of progressive download, long buffering, and high traffic waste.

Key technical points:

Progressive download (edge‑to‑edge streaming).

Traffic control with cloud policies.

Code reuse across platforms via a unified VideoController.

Support for third‑party video sources.

Comprehensive monitoring and reporting.

To gain control over video downloads, a local proxy was inserted between the player and server, allowing fine‑grained data delivery and clearer architecture.

The MVC‑based design placed business logic in the Model layer, while VideoController managed playback and download. VideoProxy handled request scheduling, traffic throttling, pre‑loading, priority dispatch, and monitoring. Data sources could be HTTP, local files, Tencent video, or third‑party streams, supporting HTTP/HTTPS/HTTP2.

Both iOS and Android now share the same C‑level logic, enabling a single codebase for QQ and QQ Space.

Monitoring and reporting became essential, covering:

Problem localization – rapid identification of playback failures.

Latency statistics – measuring time from request to playback.

Success‑rate statistics – real‑time alerts on failure spikes.

Instead of post‑mortem log analysis, the team instrumented error codes at the source, enabling instant diagnosis.

Cost optimization revealed that bandwidth usage rose sixfold with a four‑fold increase in playback volume. Strategies included:

Rate‑limited progressive download (e.g., stop after N seconds during peak hours).

Multi‑level throttling and bitrate switching.

These measures cut peak‑hour bandwidth by 25.4%.

Adopting H.265 compression offered 30‑50% bitrate reduction but required careful evaluation due to higher encoding/decoding complexity. Hardware support for H.265 was limited; software decoding increased CPU usage dramatically.

Consequently, H.265 encoding was performed only on hot videos in the backend, while client‑side playback fell back to H.264 when necessary.

After H.265 adoption, bandwidth dropped an additional ~31%.

Experience optimization targeted “instant start” – aiming for sub‑second playback, matching Facebook’s seamless video experience.

The core playback flow consists of:

Client initializes the player.

Data download.

Playback start.

Two major latency sources were identified: data download time and client‑side processing.

MP4 container analysis showed that the MOOV atom (metadata) sometimes resides at the file tail, requiring extra range requests. The solution involved server‑side transcoding fixes and client‑side handling to locate MOOV efficiently.

Download optimization also tackled anti‑hotlinking by using private long‑lived connections to fetch real URLs, and IP‑based routing to improve performance.

Pre‑loading strategies fetched key video headers and initial data while users viewed adjacent content, balancing video and image priorities.

These combined optimizations reduced average start‑up time from 1.8 s to about 0.6 s.

Client‑side performance issues such as MD5 hashing and HTTP parsing were also addressed to prevent playback stalls.

HLS live‑stream playback on Android suffered 6‑9 s delays; by parsing M3U8 manifests and parallelizing TS segment downloads through the proxy, start‑up dropped to ~1 s, with 80% of users experiencing sub‑second playback.

Further improvements tackled buffering during seeking by implementing file‑hole based caching, allowing random‑access writes and reducing seek‑induced stalls.

Overall results after the full optimization cycle:

Download success rate: 97.1% → 99.9%.

Playback success rate: 97.0% → 99.9%.

First‑buffer latency: 1.95 s → 0.70 s.

Second‑buffer probability: 4.63% → 0.48%.