摘要：本次分享将介绍爱奇艺多类型的直播业务现状，以及直播整体技术架构和客户端直播网络模块Livenet的实现。回顾直播技术顺应业务多样化的演进过程，包括从偏P2P架构发展到结合CDN&P2P混合架构，为多端适配而实现的多协议支持和切换等演变，直播P2P和直播推流SDK的技术实现等。

演讲 / 周志伟

整理 / LiveVideoStack

大家好，我是爱奇艺的周志伟，今天会跟大家分享爱奇艺的HCDN直播，可能大家对爱奇艺比较了解，但是HCDN可能不是太清楚。HCDN在我们内部是一个部门的名称，也是一种技术方式，它是通过庞大的CDN网络和P2P网络为公司所有的产品提供视频服务，主要包括点播和直播两大部分，今天主要跟大家分享直播这一部分。我的分享大概由四大部分组成，首先是直播背景，接着会介绍大规模直播，也就是我们现在主要的直播方式，以及实时直播，最后做一些展望。

直播背景

1.直播类型

首先说一下我们的直播类型，爱奇艺主要是以娱乐为主，因为创始人、CEO龚宇在爱奇艺的大会上也表达过，我们要做一家以科技创新为驱动的娱乐公司，所以在类型上主要包括晚会盛宴，像每年的春晚我们都是有直播的以及演唱会；第二个是体育赛事，比如说澳网、法网这种赛事；商业发布，像小米发布会、华为手机发布会等等；电视轮播，主要是在PC上面，有单独的轮播台，会轮番播放一些大片、动画、电影等等，就像电视台一样；颜值跟手机直播就是像奇秀这种，类似大家常用的花椒、映客；游戏直播和电商直播，比如乐活、三星等等，像三星新出的手机做全景的游戏直播，也会推到我们平台上。我们内部主要分为UGC、PGC和PPC，UGC就是像秀场这种用户直播，PGC可能像游戏直播这种相对更专业的，PPC就是类似春晚。

2.直播品质

在直播品质方面，爱奇艺应该是走在整个行业的前列，在5月26号爱奇艺惊叫之夜，我们已经是支持VR直播了，包括6月30号我们在南京也会有4K的VR直播。同时我们也支持265、杜比、多码率等等，我们也使用HCDN协议。

3.终端覆盖

终端上面，我们就是应该是全终端都覆盖的，包括PC端、安卓端、iOS端以及TV端，在Web端Flash跟H5都可以支持，同时我们支持在全球任何地点都能观看。

4.基本直播分类

针对上面介绍的这些直播，我们内部分成两大部分，第一个是实时直播，延迟相对比较小、互动也比较强，就像奇秀直播，还有秀场这一类的；第二种是大规模直播，像春晚、包括一些大型的演唱会，这种直播延迟比较大的；它的规模也很大，并发都是百万以上的级别；码率的要求也会比较高，像4K，1080P，720P都是必须的；相对来说它的专业性肯定是比较强，保证多机位多角度都能看。

大规模直播

1.直播演进过程

下面主要是先给大家分享我们大规模直播。因为爱奇艺一直是做视频方面的，包括直播也沉淀了好多年，这个演进的过程我们大概分为三大阶段，一个就是最开始的MP2P，这样镜像加P2P方式，接着进入我们的HCDN时代，直到现在的HCDN+。最初在收购PPS之前，PPS也是做直播起家的，像PPTV这种也是，它的特点就是只用了几个镜像，没有使用CDN，很少使用CDN，开播就比较慢一点，当然那个时候码率也比较低，卡顿相对比较高一些，不过分享比是非常高的，可以做到99%。

随着整个互联网的发展，用户对视频的要求就会越来越高，他们希望你的开播够快，你的视频更清楚，你的码率要高，而且还要支持回看的拖动，随时能看直播，还能够随时可以往后拉。这个时候我们进出了HCDN时代了，我们把CDN跟P2P相结合来支持，分享比相对MP2P时代有一些降低，但还是可以保证六十到八十。在2016年进入直播元年之后，我们公司的直播进入了HCDN+的时代，支持实事直播，多种协议，一个混合的直播架构，多协议的支持，就是RTMP、FLV这种实事直播，还有跟较大规模的直播相互的融合，也会支持Dolby，4K，还有VR这种直播。

