腾讯云快直播——超低延迟直播技术方案及应用

LiveVideoStack 2020年10月28日

文 / 陈华成

整理 / LiveVideoStack

视频回放:https://www.livevideostack.cn/video/online-huacheng/

大家好,我是腾讯云直播技术高级工程师陈华成,这次和大家分享的主题是腾讯云快直播——超低延迟直播技术方案及应用。主要涵盖以下四个方面:直播行业的背景;直播行业的现状;快直播(超低延迟直播)方案;快直播——延迟、秒开、抗性、画质提升。

直播行业的背景


1.1 直播行业新变化



首先我们来看一下整个直播行业在近期有哪些新的变化。5G的到来将使得边缘带宽由Mb增长至Gb、带宽容量增加、延迟由30ms减小至1ms左右;此外应用场景也将得到丰富,调研发现与5G最相关的10大场景均是低延迟音视频应用,比如电商类、在线教育、云游戏、VR、AR、物联网、自动驾驶等等。

1.2 快直播(超低延迟直播)应用场景

本次分享主要介绍两个快直播(超低延迟直播)应用场景。

  • 直播带货兴起——要求延迟小于500ms


首先是直播带货。相信大家近一年对直播带货应用场景感受很深。据统计,今年五一期间整个直播带货量增长了五倍左右。那带货场景有哪些呢?其实就是把线下的促销变成了线上,上图中列举了两个典型场景。第一个是低价秒杀促销,主播为了活跃气氛带动更多的人参与进来,她会给一些低价商品让大家抢购,秒杀的过程要求延迟很低。第二个是主播为了活跃气氛发红包,这两个场景对延迟的要求都很高。现在标准直播的延迟一般在三到几十秒,是无法满足带货需求的。延迟高也限制了带货新玩法的出现,导致现在的直播带货几乎没有互动。


  • 教育类



第二类场景是教育类客户大班课,大班课比较火的主要原因是名师价值最大化。在线教育类企业最主要就是把名师价值最大化,同时保证教学效果。在线教育大班课这种模式,老师面向的可能是上百万学生在听讲,课程讲解结束后老师一般会出一个题目让学生练手,比如数学中配图的解答题、英语的选择题。如果延迟比较高达到几十秒,那老师与学生的互动体验就非常差,老师与学生之间收、发题目的过程会因为延迟较高,导致老师认为已经把题目发给学生,学生实际上还没看到题目,而在老师收题时,学生可能刚看到题目或根本没看到题目,从而导致收题率不高,学生投诉比较多,这是对低延迟刚性的需求。

直播行业现状



2.1 标准直播现状



现在直播行业大多数用的是标准直播,它的直播协议主要是FLV、HLS、RTMP。FLV延迟一般在2-10秒左右,它的延迟因素主要是GOP大小和TCP弱网传输积压。HLS的延迟更大,一般是几秒到几十秒,它的延迟因素主要是GOP大小和TS大小,HLS是以文件索引和下载的方式,它每个文件的的大小限制了它的延迟,很多播放器要等3个TS才播放,而3个TS可能就有几十秒了,所以HLS在标准直播中延迟最高。此外RTMP的延迟因素主要是GOP大小和TCP弱网传输积压。以上介绍的集中标准直播都是基于TCP的,当前QUIC的引入对弱网带来的延迟有一定的改善,但QUC没有流媒体特性,在这里不是一个最佳方案。


2.2 TCP不适合低延迟直播的原因



  • 延迟确认+捎带应答 带来感知延迟

TCP有延迟确认和捎带应答,比如数据发过来不是立即对每个数据响应ACK,攒一定的数据量才会响应,这就会带来感知延迟,超低延迟整体只有几百毫秒,这一部分带来的延迟是不可忍受的。


  • 弱网场景,可靠传输导致数据积压

弱网场景下,像TCP机制会导致数据积压。举个例子,主播在推流,然后发送缓存,因为TCP有一个可靠缓存的对列,而网络条件比较差的时候,发送窗口发送完了却一直没有ACK,窗口一直没有往前滑动,就会导致直播这种实时传播的数据积压,甚至会导致几秒钟或几十秒钟的延迟。

  • ACK机制导致通道利用率低



