本文由蘑菇街前端开发工程师“三体”分享，原题“蘑菇街云端直播摸索——启航篇”，有订正。

1、引言

随着挪动网络网速的晋升与资费的升高，视频直播作为一个新的娱乐形式曾经被越来越多的用户逐步承受。特地是最近这几年，视频直播曾经不仅仅被使用在传统的秀场、游戏类板块，更是作为电商的一种新模式失去迅速成长。

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

学习交换：

  • 挪动端IM开发入门文章：《新手入门一篇就够：从零开发挪动端IM》
  • 开源IM框架源码：https://github.com/JackJiang2...（备用地址点此）

（本文已同步公布于：http://www.52im.net/thread-39...）

2、蘑菇街的直播架构概览

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

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

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

除去推拉流，该云平台也提供了云通信（IM即时通讯能力）和直播录制等云服务，组成了一套直播所须要的根底服务。

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

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

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

1）主播端和用户端别离与云直播的互动直播后盾建设长连贯；
2）主播端通过UDT公有协定向互动直播后盾推送音视频流；
3）互动直播后盾接管到音视频流后做转发，间接下发给与之建设连贯的用户端。

这种推拉流形式有几点劣势：

1）只须要在客户端中集成SDK：通过手机就能够开播，对于主播开播的要求比拟低，适宜直播业务疾速铺开；
2）互动直播后盾仅做转发：没有转码，上传CDN等额定操作，整体提早比拟低；
3）主播端和用户端都能够作为音视频上传的发起方：适宜连麦、视频会话等场景。

4、推拉流架构2：旁路推流

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

那么问题来了：如果我想要在H5、小程序等其余场景下观看直播，没有方法接入SDK，须要怎么解决呢？

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

旁路推流指的是：通过协定转换将音视频流对接到规范的直播 CDN 零碎上。

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

目前蘑菇街直播旁路开启的协定类型有HLS、FLV、RTMP三种，曾经能够笼罩到所有的播放场景，在后续章节会对这几种协定做具体的介绍。

5、推拉流架构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和缓冲，延时绝对较长。
6、高可用架构计划：云互备
业务倒退到肯定阶段后，咱们对于业务的稳定性也会有更高的要求，比方当云服务商服务呈现问题时，咱们没有备用计划就会呈现业务始终期待服务商修复进度的问题。

因而云互备计划就呈现了：云互备指的是直播业务同时对接多家云服务商，当一家云服务商呈现问题时，疾速切换到其余服务商的服务节点，保障业务不受影响。

直播业务中常常遇到服务商的CDN节点上行速度较慢，或者是CDN节点存储的直播流有问题，此类问题有地域性，很难排查，因而目前做的互备云计划，次要是备份CDN节点。

目前蘑菇街整体的推流流程曾经依赖了原有云平台的服务，因而咱们通过在云直播后盾直达推一路流到备份云平台上，备份云在接管到了直播流后会对流转码并且上传到备份云本身的CDN零碎当中。一旦主平台CDN节点呈现问题，咱们能够将下发的拉流地址替换成备份云拉流地址，这样就能够保障业务疾速修复并且观众无感知。

7、视频直播数据流解封装原理

介绍流协定之前，先要介绍咱们从云端拿到一份数据，要通过几个步骤能力解析出最终须要的音视频数据。

如上图所示，总体来说，从获取到数据到最终将音视频播放进去要经验四个步骤。

第一步：解协定。

协定封装的时候通常会携带一些头部形容信息或者信令数据，这一部分数据对咱们音视频播放没有作用，因而咱们须要从中提取出具体的音视频封装格局数据，咱们在直播中罕用的协定有HTTP和RTMP两种。

第二步：解封装。

获取到封装格局数据当前须要进行解封装操作，从中别离提取音频压缩流数据和视频压缩流数据，封装格局数据咱们平时常常见到的如MP4、AVI，在直播中咱们接触比拟多的封装格局有TS、FLV。

第三步：解码音视频。

到这里咱们曾经获取了音视频的压缩编码数据。

咱们日常常常听到的视频压缩编码数据有H.26X系列和MPEG系列等，音频编码格局有咱们相熟的MP3、ACC等。

之所以咱们能见到如此多的编码格局，是因为各种组织都提出了本人的编码标准，并且会相继推出一些新的议案，然而因为推广和免费问题，目前支流的编码格局也并不多。

获取压缩数据当前接下来须要将音视频压缩数据解码，获取非压缩的色彩数据和非压缩的音频抽样数据。色彩数据有咱们平时熟知的RGB，不过在视频的中罕用的色彩数据格式是YUV，指的是通过亮堂度、色调、饱和度确定一个像素点的色值。音频抽样数据通常应用的有PCM。