2.大规模直播架构

下面说一下我们现在大规模直播从数据到系统，经过怎样的处理到我们的端上面，这里面主要包括四大部分，有P2P服务群、P2P网络、CDN网络，还有RTMP集群。首先一路流通过卫星信号传上来的时候，比如说像演唱会、春晚这种节目，它会经过我们的实时解码，就是转码，实时解码做什么事？因为传上来的码流是非常高的，大概有几十兆，这时候我们就需要要把它转成4K、1080P、720P这种，同时也会对音频做一些处理，比如说做一些音量自适应，传上来的音频有时候声音会小、有时候会大一点，防止有爆音出现的情况。

完成实时解码的工作，接着数据会进入我们的RTMP网络，如果是大规模直播需要支持大延迟，我们会进入Cutter，Cutter就会对我们实时的数据进行切片处理，切片完之后，它会分成两部分，第一部分是丢到我们整个的CDN网络，另外一部分是丢到整个P2P网络，P2P网络这里边主要有有广播源(BS)，后面是一些镜像，同时跟那个Tracker进行注册一下，这些都是涉及到P2P相关的。然后这个镜像通过TCP这种协议传到端上面去，让客户端可以观看，在端上面之间是通过UDP这种方式分享的，整个CDN网络是通过HTTP这种方式来下载的。中间这边是有一个虚线，它是后面我们对整个的大规模直播架构做一些优化，可以保证实时跟大规模直播之间相互切换，我们整个的直播架构就是这个样子的。

3.直播协议

接下来说一下直播协议，我们支持的协议比较多一点，有RTMP协议，有HTTP-FLV长连接这种方式，包括HTPP-TS长连接，这种都是实时流的方式，还有HLS动态码率和HTTP分片，HTTP分片就是纯CDN下载的方式，P2P也是支持，整个SDK是所有都支持的，我们的协议层目前处于这种结构。说到HLS协议，我们最近也在跟麻省理工学院计算机科学与人工智能实验室合作，他们有一套AR的算法，是基于HLS协议的，它可以去利用AR的技术，预测你的网速，从而给你提供比较流畅的视频服务这个技术的基本思想，就是通过你的网络状况、Buffer、上一次的下载速度，还有一些卡顿，包括网络信息等等，动态的预测你接下来的网络情况，决定你下一块是选择哪个码率来进行播放的。我们把所有的协议做成了一个叫统一流地址协议，用一个协议就把所有的都囊括在里面，后面能做到自由动态的切换，包括实时、非实时这种。

4.HCDN直播协议

下面就给大家说一下HCDN的直播协议，因为我们直播协议整个是基于时间轴的方式，因为你的直播是随着时间往前推移的，所以我们有个时间的概念往前走。这个是当前时间，就是数据到达的时间，会经过我们的Cutter进行切片，这个就是要切一个GOP或者几个GOP的数据块，通过网络传输，剩下的这一部分就是我们端上面要做的，在端上面我们要对用户的播放的进度进行随机的进行打乱和延迟，因为我们要做P2P处理，包括我们对一些优质的节点做一些处理，因为你这个点比较好，能给更多的用户提供分享，所以我尽量把你优质的节点让你的请求能够靠前一点。

我们把它用户的播放进度打散，希望他们建立这种层级的关系——你下层往上层请求，上层往顶层请求，这样把我们整个的P2P网络就给建立起来，其实做这个延时就是为了整个P2P做准备的。这里面就可以看出来我们整个的大规模直播的延时所产生的原因，大概有这几块，一个是切片网络传输肯定是需要的，还有这个人为策略产生的延时。当然我们也会有两个时间点来控制，因为实时的数据，你不能太靠后，也不能太靠前，要控制你的最大时间和最小时间。

5.CDN和P2P互补

