【学习】初探移动视频直播解决方案

写作背景

写下这篇博客是因为工作中正好遇到了相关的内容，需要学习相关方面的知识，所以自己在这里做一下知识的整理。

直播行业背景

1 直播行业有多火爆？

2016年海内外移动互联网直播行业报告 - 七牛云
2016-2017 直播行业分析报告
企鹅智酷：2017中国网络视频直播行业趋势报告
个推大数据：2018第一风口——直播答题APP 行业报告

2 在监管新规下，直播进入调整期：

国家网信办发布《互联网直播服务管理规定》

3 众多答题直播的出现

这是一篇技术文章。所以不再继续衍生下去，感兴趣的朋友可以搜索相关资料学习。

移动视频直播解决方案

1 通用直播架构

首先是主播方，它是产生视频流的源头，由一系列流程组成：第一，通过一定的设备来采集数据；第二，将采集的这些视频进行一系列的处理，比如水印、美颜和特效滤镜等处理；第三，将处理后的结果视频编码压缩成可观看可传输的视频流；第四，分发推流，即将压缩后的视频流通过网络通道传输出去。

其次是播放端，播放端功能有两个层面，第一个层面是关键性的需求；另一层面是业务层面的。先看第一个层面，它涉及到一些非常关键的指标，比如秒开，在很多场景当中都有这样的要求，然后是对于一些重要内容的版权保护。为了达到更好的效果，我们还需要配合服务端做智能解析，这在某些场景下也是关键性需求。再来看第二个层面也即业务层面的功能，对于一个社交直播产品来说，在播放端，观众希望能够实时的看到主播端推过来的视频流，并且和主播以及其他观众产生一定的互动，因此它可能包含一些像点赞、聊天和弹幕这样的功能，以及礼物这样更高级的道具。

我们知道，内容产生方和消费方一般都不是一一对应的。对于一个直播产品来讲，最直观的体现就是一个主播可能会有很多粉丝。因此，我们不能直接让主播端和所有播放端进行点对点通信，这在技术上是做不到或者很有难度。主播方播出的视频到达播放端之前，需要经过一系列的中间环节，也就是我们这里讲的直播服务器端。

直播服务器端提供的最核心功能是收集主播端的视频推流，并将其放大后推送给所有观众端。除了这个核心功能，还有很多运营级别的诉求，比如鉴权认证，视频连线和实时转码，自动鉴黄，多屏合一，以及云端录制存储等功能。另外，对于一个主播端推出的视频流，中间需要经过一些环节才能到达播放端，因此对中间环节的质量进行监控，以及根据这些监控来进行智能调度，也是非常重要的诉求。

2 七牛云的直播技术架构

数据来自七牛云

主要分为四部分：

• 业务服务器
  负责协调直播类应用的业务逻辑，包括但不限于：
  • 创建直播房间
  • 返回直播房间播放地址列表
  • 关闭直播房间
• LiveNet 实时流网络
  负责流媒体的分发、直播流的创建、查询等相关操作
• 采集端
  负责采集和推送流媒体
• 播放端
  负责拉取并播放流媒体
  
  

3 移动直播用到了那些技术？

市面上的移动直播大体有：音视频数据采集，编码，传输(推流/拉流)，解码和渲染，美颜/滤镜/特效处理，封包，分发，水印，弹幕，点赞动画，解码/渲染/播放，IM聊天等功能。

其实音频技术和视频技术它们的大体处理流程都是差不多的。一般都分为五大步： 数据采集，编码，传输，解码和渲染。

