直播原理大揭秘

什么是直播系统

随着移动网络网速的提升与资费的降低，视频直播作为一个新的娱乐方式已经被越来越多的用户逐渐接受。特别是最近这几年，视频直播已经不仅仅被运用在传统的秀场、游戏类板块，更是作为电商的一种新模式得到迅速成长。

本文将通过介绍实时视频直播技术体系，包括常用的推拉流架构、传输协议等，让你对现今主流的视频直播技术有一个基本的认知。

直播架构概览

目前直播推拉流主流程依赖于某云直播的服务。

云直播提供的推流方式有两种：

• 1）一是通过集成SDK的方式进行推流（用于手机端开播）；
• 2）另一种是通过RTMP协议向远端服务器进行推流（用于PC开播端或专业控台设备开播）。

推拉流架构1：厂商SDK推拉流

如上题所示，这一种推拉流架构方式需要依赖腾讯这类厂商提供的手机互动直播SDK，通过在主播端APP和用户端APP都集成SDK，使得主播端和用户端都拥有推拉流的功能。

这种推拉流架构的逻辑原理是这样的：

1）主播端和用户端分别与云直播的互动直播后台建立长连接；
2）主播端通过UDT私有协议向互动直播后台推送音视频流；
3）互动直播后台接收到音视频流后做转发，直接下发给与之建立连接的用户端。

这种推拉流方式有几点优势：

1）只需要在客户端中集成SDK：通过手机就可以开播，对于主播开播的要求比较低，适合直播业务快速铺开；
2）互动直播后台仅做转发：没有转码，上传CDN等额外操作，整体延迟比较低；
3）主播端和用户端都可以作为音视频上传的发起方：适合连麦、视频会话等场景。

推拉流架构2：旁路推流

之前介绍了通过手机SDK推拉流的直播方式，看起来在手机客户端中观看直播的场景已经解决了。

那么问题来了：如果我想要在H5、小程序等其他场景下观看直播，没有办法接入SDK，需要怎么处理呢？

这个时候需要引入一个新的概念——旁路推流。

旁路推流指的是：通过协议转换将音视频流对接到标准的直播 CDN 系统上。

目前云直播开启旁路推流后，会通过互动直播后台将音视频流推送到云直播后台，云直播后台负责将收到音视频流转码成通用的协议格式并且推送到CDN，这样H5、小程序等端就可以通过CDN拉取到通用格式的音视频流进行播放了。

协议类型有HLS、FLV、RTMP三种，已经可以覆盖到所有的播放场景

推拉流架构3：RTMP推流

随着直播业务发展，一些主播逐渐不满足于手机开播的效果，并且电商直播需要高保真地将商品展示在屏幕上，需要通过更加高清专业的设备进行直播，RTMP推流技术应运而生。

我们通过使用OBS等流媒体录影程序，对专业设备录制的多路流进行合并，并且将音视频流上传到指定的推流地址。由于OBS推流使用了RTMP协议，因此我们称这一种推流类型为RTMP推流。

我们首先在云直播后台申请到推流地址和秘钥，将推流地址和秘钥配置到OBS软件当中，调整推流各项参数，点击推流以后，OBS就会通过RTMP协议向对应的推流地址推送音视频流。

这一种推流方式和SDK推流的不同之处在于音视频流是直接被推送到了云直播后台进行转码和上传CDN的，没有直接将直播流转推到用户端的下行方式，因此相比SDK推流延迟会长一些。

总结下来RTMP推流的优势和劣势比较明显。

优势主要是：

1）可以接入专业的直播摄像头、麦克风，直播的整体效果明显优于手机开播；
2）OBS已经有比较多成熟的插件，比如目前蘑菇街主播常用YY助手做一些美颜的处理，并且OBS本身已经支持滤镜、绿幕、多路视频合成等功能，功能比手机端强大。

劣势主要是：

1）OBS本身配置比较复杂，需要专业设备支持，对主播的要求明显更高，通常需要一个固定的场地进行直播；
2）RTMP需要云端转码，并且本地上传时也会在OBS中配置GOP和缓冲，延时相对较长。

高可用架构方案：云互备

业务发展到一定阶段后，我们对于业务的稳定性也会有更高的要求，比如当云服务商服务出现问题时，我们没有备用方案就会出现业务一直等待服务商修复进度的问题。

因此云互备方案就出现了：云互备指的是直播业务同时对接多家云服务商，当一家云服务商出现问题时，快速切换到其他服务商的服务节点，保证业务不受影响。

我们通过在云直播后台中转推一路流到备份云平台上，备份云在接收到了直播流后会对流转码并且上传到备份云自身的CDN系统当中。一旦主平台CDN节点出现问题，我们可以将下发的拉流地址替换成备份云拉流地址，这样就可以保证业务快速修复并且观众无感知。

视频封装格式

常见的视频封装格式(简称：视频格式)包括了 AVI，MPEG，VOB 等，即相当于一种储存视频信息的容器，由相应的公司开发出来的。

AVI