整个HCDN是以CDN和P2P相互补的，当你刚开始播放的时候，你会通过CDN把数据下载下来，然后播放之后，我会把整个P2P网络起动起来，根据你在播放的过程中，Buffer不断的变化进行调整，如果Buffer变小了，这时候会起动CDN来补这块，整个思想基本上就是CDN和P2P相互的交错进行下载。在端上面我们整个P2P系统里边的，包括一些节点管理、P2P下载、块管理、还有节点判断、包括跟Stun服务器就不多说了。P2P主要看你的节点能否互相连通，从我们获得的大数据看，基本上公网节点、端口受限跟IP受限，还有对称的节点，比例大概是2:5:3：30%是对称性，30%的对称性节点中还有30%也是可以打通的，也就是说整个80%以上节点之间是可以互通的，所以对整个P2P网络是有利的。然后我们这里面P2P系统防止脏数据的传输，我们会做一些校验，包括CDN下载的时候也会下载一些校验数据。

6.协议切换

协议切换主要是为了适应产品需求，原先在做一个大规模直播的时候，他会用竞品比较我们的产品，希望我们可以把延时做的更小一点，其实要满足把延时做的更小一点，采用实时直播就可以了，不需要走我们这种大延时的P2P直播，后面我们对整个协议进行优化——统一流地址协议，根据你的业务需求，根据你的并发量，根据你整个的资源情况，在实时跟大延时直播之间做一些动态的切换，比如说当你人数不多，我资源也比较好的情况下，让它都走实时直播，当然如果到达一个极限点阀值的时候，我就让它进入我们的大延时P2P直播。做这种切换是为了播放延时和带宽资源进行平衡，找到一个平衡点。

7.服务质量

整个服务质量这部分，像并发：羊年基本上有六百万，包括去年的春晚直播应该都有四五百万；分享比都是70%以上，当同时在线人数只有几千人时，分享比也可以做到60%以上；卡顿比低于10%，开播速度90分位以上都可以做到秒开。大规模直播我就说这么多了。

实时直播

1.实时直播架构

接下来介绍下我们整个实时直播，实时直播这块，主播端首先认证、推流、经RTMP网络、经过Play服务器，让用户去调度、访问播放服务器，回源到Push服务器上去把数据拉下来，整个的做实时直播基本上都是这个样子的。然后我们有一个回源中心，这里边就是记录一些流名称，还有推流服务器列表的，包括还记录整个网络拓扑和这些运营状态。我们也对整个回源做过一些优化，因为之前做回源是用配置文件这种方式来回源，然后发现这种方式流名称跟机器是绑定在一起的，比较麻烦，更新也是不太好。

后面我们对这个回源系统做了优化，叫快递式回源：推流的时候，会把流名称跟推流服务器记录到回源中心里面去，当你通过Play播放器来查回源路径的时候，我们通过这个流名称来找出这个Push服务器地址，同时根据整个的网络拓扑来计算一条最优的回源路线，把这个回源路线丢给Play服务器，Play播放服务器会拿着像快递标签一样，一级一级往上请求，上一级的服务器就会把自己的去掉，拿剩下的标签继续请求，直到找到Push服务器，整个的实时架构就是这样。

2.实时直播推流&播放

我们的实时直播，刚才也有说一部分，包括推流部分支持RTMP，H264，AAC，还有Nellymoster那种音频，支持UDP，线上主要还是RTMP这种推流，UDP可能后面做连麦，还有HTTP-TS是为后面265还有支持Dolby流做准备的，播放就是基于RTMP这种播放协议，还有HTTP-FLV这种播放协议，还包括HTTP-TS长连接这种方式，推流跟播放协议主要是这几个，具体的那个码率刚才讲过了，我也不多说了。

3.实时直播几个关键点

我在这里简单介绍实时直播的几个关键点——实时直播的关键点可能不只这几个，主要有秒开、延时、卡顿。秒开，基本上缓存GOP这种大家都这样做的，因为实时直播，你必须要等到关键帧才能开播。预调度，我们现在也在做，包括在我们自己的奇秀平台上，当你滑屏幕的时候，刚滑到那个页面预调度已经完成了，当你点击进去的时候，它用调度地址直接Paly就行了，像映客它可能还会更激进一点，猜测就是直接去加载了，我曾经抓取过映客的流量，它在往上翻页下来的时候流量非常大，稍微停顿一下就很大，确实你还没点那个东西，它就已经预下载了一份。还有CDN网络就不多说了，刚才有已经介绍过了。

