低延时的P2P HLS直播技术实践

本文根据4月21日OSC源创会·武汉站的现场分享为蓝本,重新整理。 以下是演讲内容:

近几年,随着直播、短视频等视频领域对带宽要求的提升以及CDN行业竞争的加剧,很多CDN公司开始往P2P-CDN方向发展。P2P-CDN在降低成本和加速视频业务方面一直是非常优秀的解决方案。

今天就以HLS协议做一个切入点,讲解一下又拍云的P2P-CDN项目——PrismCDN。

直播P2P-CDN通常用于传输FLV协议的视频,又拍云为什么研发支持HLS传输协议的P2P-CDN呢?因为有客户使用了Web播放器,他们不想用FLV协议。为了满足客户的需求,又拍云PrismCDN对P2P-CDN做了HLS适配,让其能够支持HLS协议。

首先看一下HLS和HLS+。虽然HLS已经被广泛使用,但是它平均延时在10秒-30秒,存在延时高的缺点。HLS+技术通过在CDN边缘节点对视频进行切片、转封装,使延迟降低到4秒。目前,又拍云PrismCDN已经全面支持HLS+服务。

P2P-CDN支持HLS实现原理

以PrismCDN为例,目前的做法是P2P-CDN需要做一个P2P下载器的SDK,再通过P2P协议下载数据,同时借助CDN服务器补充数据下载,得到中间结果—FLV数据流。接着在SDK本地做转封装,转成M3U8和TS数据流,最后在local IP地址127.0.0.1上面提供HTTP服务,最终使播放器可以访问HLS数据流。

PrismCDN支持HLS协议的方式与HLS+降低延时的方式相似,HLS+是在CDN边缘节点切片,而PrismCDN则是在客户端本地完成切片以及传输FLV数据流。

P2P HLS的思路和HLS+是一样的,把每个TS片断切的很小,TARGETDURATION制成1秒,做到端对端延时4秒。

高效低价,独特直播架构下的秘密

上面主要讲解了HLS协议本地转封装,相较于P2P-CDN而言,最关键的数据流的传输方式。

首先主播通过RTMP协议将直播流推送到CDN服务器上,CDN服务器会即时推送数据流的二十分之一到光猫、路由器、机顶盒等雾节点。再由雾节点将数据转发到SDK的下载器里。下载器再向CDN服务器补数据,最终拼成FLV流。

PrismCDN数据传输关键点在于依靠光猫、路由器等雾节点的上行能力来提供CDN带宽,从而减少CDN服务器补数据流。将大部分数据通过雾节点转发,最终达到节约成本的目的。

独特直播模型造就低延时

与其他P2P产品相比,又拍云PrismCDN最大的特点是低延时。

P2P直播已有多年历史。早在2004年时,在网络电视直播应用中就已经使用P2P技术,把部分电视台信号放到互联网上面来直播。但是受限于技术,那时的P2P直播延时相当大。

为什么2004年的P2P直播延迟会相当大呢?

这是因为当时的直播格式数据流从最顶层的播放节点和CDN下载数据,再逐层下发到各个下层节点。这种直播树结构将数据一路下灌,造成了非常大的延时。

又拍云PrismCDN不需要构建一棵直播树,只需一层直播模型,就可以达到P2P占量比较高的效果。在一层模型中做到端到端延时在3秒内。在这样的延时下,目前市面上直播的业务,如游戏直播、秀场直播,都可以用PrismCDN来实现。

总结一下,PrismCDN低延时技术主要是在数据传输模型上进行了简化。

90%分享率成就低延时、低成本特性

PrismCDN节点分享比例在90%以上,提升分享比例的关键是在于引进了第三方设备来供应数据。相比传统直播树,PrismCDN不存在“是播放者,才是供应者”的局限。比如有一万个并发播放者的话,传统直播树的结构是无法支持在播放的同时,分享带宽给其它用户,尤其是在数据压力比较高的时候。而PrismCDN增加了大量的第三方设备数量,提高上行带宽供应量,降低CDN节点压力,从而提高节点分享比例。

PrismCDN能够提升流畅度的关键在UDP协议。UDP协议与TCP协议相比,优化空间更大。实测中,我们让一部分节点用TCP来运行,另外一部分节点用UDP来运行。相较于TCP,UDP可以提升5%的流畅度。

在雾节点选择方面,借助智能调度系统,就近选择节点,解决运营商之间的互联互通问题,避免跨运营商的情况发生。

多种测试确定最合适参数

又拍云PrismCDN中低延时、高分享率以及流畅性这些指标非常重要。但是这些指标中好几个是互相矛盾的,比如说分享率和流畅性,如何在提高分享率的同时提升流畅性?我们在开发的过程当中就在调整这些参数,通过线上系统大规模AB测试不断寻找合适的参数,找到合适的时间点补数据,用多少节点传输数据,用多少冗余节点等。

未来发展

除了P2PHLS之外,又拍云还在研发WebP2P,这里面会用到WebRTC、DataChannel、MSE、Webassembly等技术。我们去销售P2P产品的时候,市场上确实会有一些阻力,因为客户可能会不大信任SDK的P2P产品,包括它的升级和分发渠道,以及出了问题以后如何回滚。但是用WebP2P来做,客户会比较放心了,万一P2P系统有问题,可以快速回滚到老版本去。

你可能感兴趣的:(p2p,直播,hls)