ACK机制会导致通道利用率低,在ACK之后不是立马就返回的,还有ACK的等待时间。在这段时间通道未被利用就会导致通道利用率变低。


  • 无流媒体特性、可靠传输导致无效重传

直播是有时效性的,上图1、2、3、4、5、6,可以看到5、6数据已经过期了,但无效的重传会一直重传,直到传输成功,所以无效重传进一步加剧拥塞。

综合以上四点可以得出TCP不适合低延迟直播。

快直播(超低延迟直播)方案



3.1 UDP是低延迟直播的必由之路



调研显示,低延迟直播在业界的协议有QUIC、SRT、WebRTC、ORTC,比较而言QUIC的延时还是比较大的,因为他没有流媒体功能;SRT、WebRTC、ORTC延迟都是毫秒级别的,都有流媒体特性,其中SRT、ORTC用的比较少,WebRTC生态繁荣,因此我们选择了WebRTC做超低延迟。


3.2 延迟关键问题在哪里?



我们要做超低延迟,首先就要知道它们的超低延迟出现在哪里?整个直播过程从数据的采集、编码都经过哪些过程?


首先是视频输入摄像头采集的数据,由YUV编码成264、265数据,采集t0,编码t1,推流传输t2,转码t3,再由CDN传输,经过视频解码,最终通过视频显示出来。在这个过程中摄像头采集耗时很小,一般在十几毫秒左右;编码耗时通过调整编码参数也能达到几十毫秒;推流传输是和rtp相关的,基本耗时在十几毫秒到几十毫秒;如果采取高速转码,耗时也不高;最关键的是CDN传输和视频解码,用户的网络现在千奇百怪,对于网络条件好的用户,传输延迟可能不高,但对于网络条件不好的用户,传输延迟可能就要达到几秒甚至几十秒,所以TCP传输延迟是一个不可控的因素。在t5视频播放和解码阶段,目前像Flash播放器、hls、rtmp播放器缓存需要6-10秒,播放器的缓存是产生延迟的关键原因。那为什么不在当前直播条件下把缓存调到0呢?这是由于调到0之后延迟虽然小了,但卡顿会很高。由此可以看到,延迟高的关键在于CDN的传输和播放解码没有很好地配合和互动。所以我们主要要解决这个问题。


3.3 快直播方案



快直播方案改造的就是从CDN分发节点到SDK、再到观众端播放这部分,这样的好处在于主播推流中间的录制、截图、转码等都可以复用,接入简单,可以同时出flv、rtmp、hls、WebRTC的数据流。


3.4 快直播对标准WebRTC进行了升级



此外快直播对标准WebRTC进行了升级。标准WebRTC存在很多限制,音频只支持OPUS、视频不支持H265(H265因为专利的一些问题,因为VP9和H265有竞争关系,谷歌更希望推VP9)、视频不支持B帧、信令交互耗时长、无法透传metadata,这些问题对于在线教育和主播带货是没必要的,可以跳过。而有些客户希望用metadata带一些同步信息,显然标准WebRTC是不支持的。


我们从五个方面对标准WebRTC进行升级,包括支持aac(同时支持adts、latm两种封装)、视频支持H265和B帧、通过STP协商精简了信令交互、可以关闭gtrs以及支持透传metadata。上图就是腾讯云快直播的Demo,从图中可以看到支持H264、H265,Audio格式、加密开关。


3.5 快直播如何接入



快直播的接入其实非常简单,只需要一步就可以从标准直播升级为快直播——升级播放端、其余全部复用。Web/H5端调用浏览器WebRTC接入快直播,App接入需要集成SDK。


3.6 快直播优势



快直播有五大优势:


1.全球分布、覆盖广泛(支持1100+节点,支持25个国家)

2.超大带宽容量(我们的部门拥有了腾讯90%的流量,支持100T+带宽)

3.质量好、成本低(抗30%丢包)

4.接入简单(只要下行SDK做改造就可以了、功能完善、平滑兼容)

5.已大规模使用(内部已接入腾讯课堂、企鹅电竞,外部已接入教育类、电商类的客户)

快直播——延迟、秒开、抗性、画质提升


4.1 快直播延迟



我们现在能做到的延迟一般是300ms左右,极限延迟可以做到43ms,这个极限方案主要是给云游戏提供的,硬件编码通过边缘编码处理的方式得以实现。