延时主要是说一下这个推流端就要用UDP推流，包括合理的回源，还有运营商合作这块提升QCI等级，因为我们现在在跟电信的4G和LTE上有合作，它们有一个增值的业务可以提升QCI等级，它保证不管在忙时还是网络拥塞的时候，你的时延都很低，还有稳定性都很高，不过他们现在只是支持移动端，而且只针对广东、福建、浙江局部省份，不过以后可以用在优质主播上面推流还是很有好处。

卡顿方面，像调整播放端的Buffer大小是肯定能降一部分卡顿，但是Buffer调大了，整个你的延时相对也会高，所以这也是分情况的，连麦的时候Buffer要控制了，播放的时候可以稍微的放大一点。包括第三方CDN，之前有跟网宿对接过，包括现在还有跟金山云、百度云也在对这种CDN，当然具体的运营情况需要你根据自己的数据来看，到底有没有降卡顿，要通过自己的监控网络判断。网络自适应推流是肯定需要的，特别是做移动端推流，它的网络特别不稳定。

4.编码推流

这里单独说一下网络自适应推流，就是编码推流这一块，我们在之前做推流的过程中是固定码率，后面我们就做了优化，基本就是你的传输模块反馈网速，编码根据网速去升降码率和帧率，现在安卓4.4，IOS8.0之后都是动态支持码率的，你都可以调接口。如果网速降低，就可以去降码率，如果码率降低不行，可以再降帧率，如果降低帧率依旧不行，就只保留音频，因为你至少保证音频大家能听的流畅一点。在选择降低码率或者帧率的时候就会在画面和在流畅性之间做选择，因为你降码率时候，你画面的清晰度就会比较差，但是你降帧率，画面虽然稍微好点，但是你的流畅性就比较差，看起来卡顿。在机器适配这方面，我们北京有专门的测试团队，经常会租用或者借用很多手机来做机器的适配，特别是安卓端有非常多机型要适配。

5.服务器质量&数据监控

我们的测试团队也很厉害，这个就是他们出的动态码率报告，就是推流情况，从不限速到限速，到限速很严重的时候，最后到放开限速，上面蓝色是帧率，这个红色就是两个视频间隙之间的间隔，当网速降的时候，视频的帧率就会往下降，降到一定程度的时候，红色线可能高一点就没有视频，只是纯音频在跑，再到后面放开限速的时候，整个帧率就会恢复到原来你的额定帧率水平。下面这张图是测试团队对音视频同步情况得出的数据，它们两个重叠在一起，如果重叠比得较好，说明音视频同步比较好，如果相差比较大，说明同步就会有问题。

数据监控，是做实时直播，特别是推流端肯定需要的。之前我们还没有做这个数据的时候，推流时候经常会卡，但是又找不到问题所在，后面我们把主播端的信息，包括你的手机型号、芯片型号、系统，所有的信息都收集上来，包括我们推流过程中也会定时得收集你的渲染帧率、编码帧率、缓存数据和时长、是否丢帧，把它都送到服务器上，我们实时分析服务器的状况。如果主播端出现卡顿，那么所有的播放终端肯定都会出现卡的情况，因为一卡全卡；但是如果主播端没有问题，基本上我们就可以确认是个体的问题，就会去找单个用户自己网络问题去排查；在推流结束之后，我们也可以过后分析，它推流的服务状况是什么样子的。

未来展望

我觉得后面在直播，实时、大并发、P2P这些部分肯定会继续优化和深挖，此外WebRTC也是一个非常优秀的开源项目，有很多东西值得去吸收和引用的。

OK，我今天的分享就到这里，感谢各位听众。

本文分享自微信公众号 - LiveVideoStack（livevideostack）
作者：周志伟