HTTP直播流HLS

wen IT资讯 2026-07-01 26

本文目录导读：

HTTP直播流HLS

HTTP Live Streaming（简称 HLS） 是由苹果公司提出的一项基于 HTTP 的流媒体网络传输协议。

它诞生的核心目的是为了解决传统流媒体协议（如 RTMP）难以穿透防火墙、需要专用服务器等问题，HLS 是目前互联网上主流的直播和点播技术之一，广泛应用于视频网站、移动端直播（如 iOS/Android 的直播 App）以及 OTT（互联网电视）等领域。

以下是关于 HLS 的详细解析：

核心思想：切分与索引

HLS 的核心原理非常简单,只有两步：

切片：服务器将一整段连续的直播或点播视频流，切割成一系列连续的、时长较短的小文件（通常为 .ts 格式，MPEG-2 Transport Stream 文件）。
索引：服务器生成一个或多个索引文件（通常是 .m3u8 格式）,记录这些切片文件的顺序和地址。

播放器要做的事情就是：先下载 .m3u8 文件，按顺序拉取 .ts 文件并播放。

.m3u8 索引文件（Playlist）
- 这是入口文件，它是一个纯文本文件,类似于一个播放列表。
- 主索引文件：用于“自适应码率”场景，里面不直接写 .ts 文件的地址，而是写多个“子索引文件”的地址（每个子索引对应不同画质：如 360P、720P、1080P）。
- 媒体索引文件：里面列出了具体的 .ts 文件地址和时长。
.ts 视频切片
- TS 是 Transport Stream（传输流）的缩写。
- 它是一个容器格式，里面封装了视频（H.264/H.265）、音频（AAC/MP3）以及字幕等信息。
- 每个切片的时长通常为 2 到 10 秒，切片越短，延迟越低，但对服务器的 I/O 压力也越大。

这是 HLS 被诟病最多的地方。

传统延迟：为了确保播放的流畅性，HLS 默认会等待获取 3 个切片（约 6-30 秒）才开始播放，这导致 HLS 的延迟通常较高（20-40 秒）。
低延迟 HLS：近年来，苹果推出了 LL-HLS，它通过“部分分发”技术，允许播放器在切片还没完全生成时就开始下载片头，从而将延迟降低到 2-5 秒（但还是比 WebRTC 高）。

点播与直播功能二合一
- 一个 .m3u8 文件动态更新就是直播；文件固定不变就是点播。
完美兼容现有的 HTTP 基础设施
- 不需要像 RTMP 那样需要专门的流媒体服务器。
- 可以利用 CDN（内容分发网络）、HTTP 缓存、代理服务器进行分发和加速。
- 不怕防火墙，因为 HTTP 的 80/443 端口通常都开放。
自适应码率
- 播放器可以根据用户当前的网络速度，在多个 .m3u8 子文件中无缝切换。
- 网络好时看 1080P，网络差时自动切到 360P,中间不用暂停。

延迟较高：传统的 HLS 延迟通常在 15 秒到 1 分钟之间，相比 RTMP（2-5秒）和 WebRTC（<1秒）有明显劣势。
文件碎片化严重：长视频会产生成千上万个 .ts 文件，对文件系统的管理和缓存是很大的负担（现在常用“碎片化 mp4”，即 fMP4 来替代 .ts 减轻压力）。
比较复杂的录制逻辑：服务器需要实时切片,对服务器编码和切片能力有要求。

推流：主播将 RTMP 推流到服务器（服务器通常是 Nginx + RTMP 模块或 SRS 等）。
转码与切片：服务器收到流后，用 FFmpeg 或专门的切片器，将视频转码为 H.264，音频转码为 AAC，然后切成 6 秒一个的 .ts 文件，并不断更新 .m3u8 文件。
发布：服务器将 .m3u8 和 .ts 推送到 CDN 节点。
拉流：观众的播放器（如 video.js、hls.js、Apple Safari、Android ExoPlayer）请求 .m3u8 地址，CDN 返回文件，播放器顺序下载 .ts 并播放。

如何播放 .m3u8 文件？
- 网页端：推荐使用 hls.js 库（即以前的开源播放器 video.js + hls.js），或直接使用 Safari 浏览器（原生支持）。
- 移动端：iOS 原生的 AVPlayer、Android 的 ExoPlayer 原生支持。
怎么检查 HLS 是否工作？
- 打开 Chrome 开发者工具，看 Network 标签，如果看到 .m3u8 请求后立刻有一连串 .ts 请求，且状态码为 206（Partial Content，部分内容），则证明 HLS 正常工作。

HLS = m3u8（播放列表）+ ts（碎片化视频）+ HTTP（传输方式）

它牺牲了延迟，换来了无与伦比的兼容性和可靠性，如果你正在开发一个面向大众用户的视频点播平台或直播平台，HLS 通常是首选的封装与分发方式。