AVI 格式(后缀为.AVI)：它的英文全称为 Audio Video Interleaved，即音频视频交错格式。它于 1992 年被 Microsoft 公司推出。

这种视频格式的优点是图像质量好。由于无损 AVI 可以保存 alpha 通道，经常被我们使用。缺点太多，体积过于庞大，而且更加糟糕的是压缩标准不统一，最普遍的现象就是高版本 Windows 媒体播放器播放不了采用早期编码编辑的 AVI 格式视频，而低版本 Windows 媒体播放器又播放不了采用最新编码编辑的 AVI 格式视频，所以我们在进行一些 AVI 格式的视频播放时常会出现由于视频编码问题而造成的视频不能播放或即使能够播放，但存在不能调节播放进度和播放时只有声音没有图像等一些莫名其妙的问题。

DV-AVI

DV-AVI 格式(后缀为.AVI)：DV 的英文全称是 Digital Video Format，是由索尼、松下、JVC 等多家厂商联合提出的一种家用数字视频格式。

数字摄像机就是使用这种格式记录视频数据的。它可以通过电脑的 IEEE 1394 端口传输视频数据到电脑，也可以将电脑中编辑好的的视频数据回录到数码摄像机中。这种视频格式的文件扩展名也是 avi。电视台采用录像带记录模拟信号，通过 EDIUS 由 IEEE 1394 端口采集卡从录像带中采集出来的视频就是这种格式。

MOV

QuickTime File Format 格式(后缀为.MOV)：美国 Apple 公司开发的一种视频格式，默认的播放器是苹果的 QuickTime。

具有较高的压缩比率和较完美的视频清晰度等特点，并可以保存 alpha 通道。大家可能注意到了，每次安装 EDIUS，我们都要安装苹果公司推出的 QuickTime。安装其目的就是为了支持 JPG 格式图像和 MOV 视频格式导入。

MPEG

MPEG 格式(文件后缀可以是 .MPG .MPEG .MPE .DAT .VOB .ASF .3GP .MP4 等)：它的英文全称为 Moving Picture Experts Group，即运动图像专家组格式，该专家组建于 1988 年，专门负责为 CD 建立视频和音频标准，而成员都是为视频、音频及系统领域的技术专家。

MPEG 文件格式是运动图像压缩算法的国际标准。MPEG 格式目前有三个压缩标准，分别是 MPEG－1、MPEG－2、和 MPEG－4。MPEG－1、MPEG－2 目前已经使用较少，着重介绍 MPEG－4，其制定于 1998 年，MPEG－4 是为了播放流式媒体的高质量视频而专门设计的，以求使用最少的数据获得最佳的图像质量。目前 MPEG-4 最有吸引力的地方在于它能够保存接近于 DVD 画质的小体积视频文件。你可能一定注意到了，怎么没有 MPEG－3 编码，因为这个项目原本目标是为高分辨率电视(HDTV)设计，随后发现 MPEG-2 已足够 HDTV 应用，故 MPEG-3 的研发便中止。

WMV

WMV 格式(后缀为.WMV .ASF)：它的英文全称为 Windows Media Video，也是微软推出的一种采用独立编码方式并且可以直接在网上实时观看视频节目的文件压缩格式。

WMV 格式的主要优点包括：本地或网络回放,丰富的流间关系以及扩展性等。WMV 格式需要在网站上播放，需要安装 Windows Media Player(简称 WMP)，很不方便，现在已经几乎没有网站采用了。

Real Video

Real Video 格式(后缀为.RM .RMVB)：Real Networks 公司所制定的音频视频压缩规范称为 Real Media。

用户可以使用 RealPlayer 根据不同的网络传输速率制定出不同的压缩比率，从而实现在低速率的网络上进行影像数据实时传送和播放。RMVB 格式：这是一种由 RM 视频格式升级延伸出的新视频格式，当然性能上有很大的提升。RMVB 视频也是有着较明显的优势，一部大小为 700MB 左右的 DVD 影片，如果将其转录成同样品质的 RMVB 格式，其个头最多也就 400MB 左右。大家可能注意到了，以前在网络上下载电影和视频的时候，经常接触到 RMVB 格式，但是随着时代的发展这种格式被越来越多的更优秀的格式替代，著名的人人影视字幕组在 2013 年已经宣布不再压制 RMVB 格式视频。

FLV

Flash Video 格式(后缀为.FLV)：由 Adobe Flash 延伸出来的的一种流行网络视频封装格式。随着视频网站的丰富，这个格式已经非常普及。

MKV

Matroska 格式(后缀为.MKV)：是一种新的多媒体封装格式，这个封装格式可把多种不同编码的视频及 16 条或以上不同格式的音频和语言不同的字幕封装到一个 Matroska Media 档内。它也是其中一种开放源代码的多媒体封装格式。Matroska 同时还可以提供非常好的交互功能，而且比 MPEG 的方便、强大。

直播协议

常用的直播协议包括了 HLS, RTMP 与 HTTP-FLV 这三种，其对比如下：

