流媒体直播播放协议：HLS、RTMP、HTTP-FLV

  • 一、推拉流
  • 二、协议介绍
  • 1. HLS
  • 2. RTMP
  • 3. HDL (HTTP-FLV)


一、推拉流

直播流协议架构 直播拉流协议_网络


在开始之前，先把流媒体服务中的双端关系说一下：在一个完整的流媒体服务框架中，角色就是“两端加一服”。推流端、拉流端加上媒体服务器。

同时按照应用场景的不同，协议又分：推流协议、拉流播放协议。

其中，RTMP 可以用在双端，但 HLS 只能用在拉流端。

  • 推流
    推流，指的是把采集阶段封包好的内容传输到服务器的过程。其实就是将现场的视频信号传到网络的过程。
    “推流”对网络要求比较高，如果网络不稳定，直播效果就会很差，观众观看直播时就会发生卡顿等现象，观看体验很是糟糕。
    要想用于推流还必须把音视频数据使用传输协议进行封装，变成流数据。使用 RTMP 传输的延时通常在 1–3 秒，对于手机直播这种实时性要求非常高的场景，RTMP 也成为手机直播中最常用的流传输协议。
    最后通过一定的 Qos 算法将音视频流数据推送到网络端，通过 CDN 进行分发。
    在直播场景中，网络不稳定是非常常见的，这时就需要 Qos 来保证网络不稳情况下的用户观看直播的体验，通常是通过主播端和播放端设置缓存，让码率均匀。
    另外，针对实时变化的网络状况，动态码率和帧率也是最常用的策略。
  • 拉流
    拉流是指服务器已有直播内容，根据协议类型（如RTMP、RTP、RTSP、HTTP等），与服务器建立连接并接收数据，进行拉取的过程。
    拉流端的核心处理在播放器端的解码和渲染，在互动直播中还需集成聊天室、点赞和礼物系统等功能。
    拉流端现在支持 RTMP、HLS、HDL（HTTP-FLV）三种协议，其中，在网络稳定的情况下，对于 HDL 协议的延时控制可达 1s，完全满足互动直播的业务需求。
    RTMP 是 Adobe 的专利协议，开源软件和开源库都支持的比较好，延时一般在 1-3 秒。
    HLS 是苹果提出的基于 HTTP 的流媒体传输协议，优点是跨平台性比较好，HTML5 可以直接打开播放，移动端兼容性良好，但是缺点是延迟比较高。

二、协议介绍

直播流协议架构 直播拉流协议_直播流协议架构_02

1. HLS

HLS 全称是 HTTP Live Streaming。这是 Apple 提出的直播流协议，是通过视频流切片成文件片段来直播的。目前，IOS 和 高版本 Android 都支持 HLS。

HLS 主要的两块内容是 .m3u8 文件和 .ts 播放文件。

其中 .m3u8 作为索引文件（确保包的顺序）

接受服务器会将接受到的视频流进行缓存，然后缓存到一定程度后，会将这些视频流进行编码格式化，同时会生成一份 .m3u8 文件和其它很多的 .ts 文件。

客户端首先会请求一个m3u8文件，里面会有不同码率的流，或者直接是ts文件列表，通过给出的ts文件地址去依次播放。在直播的时候，客户端会不断请求m3u8文件，检查ts列表是否有新的ts切片。这种方式的实时性较差，不过优势是H5、IOS、Android都原生支持。

实际上HLS作为拉流端，效率并不低，延时高的原因大概是因为HLS的实现方案：

直播流协议架构 直播拉流协议_HTTP_03


在上图的生产环境中，以 RTMP 协议推流，HLS 拉流。端到端的时间消耗是：

RTMP 推流端的联通成本是 700ms ，注意此时的 700ms 包含了 connect 和 send video data ；

推流端联通之后的时间成本，主要是采集编码封包的成本，不需要再次connect；

HLS 的请求响应成本是 300ms；