• 数据采集。对于音频来说采集到的数据是PCM格式，对于视频数据采集的格式是YUV格式。
• 数据压缩编码。数据采集完成之后，需要对数据进行压缩编码。音视频使用的压缩技术称为有损压缩技术。而像我们平RAR，ZIP工具进行的压缩都是无损压缩。就是说解压后的数据与原始数据一样叫做无损压缩，解压后和原始数据高度接近称为有损压缩，音视频编码属于后者。对于音频来讲，常用的编码格式有speex, AAC, OPUS, G.711等。现在比较常用的是AAC，一是它音质比较好，二是RTMP对AAC支持的比较好。对于视频编码格式有H.264, H.265, VP8, VP9等，目常基本上都是使用H.264。注意，衡量有损压缩好坏的指标就是看同等压缩率的情况下，解压后的数据与原始数据之间差别的大小，差别越小证明压缩的算法越优。当然在实时互动直播中，我们为了实时性就需要牺牲一部分质量或者也有可能为了质量而牺牲一些实时性，这需要仔细的权衡。
• 传输。数据压缩完之后通过网络传输。对于泛娱乐化的直播平台一般都使用RTMP协议进行数据的传输，RTMP是在TCP之上的网络协议。对于实时互动直播则必须使用UDP进行数据传输。 UDP数据的传输速度上比TCP有天然的优势。RTMP是Adobe公司发明一种传输协议，目前所有的CDN网络对RTMP的支持是非常好的，但它的问题就是延迟性比较大。使用RTMP造成延迟主要有两个方面原因，一是RTMP网络协议由于是基于TCP协议的，本身延迟就比UDP大，另一方面是CDN架构造成的。CDN首先从顶级结点接收数据，然后以树状形式分发到端结点，这个过程链条比较长，导致整体的延迟非常大。而且延迟时间不固定，有可能某段时间延迟3､5秒，也有可能过一段时间延迟就达到了30秒这都是有可能的。
  这里主要说一下 RUDP， 我们知道TCP是流式的，可靠传输，而UDP是不可靠传输。它们都是基于IP协议的，而IP协议是不可靠的包传输方式。那么TCP是怎么成为流式可靠传输的呢？这里不可以做详细介绍，但其核心就是发送／应答机制，丢包／超时重传机制，滑窗控制（慢增长，快下降）机制。而RDUP也是利用这几个机制来达到可靠性的要求。
• 解码。就是将对编码数据做反向操作。如音频是AAC编码，则它再解为PCM格式数据。视频是H.264再解为YUV数据。
• 播放和渲染。对于音频直接将PCM数据放入到音频驱动缓冲驱，驱动程序就会将音频播放出来。对于视频一般会通过 opengl利用 GPU进行图像渲染。
• IM聊天。对于直播产品中的聊天与QQ之类聊天软件还有不少区别，尤其娱乐直播，在一场直播中可能有上万人参上，其中一个用户发消息就要分发1万份，10000人同时发，就是1亿的消息量，具有短时大并发的特性。可以在用户接入设计上要考虑多点接口，而在下发时要做限流控制，同时在客户端也要限制用户发消息的频率。

4 流媒体传输

TCP：TCP为点对点的协议，虽然能保证了数据传输的可靠性，但是对服务器资源耗费较大，在数据流大的场合难以保证数据流传输的实时性。

2.UDP：UDP为不可靠传输协议，不需要维护连接状态，也不认为每个数据包都必须到达接受端，因此网络负荷比TCP小，传输速度也要比TCP快；但在网络越拥挤时，越有更多的数据包丢失。

3.RTMP：RTMP一个专门为高效传输视频，音频和数据而设计的协议。它通过建立一个二进制TCP连接或者连接HTTP隧道实现实时的视频和声音传输。

4.FFmpeg：FFmpeg是一套可以用来记录、转换数字音频、视频，并能将其转化为流的开源计算机程序。采用LGPL或GPL许可证。它提供了录制、转换以及流化音视频的完整解决方案

协议差异

RTMP vs HLS

参考链接

音视频直播--技术架构
音视频直播技术漫谈
做一款仿映客的直播App？看我就够了
七牛直播云服务技术详解
移动直播技术秒开优化经验（含PPT）
android音视频点/直播模块开发
Facebook 直播如何撐起瞬間 80 萬人的流量？
iOS 视频直播初窥:高仿<喵播APP>
iOS中集成 ijkplayer 视频直播框架