4.2 快直播首帧耗时秒开



标准WebRTC要经过sdp交互、ice、dtls握手、rtp/rtcp,这里第二步和第三步基本是可以跳过的,ice可以用简单的storm来代替,dtls握手对于不需要加解密的也可以跳过,所以我们做了一个可以通过SRTP协商来关闭dtls握手,所以第二、第三步可以根据需求选择性的开或者关,从而通过精简信令优化首帧耗时。


第二点就是边缘覆盖,我们不同的地方是信令和流媒体sever都部署在边缘节点,这就会保证用户与我们信令和流媒体交互的时候RTT多数会很小,从而就会保证整个信令耗时很短。


另外还有一个影响首帧的是流媒体的回源,如果命中率不高,流媒体需要回源,也是一个首帧耗时的点,所以我们做了个调度按房间来收敛,提高命中率,也就是说在同一个省份看同一个房间的话都让他走到同一个机房。通过以上三点优化首帧耗时基本达到100多ms。


4.3 快直播WebRTC抗性优化



WebRTC抗性怎么优化?这里抗性优化的本质是不断 “感知 + 调整 ”来适配变化的网络,这里的感知主要是RTT、丢包率、瓶颈带宽,通过感知到的网络的变化来调整发包策略、重传策略、FEC冗余策略等等。上图把网络分为两类,有丢包未拥塞的网络(基站的信号弱,WiFi的信号弱),这种情况通过根据丢包率计算重传次数,提高重传成功率,也可以通过FEC冗余发包,在弱丢包或者少丢包的情况下不需要重传。有丢包且拥塞的网络,它的表现主要是是丢包且RTT变大,这种情况又分为两种:一种是我们的码率超过了瓶颈带宽,第二个是码率没有超过瓶颈带宽。上图可以看出I帧与P帧的关系,在视频会中比较特殊的是I帧一般比P帧大8-10倍左右,所以很多时候发包策略不受控制的时候,每次发一帧的时候就是很大的毛刺。



这里我们采取的是场景的识别和动态的适配。


第一种是码率不是瓶颈,我们采用的是自适应的Pacing、根据I帧的播放时间以及buff将它平化掉,就会使得整个发包带宽在瓶颈带宽以下,从而兼顾帧率、帧大小、瓶颈带宽、播放器缓存,整个丢包就会少很多。


第二种是码率是瓶颈,也就是它的码率在瓶颈带宽以下,如果不降低发送的数据量就一定会导致拥塞。我们有两种策略:一种是时域分层,在编码的时候,将视频帧分三到四个级别,比如I帧、P帧、B帧,因为有一些B帧是没有依赖的,我们可以通过丢失一部分的帧直到码率小于瓶颈带宽,也就是通过降帧率达到降卡顿的效果。另一种方式是空域分层,比如说编码的时候,我们会编高分辨率和低分辨率,对于弱网(码率是瓶颈)的情况下,我们通过只发低分辨率的帧使码率小于瓶颈带宽。



以上是我们抗性优化的效果。从左上的图片中可以看到我们在做pacing前I帧的毛刺是很大,通过pacing发包可以减少80%突发毛刺,通过这张图可以看到在我们自己的应用上体现,WebRTC的质量是和flv相当的,而延迟从10秒降低到300ms,并且可以抗30%+丢包。


4.4 快直播画质优化



画质优化主要通过“云+端”来做协同优化,就是源流在编码的时候做修复增强,再通过一定的算法把视频进行压缩输出低码率的流,同时在云端进行云上的预分析,检测出视频的纹理区域以及边缘区域,然后把数据写到SEI中去读出纹理和边缘区域,如果是上采样就提高采样率进行超分,这样通过云端压到低码率、再由终端恢复到高码率的策略从而达到画质最强的效果。



上图是我们云端的优化效果,通过边缘区域的网格增强,平坦区域直接上采样、纹理区域网络增强。



540p的视频优化前效果



优化后的效果,它的边缘和细节清晰了很多


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

陈华成

腾讯云直播技术高级工程师

文章

粉丝

视频

阅读排行
热门视频

SRS实用手册-一剪定乾坤(10)

杨成立/RTC服务器团队负责人

WebRTC视频数据流程分析

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