超低延迟直播技术方案及应用

随着直播业务的发展，在线教育，连麦直播、赛事直播等高实时性直播场景的出现，用户对于直播流畅度、低延迟等性能的要求愈加严苛。腾讯云直播技术高级工程师陈华成 从5G时代未来直播产品的发展趋势、直播行业业务新需求出发，分享腾讯云快直播（超低延迟直播）的建设方案、应用以及技术优势与优化实践。

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

01 PART 直播行业的背景 1.1 直播行业新变化

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

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

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

教育类

第二类场景是教育类客户大班课，大班课比较火的主要原因是名师价值最大化。在线教育类企业最主要就是把名师价值最大化，同时保证教学效果。在线教育大班课这种模式，老师面向的可能是上百万学生在听讲，课程讲解结束后老师一般会出一个题目让学生练手，比如数学中配图的解答题、英语的选择题。如果延迟比较高达到几十秒，那老师与学生的互动体验就非常差，老师与学生之间收、发题目的过程会因为延迟较高，导致老师认为已经把题目发给学生，学生实际上还没看到题目，而在老师收题时，学生可能刚看到题目或根本没看到题目，从而导致收题率不高，学生投诉比较多，这是对低延迟刚性的需求。 02 PART 直播行业现状 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不适合低延迟直播。 03 PART 快直播（超低延迟直播）方案 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.已大规模使用（内部已接入腾讯课堂、企鹅电竞，外部已接入教育类、电商类的客户） 04 PART 快直播——延迟、秒开、抗性、画质提升 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的视频优化前效果

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

责任编辑：lq