Choosing a live streaming protocol is often not a question of "which is better," but rather "how much latency can your specific use case tolerate?" The latency difference between HTTP-FLV and HLS can be explained precisely in technical terms. Understanding the source of this difference is far more valuable than simply memorizing the rule of thumb that "FLV is fast while HLS is slow." After all, your specific business scenario might fall somewhere in the gray area between "HLS is sufficient" and "FLV is mandatory."

　　The Root Cause of Latency: The Segmentation Mechanism

　　HLS stands for HTTP Live Streaming; it was introduced by Apple in 2009. Its core operating principle involves slicing the live stream into small segment files (typically in TS format)—each lasting 5 to 10 seconds—and distributing them via standard HTTP protocols. Once the player retrieves the m3u8 index file, it downloads these segments sequentially for playback.

　　This workflow—segmenting, downloading, and buffering multiple segments before playback—inherently introduces latency. It takes time for a segment to be generated and fully downloaded by the player. More importantly, to ensure smooth playback, players typically do not play a segment immediately after downloading it; instead, they buffer three to four segments before starting. Technical documentation breaks the math down clearly: with segments lasting 5 seconds or more and a buffer of three to four segments, the total latency falls within the 10- to 30-second range.

　　HTTP-FLV takes a different approach. It encapsulates audio and video data into the FLV format and pushes it continuously to the player via a persistent HTTP connection. Since the server response omits the `Content-Length` header, the client continues to receive data until the connection is terminated. The player does not need to wait for segments to be generated or accumulated; data arrives as a continuous stream, allowing for minimal buffering. Technical documentation from various sources indicates that the typical latency for HTTP-FLV ranges from 1 to 3 seconds. One method involves "waiting for the file to be generated before downloading," while the other involves "streaming data as soon as it arrives." This fundamental difference dictates that the minimum latency for HLS is far higher than that of HTTP-FLV.

　　Empirical Data: How Big Is the Gap?

　　Numbers speak louder than descriptions.

　　Normal latency for RTMP streaming combined with FLV playback is around 2 to 3 seconds; conversely, due to its segment-based mechanism, latency of 10 to 30 seconds is considered "normal" for HLS. HTTP-FLV offers lower latency, making it suitable for scenarios requiring near real-time playback, whereas HLS has higher latency, with the 10-to-30-second range being typical.

　　Data from another perspective shows that the "time to first frame" (initial stream acquisition latency) is 4 to 10 seconds for HLS, compared to 2 to 4 seconds for HTTP-FLV. This metric reflects how long a user must wait to see the video after opening the stream, directly impacting the viewing experience.

　　Test data from a technical blog offers a useful reference: under identical conditions, HTTP-FLV content latency can be as low as approximately 1 second, while HLS latency reaches 20 seconds—a nearly twentyfold difference. While this test was conducted under specific conditions—and the gap in actual production environments may vary based on server configuration, network conditions, and player buffering strategies—the difference in order of magnitude is real.

　　Why Is HLS Still Used Despite High Latency?

　　If latency were the only criterion, HLS would be considered technically "inferior." However, it maintains a dominant position in the live streaming ecosystem thanks to advantages in other areas.

　　Compatibility is HLS's greatest competitive advantage. HLS is natively supported by Apple; the Safari browser can play it directly without any plugins. Browsers on Android also generally support it. This means you can send an HLS `.m3u8` link to someone via WeChat, and they can watch the stream immediately upon clicking it, without needing to install anything. HTTP-FLV relies on the browser's MSE (Media Source Extensions) capabilities; while support is solid in Chrome, Firefox, and Edge, it is weak in Safari and even more limited in mobile browsers.

　　CDN compatibility is another key factor. HLS segments are independent HTTP files, allowing CDNs to cache them just like standard web images. Popular segments are cached at edge nodes, so subsequent viewers retrieve them from nearby locations; this minimizes load on the origin server and offers excellent scalability. In contrast, HTTP-FLV uses long-lived connections, requiring CDN edge nodes to maintain the state of each viewer. This increases the complexity of caching and scheduling, as well as the cost of handling massive concurrency.

　　Stability is another advantage of HLS. Because the player buffers multiple segments, it can continue playback during brief network fluctuations, meaning users rarely notice any stuttering. HTTP-FLV uses smaller buffers, making it more susceptible to network jitter, which often manifests directly as video stutter or accumulated latency.

　　These advantages make HLS the more pragmatic choice for scenarios where low latency is not the primary requirement.

　　Choosing the Right Protocol: How Much Latency Can Your Business Tolerate?

　　Selecting a protocol isn't about picking the "best" one, but the "most suitable" one. The relative importance of latency, compatibility, and cost varies significantly depending on the scenario.

　　Scenarios requiring HTTP-FLV:

　　Large-screen monitoring displays on internal networks, production command centers, and equipment monitoring dashboards. Users in these scenarios need to see events as they happen; latency exceeding three seconds can impair decision-making. HTTP-FLV’s latency of 1–3 seconds meets a critical need here, while CDN and compatibility issues are generally not obstacles within an internal network.

