autor：贺志兵
一、直播科普
1、直播是什么
在之前一篇文章详细解答过关于视频的结构，这里就直接上个思维导图。
理解视频的结构有助于我们更好的去理解直播。从本质上讲，直播就是一帧帧的数据加上时序标签流式传输。 这里有个悖论：一个容器封装好后的视频是“结构化”的，即不可变的，那直播又是怎么产生的呢？或者说，怎么去打破这个已经产生的“结果”，从而还往里面加上时序标签流式传输的呢？ 很简单，那就是**“边生产边传输边播放”。** 至于如何达到这种效果，我们继续往下看。
2、视频编码压缩
前面讲直播，怎么又突然讲到视频了呢？ 简而言之，视频和直播息息相关。当然，这也是既定的事实，所以也不多说。 那这里讲的编码压缩又是什么呢？ 采集设备采集一帧图像会生成无损的**.bmp文件格式的图片文件，一个6M通过有损压缩得到200kb的JPEG文件，压缩比就是1/30。 但是视频不需要单独传输一张张压缩图，只需要记录每帧之间的差别即可。于是，根据I帧（200K原始图像）生成差异文件P帧，通过I帧和P帧再生成B帧。 这，就是H.264编码。
一个公式： GOP = I(帧内编码帧) + B（双向预测帧） + P（前向预测帧） 其中I帧也叫关键帧，是一副完整的画面，而P帧则是记录I帧的变化（H.264中通过补偿算法根据I帧得到的差异文件），B帧类似。 再简单点说，如果没有I帧，P帧和B帧也无法解码。这也很好理解，没有原始对比文件，只有差异文件是无法渲染画面的。 GOP结构一般两个数字，如M=1，N=2。M指定I帧和P帧之间的距离，N指定两个I帧之间的距离，其他都是B帧填充。如M=1，N=2这里的例子是IDR PB I排序。 有些地方会讲IDR帧，其实就是GOP的第一个I帧，这个帧很重要，因为关于首开优化基本上都在去尽可能减小IDR帧的大小。
总结，编码后的视频（video） = 一组 GOP 画面 = 一组 I帧 +B帧 +P帧。
如果用物理学上的概念来比喻，Video就是“物体”， GOP好比“分子”，I/P/B帧的图像就是“原子”。 而直播，就是利用video的“原子”传输。
3、视频直播的准确定义
到这里，我们终于可以来尝试来给直播表述较为准确的一个定义。
直播就是将每帧数据（Video/Audio/Data Frame），打上时序标签后进行流式传输的过程。发送端源源不断的采集音视频数据，经过编码、封包、推流，再经过中继分发网络进行扩散传播。播放端则源源不断的下载数据并按时序进行解码播放。 这样就完成了“边生产、边传输、边播放”的直播过程了。 简而言之，视频直播技术，就是将视频内容的最小颗粒（I/P/B帧）,基于时序标签，以流式传输的一种技术。
题外话：GOP越长，所包含的B帧和P帧越多，响应的压缩比也会更高。 GOP越短，I帧比例增高，压缩比增加，同码率下视频质量会下降。
二、常见直播技术梳理
1、直播业务逻辑
直播也分为两种，一种就是直播服务，一种叫互动直播。打个比方，如果 直播 服务是个信号发射塔，那 互动直播 就是个带舞台的剧院。
今天我们这里主要讲述的主要是前一种，也就是“信号塔”式直播。相比较“舞台式”互动直播，“信号塔”式直播只要知道发射塔的信号频率(即频道号或链接)就能收看它发送的节目，但是并不能很好的去实时交互动。而对于互动直播来说，“舞台上”的演员可以很多个，观众也可能被邀请到舞台上面对面交流，所以互动直播的延时会比直播更低，甚至达到了毫秒级（100ms）。 当然，互动直播经过旁路转推也可以经过“发射塔”播出去，这就是“旁路转推”功能。
常见直播业务逻辑如下：
2、直播技术栈
上图是一个如今主流的直播泳道，非常直白的表述了从主播端采集视频到观看端播放直播的数据流向，下面我们根据其中主要的几大模块一一详解。
数据采集→数据预处理→数据编码→数据传输(流媒体服务器)→解码数据→直播播放
1、数据采集（主播端）
采集设备：手机、电脑、摄像机
2、数据预处理
涉及功能：美颜、滤镜 涉及技术：SDK内置算法或第三方特效
3、数据编码
编码器主要流程：
编码方式：CBR（静态码率）和VBR（动态码率） 视频编码格式：H.265、H.264、MPEG-4等 音频编码格式： Opus、G711、AAC、Speex、3A等 视频封装容器：封装容器有TS、MKV、AVI、MP4等 音频封装容器：MP3、OGG、AAC等
4、数据传输
传输协议：
- 推流：RTSP、RTMP、QUIC
- 拉流：RTMP、HTTP-FLV、HLS 控制信令：SIP、SDP、SNMP
5、解码数据
涉及技术：编码器自带解码器
6、数据播放（播放端）
播放渠道：移动端（手机、平板等）、客户端（PC等）、网页端（各终端）
三、直播协议的区别以及应用场景
在第二部分，我们已经详细介绍了直播的流程，其中还简要的介绍的直播过程中拉流和推流所使用到的协议，下面我们来一一详解。
1、推流
推流协议：RTMP、RTSP和QUIC 备注：RTSP、RTMP、QUIC协议都在应用层。
-
RTSP是流媒体协议，主要应用于安防监控，目前绝大多数的摄像头默认支持RTSP推流。一般传输的是 ts、mp4 格式的流。RTSP在体系结构上位于RTP和RTCP之上，它使用TCP或UDP完成数据传输。但是实现复杂，各家CDN支持度不高，一般需要将直播流转码成CDN支持更好的RTMP。
-
RTMP也是流媒体协议，属于Adobe，基于TCP长链接一般传输的是 flv，f4v 格式流。优点是延时低，国内CDN厂商都兼容。这也是主要的推流方式。但是在浏览器中只能使用 Flash 实现播放器。但作为拉流协议时无法支持移动端 Web 播放（手机无法安装flash）是它的硬伤。
-
QUIC全称 quick udp internet connection，即“快速 UDP 互联网连接”。是谷歌公司制定的一种基于 UDP 协议的低时延互联网传输协议。使用QUIC推流，针对弱网用户也能够有很好的用户体验。
2、拉流
有直播推流到流媒体服务器，那肯定也会有相应的拉流方式。相比较于推流，目前主流的拉流协议有三种：RTMP、HLS、HTTP-FLV。
RTMP拉流：
- 基于TCP长连接，默认使用端口1935，延时在1-3s左右
- Web端依赖flash，H5需要安装插件
- 手机浏览器由于flash原因，不能使用RTMP拉流
HLS拉流：
- 基于HTTP短连接，默认80端口，由苹果公司创造。
- 对H5支持较好，但是延时一般在10S以上
- 可以使用 HTTPS 做加密通道
HTTP-FLV：
- 基于HTTP长链接，默认80端口，延时在1-3s左右
- 使用B站开源flv.js可以很好的支持H5，否则也依赖flash
- 很好的支持移动端（Android，IOS）
- 可以使用 HTTPS 做加密通道
在支持浏览器的协议里，延迟排序是： HTTP-FLV >= RTMP < HLS 而性能排序恰好相反： RTMP > HTTP-FLV > HLS 就目前主流直播平台（斗鱼、虎牙、熊猫等）清一色的都是使用HTTP-FLV（主）+RTMP（备）协议。而手机web端（小程序）则大多数使用的HLS协议。
3、开源推拉流软件推荐
1、推流工具
Windows端：
- OBS（Open Broadcaster Software）
- Adobe Flash Media Encoder（不再更新）
- XSplit推流器
- ffmpeg命令行工具
移动端（IOS和Andriod）：
- 七牛开源SDK
备注：不支持H5推流
2、播放工具
Web端：
- 七牛云Web sdk
- 超酷开源播放软件
Windows：
- 七牛windows开源播放器
- VLC播放器
移动端（IOS和Andriod）：
- 七牛开源移动播放器
四、使用七牛云从0到1打造直播平台
1、简要流程
通过七牛开发者平台快速创建直播空间、直播流及获取推流播放地址等操作，一站式完成直播业务的基本推流及播放。
备注：申请七牛云直播需审核以及一个双备案（ICP及公安部）的域名。
2、产品框架
主要分为四部分：
-
业务服务器 负责协调直播类应用的业务逻辑，包括但不限于：
-
创建直播房间
-
返回直播房间播放地址列表
-
关闭直播房间
-
LiveNet 实时流网络 负责流媒体的分发、直播流的创建、查询等相关操作
-
采集端
-
负责采集和推送流媒体
-
播放端
-
负责拉取并播放流媒体
七牛云官网文档：