Optimizing First-Frame Latency in Mobile Live Streaming with ijkplayer and ffmpeg

With the rapid growth of mobile live streaming, the time it takes for a user to see the first video frame (first‑screen latency) has become a critical user‑experience metric. Meipai reduced this latency by more than 50%, achieving around 500 ms, by systematically optimizing DNS resolution, TCP connection, HTTP response, stream detection, and buffering using the ijkplayer (ffmpeg‑based) player.

Why ijkplayer? ijkplayer is an open‑source, ffmpeg‑based mobile player with a clear code structure, making it an ideal reference for analyzing and improving live‑stream startup performance. Although Meipai’s production player is a custom ffmpeg implementation, its logic mirrors ijkplayer, allowing direct source‑level inspection.

Factors affecting first‑screen latency

Network bandwidth consumption by UI assets (avatars, gifts, etc.)

Mobile network bandwidth limits (typically ~1 Mbps)

Player pull‑stream speed and buffering strategy

CDN caching policies

Streaming protocol (http‑flv vs. RTMP, with http‑flv saving ~300‑400 ms)

Decomposing the latency

The latency can be broken down into five stages, each measurable in the ffmpeg source:

DNS lookup – usually ≥300 ms without cache; can drop to a few ms with cache.

TCP connection – the three‑way handshake, typically <50 ms on Wi‑Fi.

HTTP response – header receipt, 50‑200 ms depending on CDN cache hit.

Stream probing – avformat_find_stream_info execution, often ~100 ms.

Buffering – waiting for enough audio/video frames before playback.

Code snippets for measuring each stage (example for DNS and TCP):

int64_t start = av_gettime();
if (!hostname[0])
    ret = getaddrinfo(NULL, portstr, &hints, &ai);
else
    ret = getaddrinfo(hostname, portstr, &hints, &ai);
int64_t end = av_gettime();

int64_t start = av_gettime();
if ((ret = ff_listen_connect(fd, cur_ai->ai_addr, cur_ai->ai_addrlen,
    s->open_timeout / 1000, h, !!cur_ai->ai_next)) < 0) {
    if (ret == AVERROR_EXIT) goto fail1; else goto fail;
}
int64_t end = av_gettime();

Optimization measures

DNS : Combine HTTPDNS with a local DNS cache, pre‑resolve streaming domains at app start, and switch to HTTPDNS when cache results are slow or hijacked. This can shave 100‑300 ms.

TCP : Use CDN‑aware domain selection based on user location and carrier, and leverage HTTPDNS to direct users to optimal edge nodes.

HTTP response : Push CDN providers to improve cache hit rates and edge‑node performance; cold‑cache requests can add ~400 ms.

Stream probing : Reduce the required frame count by setting av_dict_set_int(&ffp->format_opts, "fpsprobesize", 0, 0); , cutting the probe time to <100 ms.

Buffering : Lower BUFFERING_CHECK_PER_MILLISECONDS from 300 ms to 50 ms and reduce MIN_MIN_FRAMES from 10 to 5, decreasing buffering delay by ~200‑300 ms.

CDN edge optimization : Enable GOP‑level caching and fast‑start acceleration to deliver the first second of video at up to 5× normal bandwidth.

After applying these changes, Meipai’s live streaming first‑screen time consistently falls within the 0‑500 ms range, matching industry‑leading performance.

Conclusion

Accurate per‑stage statistics are essential for pinpointing bottlenecks; without reliable data, optimization becomes guesswork. The described methodology—instrumenting ffmpeg, analyzing each latency component, and applying targeted code and network tweaks—provides a repeatable framework for other mobile live‑streaming products.

Recruitment notice (optional)

Meitu is hiring engineers for AI, blockchain, and video algorithm roles; interested candidates can contact [email protected].