　　HTTP-FLV is also worth considering for highly interactive private-domain live streaming scenarios. Activities such as online quizzes, auctions, and limited-time flash sales require tight synchronization between the speaker's words and the video seen by the audience. The goal of latency optimization for private-domain live streaming is to make the broadcast feel more like a "real-time" event; while standard courses might tolerate a delay of a few seconds, scenarios requiring high levels of interaction demand lower latency.

　　Scenarios where HLS is more suitable:

　　Public live events, streamed courses, and social media sharing. In these scenarios, the audience uses a wide variety of devices, making compatibility the top priority. If a live stream link shared via WeChat requires users to "open in Chrome" or "install an app," conversion rates drop significantly. The "click-and-watch" convenience of HLS in this context far outweighs the user experience improvement gained by reducing latency from 10 seconds to 3 seconds.

　　Scenarios dominated by mobile viewing also favor HLS. Comparative data shows that HLS offers superior compatibility for mobile playback. iOS devices support HLS natively, and Android browser support for HLS is far better than for HTTP-FLV.

　　A pragmatic architecture: multi-protocol output.

　　In real-world enterprise live streaming systems, rarely is only one protocol chosen. Once the source stream is ingested, the streaming server outputs both HLS and HTTP-FLV streams simultaneously. Latency-sensitive endpoints (such as large screens on an internal network) use FLV, while endpoints requiring high compatibility (such as mobile viewers accessing links via WeChat) use HLS. Streaming servers like SRS and ZLMediaKit support this multi-protocol output capability.

　　This requires no changes at the encoding stage. You simply push a single RTMP stream, and the server automatically adapts the output format based on the protocol requested by the playback client.

　　FAQ

　　Q: How much lower is HTTP-FLV latency compared to HLS?

　　A: According to various technical documents and empirical data, typical latency for HTTP-FLV ranges from 1 to 3 seconds, whereas HLS ranges from 10 to 30 seconds—a difference of approximately tenfold. A comparison of initial stream startup latency shows that HLS requires 4 to 10 seconds, whereas HTTP-FLV needs only 2 to 4 seconds. While actual latency is influenced by server performance, player buffering strategies, and network conditions, the difference in magnitude remains consistent.

　　Q: Why can't HLS latency be reduced simply by shortening the segment duration?

　　It is possible, but there is a trade-off. Reducing the segment duration from 10 seconds to 2 seconds could theoretically lower latency from 20 seconds to around 4 seconds. However, shorter segments result in more frequent playlist updates and a higher volume of HTTP requests, significantly increasing the load on servers and CDNs. Technical documentation also notes that reducing HLS latency by decreasing the number or duration of segments requires "careful consideration of the potential impact on playback stutter." Low-Latency HLS (LL-HLS) is a more complex end-to-end solution requiring coordinated support across the packager, CDN, and player; it cannot be achieved by simply tweaking a single parameter.

　　Q: My audience primarily watches the live stream via WeChat; which protocol should I choose?

　　HLS. WeChat's built-in browser offers native support for HLS, allowing `.m3u8` links to open and play directly. Support for HTTP-FLV in the WeChat browser is inconsistent—relying on MSE availability—and playback may fail on certain Android models and iOS devices. If your live stream is accessed mainly through WeChat sharing, HLS is the only reliable choice.

　　Q: For live streaming on a large screen within an intranet (without a public CDN), which one should I choose?

　　HTTP-FLV. In an intranet environment, there are no concerns regarding CDN scalability, and compatibility is not an issue (large screens typically use Chrome or dedicated players). HTTP-FLV’s latency of 1 to 3 seconds provides operators with a near-real-time view, which is crucial for monitoring and command-and-control scenarios.

　　Q: Is there a way to balance low latency with compatibility?

　　You can use dual-protocol output. The source stream is pushed to a streaming server (such as SRS), which simultaneously outputs both HLS and HTTP-FLV. The playback client automatically selects the format based on the device type: HLS for mobile browsers and HTTP-FLV for large-screen displays on the internal network. While this requires some adaptation logic on the player side, server-side configuration is straightforward; both SRS and ZLMediaKit natively support this mode.

　　Q: WebRTC offers even lower latency than HTTP-FLV—why not just use WebRTC?

　　WebRTC can achieve latency of 0.2 to 1 second, which is indeed lower. However, its implementation complexity is far higher than that of HTTP-FLV, as it requires handling signaling, ICE traversal, NAT issues, and more. Furthermore, it is not well-suited for traditional CDNs, making large-scale distribution costly. WebRTC is ideal for scenarios requiring ultra-low latency and involving a controllable audience size, such as interactive "co-hosting" (duet streaming) or real-time command-and-control operations. If your use case is simply "watching a live stream," the 1-to-3-second latency of HTTP-FLV meets the vast majority of needs; there is no need to shoulder the complexity of WebRTC just to shave off a second or two of delay.