第四步：音视频同步播放。

最初咱们须要比对音视频的时间轴，将音视频解码后的数据交给显卡声卡同步播放。

PS：如果你对上述流程还不太了解，倡议进一步浏览以下系列文章：

《挪动端实时音视频直播技术详解（一）：开篇》
《挪动端实时音视频直播技术详解（二）：采集》
《挪动端实时音视频直播技术详解（三）：解决》
《挪动端实时音视频直播技术详解（四）：编码和封装》
《挪动端实时音视频直播技术详解（五）：推流和传输》
《挪动端实时音视频直播技术详解（六）：提早优化》

另外：无关音视频编解码技术的文章，也能够具体学习以下文章：

视频编解码之：《实践概述》、《数字视频介绍》、《编码根底》、《预测技术介绍》
《意识支流视频编码技术H.264》
《如何开始音频编解码技术的学习》
《音频根底及编码原理入门》
《常见的实时语音通信编码标准》
《实时视频编码H.264的特点与劣势》、《视频编码H.264、VP8的前世今生》
《详解音频编解码的原理、演进和利用选型》、《零根底，史上最艰深视频编码技术入门》

8、视频直播传输协定1：HLS

首先介绍一下HLS协定。HLS是HTTP Live Streaming的简写，是由苹果公司提出的流媒体网络传输协定。

从名字能够显著看出：这一套协定是基于HTTP协定传输的。

说到HLS协定：首先须要理解这一种协定是以视频切片的模式分段播放的，协定中应用的切片视频格式是TS，也就是咱们前文提到的封装格局。

在咱们获取TS文件之前：协定首先要求申请一个M3U8格局的文件，M3U8是一个形容索引文件，它以肯定的格局形容了TS地址的指向，咱们依据M3U8文件中形容的内容，就能够获取每一段TS文件的CDN地址，通过加载TS地址分段播放就能够组合出一整段残缺的视频。

应用HLS协定播放视频时：首先会申请一个M3U8文件，如果是点播只须要在初始化时获取一次就能够拿到所有的TS切片指向，但如果是直播的话就须要不停地轮询M3U8文件，获取新的TS切片。

获取到M3U8后：咱们能够看一下外面的内容。首先结尾是一些通用形容信息，比方第一个分片序列号、片段最大时长和总时长等，接下来就是具体TS对应的地址列表。如果是直播，那么每次申请M3U8文件外面的TS列表都会随着最新的直播切片更新，从而达到直播流播放的成果。

HLS这种切片播放的格局在点播播放时是比拟实用的，一些大的视频网站也都有用这一种协定作为播放计划。

首先：切片播放的个性特地实用于点播播放中视频清晰度、多语种的热切换。比方咱们播放一个视频，起初抉择的是标清视频播放，当咱们看了一半感觉不够清晰，须要换成超清的，这时候只须要将标清的M3U8文件替换成超清的M3U8文件，当咱们播放到下一个TS节点时，视频就会主动替换成超清的TS文件，不须要对视频做从新初始化。

其次：切片播放的模式也能够比拟容易地在视频中插入广告等内容。

在直播场景下，HLS也是一个比拟罕用的协定，他最大的劣势是苹果大佬的加持，对这一套协定推广的比拟好，特地是挪动端。将M3U8文件地址喂给video就能够间接播放，PC端用MSE解码后大部分浏览器也都可能反对。然而因为其分片加载的个性，直播的提早绝对较长。比方咱们一个M3U8有5个TS文件，每个TS文件播放时长是2秒，那么一个M3U8文件的播放时长就是10秒，也就是说这个M3U8播放的直播进度至多是10秒之前的，这对于直播场景来说是一个比拟大的弊病。

HLS中用到的TS封装格局，视频编码格局是通常是H.264或MPEG-4，音频编码格局为AAC或MP3。

一个ts由多个定长的packtet组成，通常是188个字节，每个packtet有head和payload组成，head中蕴含一些标识符、错误信息、包地位等根底信息。payload能够简略了解为音视频信息，但实际上上层还有还有两层封装，将封装解码后能够获取到音视频流的编码数据。

9、视频直播传输协定2：HTTP-FLV

HTTP-FLV协定，从名字上就能够显著看出是通过HTTP协定来传输FLV封装格局的一种协定。

FLV是Flash Video的简写，是一种文件体积小，适宜在网络上传输的封包形式。FlV的视频编码格局通常是H.264，音频编码是ACC或MP3。

