Technical Overview of HLS and HTTP-FLV Live Streaming for K歌 Web Frontend

Background : Due to the COVID‑19 pandemic in 2020, offline entertainment decreased and live‑streaming usage surged. The K‑song (K歌) platform saw a rapid increase in broadcaster registrations and online audience, with about 20 star concerts hosted by TME since April. Existing K‑song live‑streaming code could not meet growing functional and UX requirements, prompting the need for a more reliable web‑side streaming solution.

HLS and HTTP‑FLV

Currently the K‑song web uses HLS (HTTP Live Streaming) as the main streaming format. HLS works by the server segmenting the stream into small MPEG‑TS fragments referenced by an m3u8 playlist. Mobile iOS and Android browsers support HLS, and the stream can be played directly in an HTML5 element.

<video>
<source id="source" src="http://xxxx/video.m3u8" type="application/x-mpegURL" />
</video>

Limitations of HLS : high latency (20‑30 s) due to server‑side segmentation, frequent HTTP requests causing possible stutter, and limited ability to customize playback or monitor data through the tag.

To achieve lower latency and more stable playback, HTTP‑FLV is introduced.

HTTP‑FLV encapsulates RTMP over HTTP, delivering an unbounded HTTP stream of FLV data. Because it does not require server‑side segmentation, latency is reduced to 1‑2 s. It also bypasses some firewall restrictions, supports 302 redirects and HTTPS encryption.

Limitations of HTTP‑FLV : playback depends on Media Source Extensions (MSE) and fetch+stream APIs, which are not available on iOS Safari, so FLV cannot be played directly on iOS devices.

FLV Web Support Solutions

Direct playback of FLV via the native tag is not feasible. Several JavaScript SDKs are evaluated:

The table below summarizes the capabilities of major FLV SDKs on different platforms (Apple iOS, Android, various browsers). In short, flv.js relies on MSE and cannot run on iOS; NodePlayer.js uses ASM.js soft‑decoding with WebGL/WebAudio rendering; WXInlinePlayer and the internally developed ffmpeg‑player follow a similar pipeline: fetch HTTP‑FLV data, decode with WASM in a Web Worker, render video with WebGL and audio with Web Audio API.

Key differences between WXInlinePlayer and the ffmpeg‑player include decoder dependencies (OpenH264 vs. full FFmpeg with H.265 support), algorithm choices (SWS_FAST_BILINEAR vs. SWS_BICUBIC), and deployment strategy (WASM + JS glue on CDN vs. base64‑encoded single JS file).

kg‑player SDK

The K‑song team packaged the optimized WXInlinePlayer and Tencent’s TCPlayer into a unified kg‑player SDK that supports both HLS and FLV streams. Improvements address iOS audio‑video sync, mobile system adaptation, and WebGL rotation handling.

For iOS, extra audio offset is subtracted to align A/V. For Android, video rotation is corrected via matrix transforms in the WebGL layer.

The SDK automatically detects device capabilities, falls back to lower bitrate or switches from FLV to HLS when performance degrades (e.g., page FPS < 24). It also monitors playback stutter via a 2‑second heartbeat; repeated identical timestamps are reported as “stutter”.

Technical Architecture

The overall architecture consists of three modules: the kg‑player SDK for stream playback, the kg‑im SDK for real‑time chat and gift messages, and a gift‑animation rendering module (WebGL, CSS, or video). The kg‑im SDK polls messages, aggregates them, and provides a lightweight data structure to the front‑end.

Performance Data

First‑frame rendering time (initial test): FLV average 3421 ms vs. HLS 1076 ms. After optimization, FLV first‑frame time dropped to 3182 ms on iOS and 981 ms on Android.

Stutter rate is measured by comparing playback time between heartbeats. FLV generally shows lower stutter than HLS under the same network conditions because it does not require segment requests.

When stutter is detected, the SDK degrades the stream (e.g., from 720p to 540p, or from FLV to HLS). Overall degradation rate is about 11.5 %.

Further Optimizations

Because WASM‑based soft decoding and WebGL rendering are hardware‑intensive, many mid‑range devices struggle with FLV. The team switched Android devices to an MSE‑based FLV loading path using flv.js or video.js, eliminating the need for WASM and reducing first‑frame latency.

Business Impact

The solution powers K‑song’s external H5 sharing pages (≈300 k daily PV) and TME live streams (≈500 k per event), delivering stable front‑end performance and good user experience.

Conclusion and Outlook

The encapsulated SDK meets current K‑song live‑streaming requirements and provides a solid foundation for future web‑based live‑streaming projects. Ongoing work includes expanding to more scenarios (e.g., live karaoke rooms), further performance tuning, and eventual open‑source release.