在 HLS 和 HTTP-FLV 之间做选择，不仅仅是决定哪种格式更新。正确的选择取决于观众需要做什么、他们在哪里观看、平台必须支持多少并发连接，以及应用程序能容忍多大延迟。公共网络直播、基于浏览器的监控控制台和移动端实时观看应用可能始于相同的视频源，但需要不同的传输路径。
本指南说明了每种技术的作用，并展示了如何将它们组合到实用的流媒体架构中。它保留了本质区别：HLS 专为通过标准 HTTP 基础设施进行可靠、自适应的传输而设计，而 HTTP-FLV 通过 HTTP 连接发送连续的 FLV 流，通常在浏览器播放需要更接近实时时被选用。
首先区分协议、传输和容器
HLS、FLV、HTTP-FLV 和 RTMP 这些术语经常被当作描述同一层来使用，但事实并非如此。
-
HLS（HTTP Live Streaming） 是 Apple 最初开发的媒体传输协议。它使用播放列表和通过 HTTP 或 HTTPS 传输的一系列媒体分片。
-
FLV（Flash Video） 是一种容器格式，可以承载编码后的音频和视频。FLV 本身并不定义流如何在网络上传输。
-
HTTP-FLV 通过 HTTP 连接保持 FLV 流持续打开。播放器连续接收媒体，而不是请求播放列表和单独的分片。
-
RTMP 是一种独立的流协议，历史上与 Flash 相关。它在推流或输入侧仍然常见，即使观众接收的是 HLS 或其他输出格式。
这种区分在系统设计时很重要。平台可以从编码器接收 RTMP 流，一次性处理源流，然后为不同观众群体发布 HLS 和 HTTP-FLV 输出。因此，选择传输方式不一定需要更改摄像机、编码器或上游推流协议。
为什么分片传输在大规模场景下表现出色
HLS 将直播或点播节目分成媒体分片，并在 M3U8 播放列表中列出它们。传统部署通常使用 MPEG-2 Transport Stream 分片，通常以 .ts 扩展名标识。现代 HLS 也可以使用碎片化 MP4（通常称为 fMP4），这为当代编码和打包工作流提供了实用的基础。音频和字幕可以作为独立的呈现版本与视频一同提供。
由于播放列表和分片是普通的 HTTP 资源，它们可以通过标准 Web 服务器、反向代理和内容分发网络（CDN）来提供。边缘缓存可以将热门分片保存在靠近观众的位置，从而减少对源站的重复流量。这使得 HLS 非常适合公共直播活动、培训门户、移动应用和具有地理分布受众的服务。
自适应比特率传输是另一个核心优势。平台会准备同一节目的多个不同分辨率和比特率的版本。根据当前吞吐量、缓冲区状态和设备能力，播放器可以在这些变体之间切换，以保持播放稳定。在移动网络变化中的观众可能会接收到较低分辨率的版本，而不是经历完全的中断。
其代价是传统的 HLS 播放通常需要等待分片创建、播放列表更新和播放缓冲区。实际延迟取决于分片时长、播放列表设计、播放器设置和网络条件。低延迟 HLS 可以减少这种延迟，但它需要在打包器、源站、CDN 和播放器之间进行协调支持。应将其视为端到端的设计选择，而不是在最后阶段添加的开关。
分片时长应根据服务目标来选择。较短的分片可以帮助播放器更快地发现新媒体，但也会增加播放列表更新、对象请求和打包开销。较长的分片减少了请求频率，可能提高传输效率，但可能增加启动时间并使质量切换响应变慢。编码器的关键帧间隔必须遵循打包计划，以便每个呈现版本在相同位置提供清晰的切换点。
连续 HTTP 流仍然适用的场景
HTTP-FLV 通过一个长生命周期的 HTTP 响应发送 FLV 标签。一旦播放开始，媒体数据会通过同一连接持续到达。无需刷新分片播放列表，因此正确调优的系统通常可以比传统的分片工作流保持更接近直播源。
这种特性在面向操作员的应用中非常有用，这些场景下人员需要观察事件并快速反应：视频监控页面、生产仪表板、设备监管、远程检查以及内部实时查看系统。它还可以简化通过已经允许 HTTP 或 HTTPS 流量的网络的传输。
然而，不应将 HTTP-FLV 与浏览器的原生视频支持混淆。Adobe Flash Player 的终结移除了旧的插件播放路径：Adobe 于 2020 年 12 月 31 日终止了 Flash Player 支持，并于 2021 年 1 月 12 日开始阻止 Flash 内容。因此，现代 HTTP-FLV 播放依赖于 HTML5 播放器，通常使用 JavaScript 解析 FLV 流，并通过浏览器媒体 API 将受支持的音频和视频编解码器送入解码器。
这带来了兼容性依赖。浏览器必须支持所需的媒体 API 以及 FLV 容器内携带的编解码器。因此，HTTP-FLV 更适合受控的 Web 客户端和专用应用程序，而非无限制的公共受众。大量持续连接也会对传输服务器和中间网络设备造成比可缓存的分片对象更持续的压力。
根据观看需求匹配传输路径
协议决策应从运营需求出发，而不是从功能清单开始。以下比较提供了一个有用的起点。
| 决策因素 | HLS | HTTP-FLV |
|---|---|---|
| 传输模型 | 播放列表 + 媒体分片 | 通过 HTTP 或 HTTPS 的连续 FLV 流 |
| 典型优先级 | 稳定播放和广泛分发 | 降低直播观看的延迟 |
| 自适应比特率 | 通过变体流内置于协议中 | 非固有；通常需要应用特定的流切换 |
| CDN 效率 | 高，因为分片可作为 HTTP 对象缓存 | 较有限，因为每个观众维持一个持续响应 |
| 客户端覆盖 | 在 Apple 设备、移动平台、智能设备和 Web 播放器生态中表现强劲 | 在受控浏览器或具备兼容播放器的专用应用中最佳 |
| 网络变化应对 | 当提供多个版本时，能很好地处理带宽变化 | 更敏感，除非应用自身提供质量切换逻辑 |
| 适用场景 | 公共直播、移动观看、视频门户和大规模受众 | 监控控制台、内部系统和低延迟浏览器观看 |
当受众规模不可预测、观众使用各种设备、播放连续性比即时性更重要，或者 CDN 分发属于计划的一部分时，请将 HLS 作为主要输出。当平台控制 Web 播放器、受众已知、同时观看人数可管理，并且降低直播延迟具有明确的运营价值时，请使用 HTTP-FLV。
在批准任一方案之前，请为每个阶段定义延迟预算：采集、编码、网络接收、媒体处理、分发、播放器缓冲和解码。这可以防止将传输协议归咎于其他环节引入的延迟。低延迟输出无法弥补编码器长 GOP、过载的转码器或配置了较大安全缓冲区的播放器。请在最终生产环境和网络上测量实际结果。
两种选项都不适用于所有形式的实时通信。如果用户必须进行双向对话或操作需要极紧密交互时序的设备，则实时通信技术可能更合适。关键点是在选择传输架构之前，将单向视频分发与交互式媒体区分开。
混合设计可覆盖更多用户，而无需重复源流
许多项目并不需要非此即彼的决策。混合平台可以接收一个源流，统一时间戳和编解码器，然后为不同客户端打包独立的输出。
-
接收源流。 通过现场设备支持的推流协议，从摄像机、编码器、网关或上游平台接收直播视频。
-
检查媒体。 在决定流是可直接重新打包还是必须转码之前，验证编解码器、分辨率、帧率、音频格式和时间戳连续性。
-
创建传输版本。 为 HLS 生成自适应比特率阶梯。仅为需要且能解码其媒体配置的客户端生成 HTTP-FLV 输出。
-
分离受众路径。 将 HLS 通过源站和 CDN 发送，用于外部或大规模观看。将 HTTP-FLV 通过受控的传输集群路由给运营用户。
-
应用访问控制。 根据每条路径使用 HTTPS、短期授权、源站保护和会话策略。
-
测量完整链路。 监控接收连续性、转码负载、打包错误、首帧时间、缓冲、断连和端到端延迟。
这种模式避免强迫每个客户端接受同一种折中方案。公共观众获得有弹性、可扩展的流，而操作员可以使用低延迟路径。媒体平台也成为将旧式源格式转换为当前浏览器和应用可消费输出的转换点。
在重新打包和转码之间选择
如果输入的编解码器已经符合传输配置，平台可能只需要重新打包压缩媒体。重新打包会更改容器或输出结构，而无需解码和编码每一帧，因此通常消耗较少的处理资源并保持源质量。仅当编解码器支持、时间戳、关键帧放置和音频参数已经适合目标播放器时，才适用。
当目标客户端无法解码源编解码器、需要多个分辨率和比特率，或者必须规范化帧率、音频格式和关键帧结构时，则需要转码。它会增加计算成本和加工延迟，因此容量应根据峰值并发频道数而非平均使用量来计算。硬件加速可以增加频道密度，但仍需使用所选播放器测试输出质量和行为。
生产系统还应消除单点故障。使用冗余源站、受控的播放器重连和经过测试的故障转移规则，同时避免创建激进的、会放大故障的重试循环。
可避免可预防故障的部署检查项
仅选择协议并不能保证服务的可靠性。上线前，请验证完整的媒体和网络路径。
-
确认端点的编解码器支持。 传输可以成功到达播放器，但播放仍然可能失败，因为浏览器无法解码音频或视频配置。
-
保持时间戳连续。 损坏或非单调的时间戳可能导致卡顿、音频漂移和质量切换失败。
-
使关键帧与打包规则对齐。 HLS 版本应使用协调的关键帧边界，以便播放器能在无明显干扰的情况下切换质量。
-
规划从源站到播放器的 HTTPS。 安全页面不应请求不安全的媒体，且证书必须在源站和分发层均有效。
-
测试真实网络条件。 在有限带宽、丢包和短暂中断下验证启动、恢复和质量变化，而不仅仅是在本地网络上测试。
-
根据连接行为规划容量。 HLS 容量规划主要侧重分片请求、存储和缓存命中率。HTTP-FLV 规划必须考虑长生命周期的并发连接和持续出流量。
-
提供回退策略。 如果首选播放器或格式不可用，应用程序应返回受支持的替代方案或明确的错误，而不是无限重试。
对于大多数面向外部的服务，HLS 是更安全的默认选择，因为它将自适应比特率播放与成熟的 HTTP 分发相结合。当受管播放器和更低延迟比通用覆盖更重要时，HTTP-FLV 仍然有用。当同一个直播源必须同时服务这两类群体时，混合架构通常是最实际的答案。
常见问题
能否在直播工作流中添加字幕？
可以。字幕可以在上游生成或在媒体处理期间插入。对于 HLS，WebVTT 字幕版本是一种常见选择。自定义 HTTP-FLV 播放器可能需要单独的定时文本通道及其自身的同步逻辑。
直播活动进行时，观众可以回退吗？
如果服务保留了足够长的直播窗口并且播放器暴露了时移控制，则可以。在启用直播回退之前，应定义保留窗口、存储容量和内容版权。
当视频带宽不可用时，播放器能否回退到仅音频？
可以，前提是平台发布了纯音频版本或单独的音频流，并且播放器配置为选择它。这可以在高度受限的连接上保留关键解说或指令。
分析能否区分观众退出和网络故障？
仅凭单个断连事件无法区分。结合播放器事件、心跳间隔、会话标识符、重试行为和服务器连接日志，可以更可靠地对退出进行分类。
直播结束后的 URL 应该如何处理？
平台可以关闭直播会话、发布结束画面，或在处理完成后将用户重定向到存档节目。请提前定义过渡方式，以免嵌入式播放器和共享链接在没有说明的情况下失败。
