Technical Exploration of iQIYI's Qixiu Live Streaming System

In the first half of 2020, live streaming surged as a dominant trend in the Chinese internet, reaching a point where every influencer and celebrity engages in live broadcasts. This article presents iQIYI's technical exploration of its Qixiu live streaming platform.

Two Live Streaming Scenarios

1. Ordinary Live : A single host streams to a large audience. Interaction is limited to text chat via an IM system. The stream mainly uses the RTMP protocol and is distributed through a CDN for massive concurrent delivery.

2. Link‑Mic Live : Hosts can interact with each other and with the audience via real‑time audio/video. Multiple hosts’ streams are displayed simultaneously, creating a more engaging experience similar to group performances.

Technical Foundations

Ordinary live streaming relies on the TCP‑based RTMP protocol, while link‑mic live streaming adopts the UDP‑based RTP protocol, which introduces the need for application‑level packet loss recovery and higher implementation complexity.

System Architecture

Qixiu live streaming employs woogeen , an enhanced WebRTC solution, with a redesigned client SDK and MCU (Multipoint Control Unit) server. The main modules are:

Client SDK – handles signaling and pushes WebRTC streams to the MCU.

MCU Node – receives signaling via Socket.IO, ingests WebRTC streams, performs audio/video transcoding and mixing, and pushes the resulting stream out via RTMP.

MCU_DNS – selects the optimal MCU node based on load, geographic location, and blacklist policies.

MCU_API – provides business‑level APIs for signaling, stream control, and mixing operations.

Business Backend – supplies resources such as MCU room IDs and RTMP URLs, and monitors API feedback to control the overall live session.

The topology shows hosts pushing RTP streams to the MCU. For ordinary live, the MCU simply forwards the stream to RTMP; for link‑mic, the MCU mixes multiple streams before forwarding, enabling seamless transition between scenarios without interrupting playback.

Viewers retrieve the stream via HTTP‑FLV or RTMP over TCP, and each MCU instance operates independently, allowing isolated upgrades and fault tolerance.

Link‑Mic Optimizations

WebRTC Adjustments : Audio is captured at 48 kHz (higher than the typical 8/16 kHz for calls) and encoded at 128 kbps to meet music‑performance quality. Video encoding uses H.264 instead of VP8/VP9 for CDN compatibility. The system adopts a relay model rather than pure P2P to ensure reliable delivery to the MCU and downstream CDN.

Key Challenges and Solutions :

Mixing : Server‑side mixing reduces downstream bandwidth and client processing load.

Push Latency : Network‑aware node selection before streaming, dynamic bitrate adaptation using both delay‑based (Kalman filter, RTCP feedback) and loss‑based (RTCP RR, TMMBR/REMB, TFRC) congestion control algorithms.

Performance : Optional beauty/effect filters, hardware encoding/decoding, and adaptive bitrate help mitigate device overheating and frame drops.

Room Management : Dedicated room processes maintain state, support independent rooms per host, and enable cross‑room stream pulling for mixing.

Echo Cancellation : PC side uses multi‑channel audio routing; mobile side employs WebRTC AEC/AECM with adaptive filtering (NLMS, NLP, CNG) to eliminate feedback loops.

Future Optimization Directions

Enable real‑time MCU server switching during an ongoing stream to avoid re‑broadcasting when network issues arise.

Support seamless network switching on mobile devices during live push.

Improve the quality of mobile echo cancellation beyond the current WebRTC algorithms.

References:

WebRTC Interactive Live Streaming Practice

Mobile Live Streaming Link‑Mic Technical Practice

WebRTC Echo Cancellation Technology

WebRTC Congestion Control Techniques