HTTP-FLV在直播中是通过走HTTP长连贯的形式，通过分块传输向申请端传递FLV封包数据。

在直播中，咱们通过HTTP-FLV协定的拉流地址能够拉取到一段chunked数据。

关上文件后能够读取到16进制的文件流，通过和FLV包构造比照，能够发现这些数据就是咱们须要的FLV数据。

首先结尾是头部信息：464C56转换ASCII码后是FLV三个字符，01指的是版本号，05转换为2进制后第6位和第8位别离代表是否存在音频和视频，09代表头部长度占了几个字节。

后续就是正式的音视频数据：是通过一个个的FLV TAG进行封装，每一个TAG也有头部信息，标注这个TAG是音频信息、视频信息还是脚本信息。咱们通过解析TAG就能够别离提取音视频的压缩编码信息。

FLV这一种格局在video中并不是原生反对的，咱们要播放这一种格局的封包格局须要通过MSE对影视片的压缩编码信息进行解码，因而须要浏览器可能反对MSE这一API。因为HTTP-FLV的传输是通过长连贯传输文件流的模式，须要浏览器反对Stream IO或者fetch，对于浏览器的兼容性要求会比拟高。

FLV在提早问题上相比切片播放的HLS会好很多，目前看来FLV的提早次要是受编码时设置的GOP长度的影响。

这边简略介绍一下GOP：在H.264视频编码的过程中，会生成三种帧类型：I帧、B帧和P帧。I帧就是咱们通常说的关键帧，关键帧内包含了残缺的帧内信息，能够间接作为其余帧的参考帧。B帧和P帧为了将数据压缩得更小，须要由其余帧推断出帧内的信息。因而两个I帧之间的时长也能够被视作最小的视频播放片段时长。从视频推送的稳定性思考，咱们也要求主播将关键帧距离设置为定长，通常是1-3秒，因而除去其余因素，咱们的直播在播放时也会产生1-3秒的延时。

10、视频直播传输协定3：RTMP

RTMP协定理论能够与HTTP-FLV协定归做同一种类型。

他们的封包格局都是FlV，但HTTP-FLV应用的传输协定是HTTP，RTMP拉流应用RTMP作为传输协定。

RTMP是Adobe公司基于TCP做的一套实时音讯传输协定，常常与Flash播放器匹配应用。

RTMP协定的优缺点非常明显。

RTMP协定的长处次要是：

1）首先和HTTP-FLV一样，提早比拟低；
2）其次它的稳定性十分好，适宜长时间播放（因为播放时借用了Flash player弱小的性能，即便开多路流同时播放也能保障页面不呈现卡顿，很适宜监控等场景）。

然而Flash player目前在web端属于墙倒众人推的地步，支流浏览器慢慢都示意不再反对Flash player插件，在MAC上应用可能立即将电脑变成烧烤用的铁板，资源耗费很大。在挪动端H5根本属于齐全不反对的状态，兼容性是它最大的问题。

11、视频直播传输协定4：MPEG-DASH

MPEG-DASH这一协定属于新兴势力，和HLS一样，都是通过切片视频的形式进行播放。

他产生的背景是晚期各大公司都本人搞本人的一套协定。比方苹果搞了HLS、微软搞了 MSS、Adobe还搞了HDS，这样使用者须要在多套协定封装的兼容问题上痛苦不堪。

于是大佬们凑到一起，将之前各个公司的流媒体协定计划做了一个整合，搞了一个新的协定。

因为同为切片视频播放的协定，DASH优劣势和HLS相似，能够反对切片之间多视频码率、多音轨的切换，比拟适宜点播业务，在直播中还是会有延时较长的问题。

12、如何抉择最优的视频直播传输协定

视频直播协定抉择十分要害的两点，在前文都曾经有提到了，即低延时和更优的兼容性。

首先从延时角度思考：不思考云端转码以及上下行的耗费，HLS和MPEG-DASH通过将切片时长减短，延时在10秒左右；RTMP和FLV实践上延时相当，在2-3秒。因而在延时方面HLS ≈ DASH > RTMP ≈ FLV。

从兼容性角度思考：HLS > FLV > RTMP，DASH因为一些我的项目历史起因，并且定位和HLS反复了，临时没有对其兼容性做一个详尽的测试，被推出了抉择的思考范畴。

综上所述：咱们能够通过动静判断环境的形式，抉择以后环境下可用的最低提早的协定。大抵的策略就是优先应用HTTP-FLV，应用HLS作为兜底，在一些非凡需要场景下通过手动配置的形式切换为RTMP。

