随着互联网带宽的发展，尤其是移动互联网的浪潮的到来，互联网的内容也越来越视频化、移动化。面对越来越多的用户基数、越来越复杂的网络环境，如何能够在技术工程上保证到视频直播用户的体验，面临了巨大的挑战。总结这些关键经历，对于海量直播的技术要求，在终端SDK、存储、CDN、调度、编解码等层面的技术解析，在高可用、稳定性、负载均衡、过载保护、数据安全等架构、运营层面的全面剖析，代你领略不一样的移动互联网时代的视频直播架构。

本文为UCloud高级架构师叶仲华在2016全球移动技术大会上发表的演讲内容，主要介绍了视频直播重点要关注的内容以及UCloud“直播云”的平台架构，希望对正在开发直播App和想要了解云直播架构的朋友有一些帮助。

本文大纲如下：

直播业务的关注点

直播主要的技术范畴

跨网通信的优化

播放器的软硬编解码

首先，先来看一组数字：

200小时：这是国外Youtube每一分钟上传视频的时长。一分钟，它的用户就会上传长达200个小时的视频。

30亿：是脸书每天观看视频的次数，可以看到视频这块的活跃度。

300人：这是每分钟全球增加的视频用户数。

60%：指的是视频流量占整个互联网流量的60%。

从这些数字上来看，视频是一个非常大的市场。

直播业务的关注点：

第一、首屏的秒开。

大家如果使用过一些直播APP的话，会有很直接的体验。一些直播APP打开之后，可能会出现画面不能动或者是黑屏状态，要过一会儿才播放，然后你就得等。

通常打开一个APP也会有加载的过程，这个从技术上来讲大家可以理解。但是从最终用户的角度来讲，肯定倾向于打开就能播放。所以，实际上这是现在主流直播APP要实现的功能，叫做首屏秒开，基本上所需要的时间也就是一秒。

当然，首屏秒开只是说你怎样在很短时间内把视频数据快速呈现出来，是一个体验上的改进，并不包括从内容生产方传输到直播观看者应用整个业务的延迟。

第二、低卡顿率。

大家看视频的时候卡了不爽，直播卡了就更不爽。因为哪一个瞬间卡住，等会可能就看不到了，所以“卡顿率”也是大家比较关注的。这个与你后端网络的分发，客户端的设计、视频的切片间隔可能都有关系。

第三、低延时。

低延时指的是内容生产方到直播观看者之间的延时，这个延时希望做到尽量低。当你的用户在做送花、聊天等一些视频社交的时候，你的内容方可以很快对这些互动做响应。所以这个时间越短越好，如果要求一些动作在用户看来是同时发生的。那么这个对于延时的要求，可能会更苛刻。

第四、多码率和多格式。

这个主要是一个适配的问题。多码率更多是一个网络环境的适配，比如说你在WIFI环境下，在3G环境下，在4G环境下，你是在热点区域下，还是在一个信号不太好的情况下，这都对码率非常敏感。

实际上，所谓码率就是下载带宽。当带宽不大的时候，既要去保证清晰度还要流畅度，这实际上是有矛盾的。所以，什么时候去给用户更换码率，也是大家需要考虑的问题。

多格式，这个和多终端是相关的。比如说，苹果的一些设备，如果直接通过浏览器去看的话，你看不了Http Flv的视频，而像RTMP的格式，你需要有对应的播放器才能播放。

第五、多终端。

这个基本上就是移动端的iOS，安卓，包括PC端等不同方式。

视频直播业务的五大关注点

直播主要的技术范畴

用户对直播往往有着不同需求，将他们的需求抽象出来，变成我们能够适配的技术和能够提供的产品很重要。所以，我们主要看几个方面：

第一个，与视频相关的协议及编解码的技术。

第二个，跟后台相关的，包括你的调度、社交因素等等。不管你是自己做，还是用云服务商提供的SDK来做，总而言之，你必须有后端逻辑系统。

对于直播，有三种协议会非常普遍。一个就是RTMP，这是Adobe的一个专利协议，目前使用比较普遍，除了有很多的开源软件适配，还有开源库的支持。这些都比较完善。

它会带来功能上的好处，但是纯从建立连接的时间上来讲，因为HTTP本身没有复杂的状态交互，所以HTTP的方式肯定会比RTMP快一些。当然这都是属于百毫秒级别的体验了。最后苹果的HLS使用也很广泛。因为在苹果的平台上，HLS的全称就叫Http Live streaming，可用HTML5直接打开播放，不管通过微信分享链接还是其他方式，无需APP都可以。

直播的三种协议对比

在面对PC端和移动APP端这两个不同场景时，视频推送的过程中要做一些调整。如果说推流端是PC，一般我们认为它的网络环境会好一点。推流上来之后，直播云平台会直接分发给观看的用户。

如果推流端换成移动APP，那么对于推流的清晰度要求会下调一些。因为移动端来推的话很费流量，而对于观看的用户来讲，用这么高的清晰度传输也浪费。带宽不大的话肯定会卡顿。为了解决这些问题，必须在实时转码后再进行分发。

直播协议的典型场景

此外在后台系统中，可能要需要一些截图，鉴黄，直播转存的功能。截图主要是获取主播当时的状态，你可能要将其更新到封面图片上。另外在实时截图中，鉴黄也是大家需要考虑的重点。

很多公司还在依靠人工来鉴黄，而一些直播云服务商已经开始通过机器学习来做图片识别了。通过技术的运用，可以大幅减轻人工鉴黄的压力。

直播转存是说主播直播完，可能他（她）的粉丝希望回看。这时候需要提前录制，获得一个可点播的视频文件。

直播相关服务

现在监管部门要求直播类的APP必须把它的内容做一个15天的存储。主要是因为之前有一些直播网站出现“造娃”等不良事件，所以在监管上会有这样的考虑。

这些东西最终都要存下来，那就对直播存储的安全和稳定提出了要求。所以在直播后台要有相应的分布式存储集群去处理这样的数据。

直播云平台架构

跨网通信的优化

在直播中，拉流端跟推流端实际上是对称的。拿着电信手机的用户在路上直播了一个视频。而观众可能是移动跟联通的用户。我们都知道，现在国内的网络基本上都有一个跨网通信的问题，所以你让移动或者联通的用户直接去看电信用户的直播效果会比较差。因为这都是跨网流量，延迟，卡顿会比较严重。

所以我们云服务商必须去建三通节点。在北京、上海、广州、成都、武汉、沈阳、南京、西安多个城市建立数据中心并连入不同的运营商，当跨运营商的场景出现时，我们会把推流送到三通节点做一个转发，然后让距离用户最近的运营商传输。这就明显提高了用户体验。

直播网络与调度

播放器的软硬编解码也是一个需要关注的问题。硬件编解码的时候，iOS还好，但是安卓就很难办。型号太多，硬件也是参次不齐。所以有的时候要用硬件，有的时候要用软件，当中有大量的适配过程。

区别硬件和软件很简单，主要就是看吃不吃CPU，耗不耗电。你要做多终端适配的话，可以在SDK里加一些动态调整的配置文件。这个配置文件会根据我们在后端做的终端适配来实时更新，一旦手机装上APP，就可以知道手机的版本信息。然后再匹配对应的软解、硬解。包括你后期的维护，适配的更新，都会直观的反映到你前端的APP上去。