flv to ts 的成本，用 ffmpeg 切一个 10 秒的码率 500 的视频，算上磁盘的写入时间最多 200ms；

所以说，HLS 的慢的原因只有一个，就是等数据！

  • 优势
  • H5 可以直接打开播放，移动端兼容性良
  • 使用 HTTPS 加密 ts 文件
  • 快/倒放
  • 广告插入
  • 不同分辨率视频切换
  • 穿透防火墙。基于 HTTP/80 传输，有效避免防火墙拦截。
  • 性能高。通过 HTTP 传输，支持网络分发，CDN 支持良好，且自带多码率自适应。
  • 劣势
  • 实时性差，延迟高。HLS 的延迟基本在 10s+ 以上。
  • 文件碎片。特性的双刃剑，ts 切片较小，会造成海量小文件，对存储和缓存都有一定的挑战。

2. RTMP

RTMP，全称 Real Time Messaging Protocol，即实时消息传送协议。

纯 RTMP 使用 TCP 连接，默认端口为 1935（有可能被封）。

是 Adobe Systems 公司为 Flash 播放器和服务器之间音频、视频和数据传输开发的开放协议。协议基于 TCP，是一个协议族，包括 RTMP 基本协议及 RTMPT/RTMPS/RTMPE 等多种变种。

RTMP 由于借由 TCP 长连接协议，所以，客户端向服务端推流这些操作而言，延时性很低。

它会将上传的流分成不同的分片，这些分片的大小，有时候变，有时候不会变。

默认情况下就是，64B 的音频数据 + 128B 的视频数据 + 其它数据（比如 头，协议标签等）。

但 RTMP 具体传输的时候，会将分片进一步划分为包，即，视频包，音频包，协议包等。因为，RTMP 在进行传输的时候，会建立不同的通道，来进行数据的传输，这样对于不同的资源，对不同的通道设置相关的带宽上限。

RTMP 是一种设计用来进行实时数据通信的网络协议，主要用来在 Flash/AIR 平台和支持 RTMP 协议的流媒体/交互服务器之间进行音视频和数据通信。这种方式的实时性比较强，基本能保证延迟在 1-2s 内，是现在国内直播主要采用的方式之一。不过使用这种协议，就必须安装 flash，而 H5、IOS、Android 并不能原生支持 flash，因此这种协议能流行多久，就不得而知了，毕竟移动端才是现在的主流。

FLV (Flash Video) 是 Adobe 公司推出的另一种视频格式，是一种在网络上传输的流媒体数据存储容器格式。其格式相对简单轻量，不需要很大的媒体头部信息。整个 FLV 由 The FLV Header，The FLV Body 以及其它 Tag 组成。因此加载速度极快。采用 FLV 格式封装的文件后缀为 .flv。

直播流协议架构 直播拉流协议_网络协议_04

现在推流协议各大云厂商基本都是直接支持 RTMP 。

拉流用 RTMP 的话就不太现实了，现在对 flash 支持都不友好了。

3. HDL (HTTP-FLV)

HTTP-FLV 就是对 RTMP 协议的封装，都是针对于 FLV 视频格式做的直播分发流。相比于 RTMP，它是一个开放的协议，因此他具备了 RTMP 的实时性和 RTMP 不具备的开发性。而且随着 flv.js 的出现，使得浏览器在不依赖 flash 的情况下，播放 flv 视频，从而兼容了移动端，所以现在很多直播平台，尤其是手机直播平台，都会选择它。

因为 RTMP 发的包很容易处理，通常 RTMP 协议会作为视频上传端来处理，然后经由服务器转换为 FLV 文件，通过 HTTP-FLV 下发给用户。

参考：

  1. 直播协议RTMP、HLS、HTTP FLV
  2. 理解RTMP、HttpFlv和HLS的正确姿势
  3. 流媒体直播播放三大件PK：RTMP/HLS/HTTP-FLV