协议	优势	缺陷	延迟性
HLS	支持性广	延时巨高	10s 以上
RTMP	延时性好，灵活	量大的话，负载较高	1s 以上
HTTP-FLV	延时性好，游戏直播常用	只能在手机 APP 播放	2s 以上

HLS

HLS, HTTP Live Streaming 是 Apple 提出的直播流协议，其将整个流分成一个个小的块，并基于 HTTP 的文件来下载；HLS 由两部分构成，一个是 .m3u8 文件，一个是 .ts 视频文件；每一个 .m3u8 文件，分别对应若干个 ts 文件，这些 ts 文件才是真正存放视频的数据，m3u8 文件只是存放了一些 ts 文件的配置信息和相关路径，当视频播放时，.m3u8 是动态改变的，video 标签会解析这个文件，并找到对应的 ts 文件来播放，所以一般为了加快速度，.m3u8 放在 web 服务器上，ts 文件放在 CDN 上。 HLS 协议视频支持 H.264 格式的编码，支持的音频编码方式是 AAC 编码。

.m3u8 文件，其实就是以 UTF-8 编码的 m3u 文件，这个文件本身不能播放，只是存放了播放信息的文本文件：

HLS 协议的使用也非常便捷，将 m3u8 直接写入到 src 中然后交与浏览器解析，也可以使用 fetch 来手动解析并且获取相关文件：

HLS 详细版的内容比上面的简版多了一个 playlist，也可以叫做 master。在 master 中，会根据网络段实现设置好不同的 m3u8 文件，比如，3G/4G/wifi 网速等。比如，一个 master 文件中为：

以 high.m3u8 文件为例，其内容会包含：

该二级 m3u8 文件也可以称为 media 文件，其有三种类型：

• live playlist: 动态列表。顾名思义，该列表是动态变化的，里面的 ts 文件会实时更新，并且过期的 ts 索引会被删除。默认，情况下都是使用动态列表。
• event playlist: 静态列表。它和动态列表主要区别就是，原来的 ts 文件索引不会被删除，该列表是不断更新，而且文件大小会逐渐增大。它会在文件中，直接添加 #EXT-X-PLAYLIST-TYPE:EVENT 作为标识。
• VOD playlist: 全量列表。它就是将所有的 ts 文件都列在 list 当中。如果，使用该列表，就和播放一整个视频没有啥区别了。它是使用 #EXT-X-ENDLIST 表示文件结尾。

显而易见，HLS 的延时包含了 TCP 握手、m3u8 文件下载与解析、ts 文件下载与解析等多个步骤，可以缩短列表的长度和单个 ts 文件的大小来降低延迟，极致来说可以缩减列表长度为 1，并且 ts 的时长为 1s，但是这样会造成请求次数增加，增大服务器压力，当网速慢时回造成更多的缓冲，所以苹果官方推荐的 ts 时长时 10s，所以这样就会大改有 30s 的延迟。

RTMP

RTMP，Real-Time Messaging Protocol 是由 Adobe 推出的音视频流传递协议；它通过一种自定义的协议，来完成对指定直播流的播放和相关的操作。在 Web 上可以通过 MSE（MediaSource Extensions）来接入 RTMP，基本思路是根据 WebSocket 直接建立长连接进行数据的交流和监听。RTMP 协议根据不同的套层，也可以分为：

• 纯 RTMP: 直接通过 TCP 连接，端口为 1935
• RTMPS: RTMP + TLS/SSL，用于安全性的交流。
• RTMPE: RTMP + encryption。在 RTMP 原始协议上使用，Adobe 自身的加密方法
• RTMPT: RTMP + HTTP。使用 HTTP 的方式来包裹 RTMP 流，这样能直接通过防火墙。不过，延迟性比较大。
• RTMFP: RMPT + UDP。该协议常常用于 P2P 的场景中，针对延时有变态的要求。

RTMP 内部是借由 TCP 长连接协议传输相关数据，所以，它的延时性非常低。并且，该协议灵活性非常好（所以，也很复杂），它可以根据 message stream ID 传输数据，也可以根据 chunk stream ID 传递数据。两者都可以起到流的划分作用。流的内容也主要分为：视频，音频，相关协议包等。

HTTP-FLV
RTMP 是直接将流的传输架在 RTMP 协议之上，而 HTTP-FLV 是在 RTMP 和客户端之间套了一层转码的过程，即：

每个 FLV 文件是通过 HTTP 的方式获取的，所以，它通过抓包得出的协议头需要使用 chunked 编码：

QoS 策略

客户端推流除了需要考虑网络上传能力以外，还需要考虑客户端的计算能力。如果在 5 年前的安卓机上去编码一个分辨率为 640P 的高清视频流，那这个过程必然会产生延迟甚至无法工作。为此需要针对各个终端的计算能力设计一个 QoS 策略，不同计算能力的终端采用不同的视频编码器、分辨率、音频处理算法等，这个 QoS 策略会配合拥塞控制做一个状态不可逆的查找过程，直到找到最合适的 QoS 策略位置