CDN+P2P在大规模直播&实时直播的技术实践

LiveVideoStack 2017年7月27日

大家好,我是爱奇艺的周志伟,今天会跟大家分享爱奇艺的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也是一个非常优秀的开源项目,有很多东西值得去吸收和引用的。

还可输入800
全部评论
作者介绍

周志伟

爱奇艺

技术经理

文章

粉丝

视频

相关文章
阅读排行
  • 2周
  • 4周
  • 16周
热门视频

WebRTC视频数据流程分析

许建林/《WebRTC Native开发实战》书籍作者