Optimization of Baidu Live Streaming Startup Process

Background : Baidu live streaming aims to replicate offline experiences online and to create new immersive experiences with 5G, VR, and AI. The primary goal is to improve Quality of Experience (QoE) by reducing startup latency, delay, video quality issues, and audio‑video sync problems.

Current Situation : Baidu offers two types of live services – generic service live (media, consulting, e‑commerce) and entertainment live (showroom, audio, voice rooms). The generic service live has a complex startup flow with multiple external and immersive navigation paths, many live states, and involvement of many teams (playback, kernel, network, CDN, etc.).

QoE/QOS Metrics : From a QoE perspective, key metrics include first‑screen time, latency, picture quality, AV sync, clarity, noise, echo, etc. Corresponding QoS metrics cover push success rate, push stutter, slow‑push ratio, end‑to‑end latency, CDN smoothness, startup time, pull‑stream stutter, video bitrate, memory/CPU/GPU consumption, and more.

Data Analysis : The startup process is divided into three stages – live‑business time, player time, and kernel time. Detailed measurements show that business‑scene latency accounts for >60% of total startup time, followed by pull‑stream latency. Optimizations therefore focus first on business‑scene, then on pull‑stream, and finally on smaller‑scale delays.

Optimization Schemes : Two device‑specific schemes were designed. Scheme A (iPhone 8 and newer) creates the player and starts playback as soon as the user begins sliding. Scheme B (iPhone 7 and older) creates the player during sliding, prepares resources, and only switches playback after the slide stops, destroying the previous stream. A/B testing confirmed reduced stutter rates across devices.

Scheme for External Scheme Jump : When jumping via a scheme URL, if no roomID is provided, the client first fetches a list to obtain a roomId, then retrieves room info, installs components/plugins, renders the page, creates the player, sets the URL, initializes the kernel, and finally starts playback. If a roomID is present, the flow skips the list request.

DNS Pre‑fetch : DNS resolution contributes ~60 ms to startup latency. Baidu adopts HTTPDNS with asynchronous IP resolution, caches IPs for up to 300 s, and performs pre‑fetch based on a model that considers recent live‑watch time, network state, and backend controls. This reduces DNS latency to <3 ms for >90 % of live PVs.

Kernel Optimizations : Measures include forced first‑frame rendering, low‑bitrate startup under weak networks, pre‑loading the next player kernel on high‑end devices, and adaptive audio dropping to keep buffer delay within acceptable limits.

Media Information Parsing : For Android (MediaCodec) and iOS (VideoToolbox), video width, height, and codec information are required before initializing hardware decoders. Instead of downloading the entire stream to extract this info (as with FLV), the system parses SPS/PPS NAL units from H.264/AVC to obtain these parameters directly.

HLS (m3u8) Pre‑fetch : Live replay (HLS) suffers from an extra HTTP request to fetch the M3U8 index, adding ~1250 ms to startup. Pre‑fetching the M3U8 file to local storage reduces startup by ~346 ms, as demonstrated in A/B experiments.

Overall, the combination of business‑scene optimizations, device‑specific playback strategies, DNS pre‑fetch, kernel enhancements, and media parsing significantly improves Baidu live streaming startup performance.