对于HLS和HTTP-FLV：咱们能够间接应用 hls.js 和 flv.js 做做解码播放，这两个库外部都是通过MSE做的解码。首先依据视频封装格局提取出对应的音视频chunk数据，在MediaSource中别离对音频和视频创立SourceBuffer，将音视频的编码数据喂给SourceBuffer后SourceBuffer外部会解决完剩下的解码和音视频对齐工作，最初MediaSource将Video标签中的src替换成MediaSource 对象进行播放。

在判断播放环境时咱们能够参照flv.js外部的判断形式，通过调用MSE判断办法和模仿申请的形式判断MSE和StreamIO是否可用：

// 判断MediaSource是否被浏览器反对，H.264视频编码和Acc音频编码是否可能被反对解码
window.MediaSource && window.MediaSource.isTypeSupported('video/mp4; codecs="avc1.42E01E,mp4a.40.2"');

如果FLV播放不被反对的状况下：须要降级到HLS，这时候须要判断浏览器环境是否在挪动端，挪动端通常不须要 hls.js 通过MSE解码的形式进行播放，间接将M3U8的地址交给video的src即可。如果是PC端则判断MSE是否可用，如果可用就应用hls.js解码播放。

这些判读能够在本人的逻辑里提前判断后去拉取对应解码库的CDN，而不是期待三方库加载实现后应用三方库外部的办法判断，这样在抉择解码库时就能够不把所有的库都拉下来，进步加载速度。

13、同层播放如何解决

电商直播须要观众操作和互动的局部比起传统的直播更加多，因而产品设计的时候很多的功能模块会悬浮在直播视频上方缩小占用的空间。这个时候就会遇到一个挪动端播放器的老大难问题——同层播放。

同层播放问题：是指在挪动端H5页面中，一些浏览器内核为了晋升用户体验，将video标签被劫持替换为native播放器，导致其余元素无奈笼罩于播放器之上。

比方咱们想要在直播间播放器上方减少聊天窗口，将聊天窗口通过相对定位晋升z-index置于播放器上方，在PC中测试齐全失常。但在挪动端的一些浏览器中，video被替换成了native播放器，native的元素层级高于咱们的一般元素，导致聊天窗口理论显示的时候在播放器下方。

要解决这个问题，首先要分多个场景。

首先在iOS零碎中：失常状况下video标签会主动被全屏播放，但iOS10以上曾经原生提供了video的同层属性，咱们在video标签上减少playsinline/webkit-playsinline能够解决iOS零碎中大部分浏览器的同层问题，剩下的低零碎版本的浏览器以及一些APP内的webview容器（譬如微博），用下面提的属性并不论用，调用三方库iphone-inline-video能够解决大部分残余问题。

在Android端：大部分腾讯系的APP内置的webview容器用的都是X5内核，X5内核会将video替换成原生定制的播放器已便于加强一些性能。X5也提供了一套同层的计划（该计划官网文档链接已无奈关上），给video标签写入X5同层属性也能够在X5内核中实现内联播放。不过X5的同层属性在各个X5版本中体现都不太一样（比方低版本X5中须要应用X5全屏播放模式能力保障MSE播放的视频同层失效），须要留神辨别版本。

在蘑菇街App中，目前集成的X5内核版本比拟老，在应用MSE的状况下会导致X5同层参数不失效。但如果集成新版本的X5内核，须要对大量的线上页面做回归测试，老本比拟高，因而提供了一套折中的解决方案。通过在页面URL中减少一个开关参数，容器读取到参数当前会将X5内核降级为零碎原生的浏览器内核，这样能够在解决浏览器视频同层问题的同时也将内核变动的影响范畴管制在单个页面当中。

14、相干文章

[1] 挪动端实时音视频直播技术详解（四）：编码和封装
[2] 挪动端实时音视频直播技术详解（五）：推流和传输
[3] 实现提早低于500毫秒的1080P实时音视频直播的实际分享
[4] 浅谈开发实时视频直播平台的技术要点
[5] 直播零碎聊天技术(七)：直播间海量聊天音讯的架构设计难点实际
[6] 从0到1：万人在线的实时音视频直播技术实际分享(视频+PPT) [附件下载]
[7] 实时视频编码H.264的特点与劣势
[8] 视频编码H.264、VP8的前世今生
[9] 零根底，史上最艰深视频编码技术入门
[10] 视频编解码之编码根底
[11] 零根底入门：实时音视频技术基础知识全面盘点
[12] 实时音视频面视必备：疾速把握11个视频技术相干的根底概念
[13] 写给小白的实时音视频技术入门提纲

（本文已同步公布于：http://www.52im.net/thread-39...）