腾讯视频云流媒体技术探索

编者按： 赛事直播场景与普通直播场景有一定差异，赛事直播场景对码率、画质、延时等性能要求更高。LiveVideoStackCon 2022 音视频技术大会上海站邀请到了腾讯专家工程师，媒体直播负责人——吴昊老师，为我们分享《腾讯视频云流媒体技术探索——赛事直播场景的技术优化》，他将介绍如何利用多路径传输、QoS控制，以及跨区调度和加速的能力，优化端到端的传输质量。在媒体处理和封装上，他将介绍通过多码率自适应、低延迟、多音轨、广告插入等技术，提升终端的播放体验，同时满足国内及海外不同场景的需求。

文/吴昊

整理/LiveVideoStack

大家好，我是腾讯专家工程师吴昊，很高兴来到LiveVideoStackCon 2022 音视频技术大会 上海站，为大家做这次的线下技术分享。今天我的主题是：在赛事直播场景下，视频云流媒体技术的优化探索。

1、Introduction

首先介绍背景，自从2020年以来，疫情改变了人们工作和生活的方式，越来越多的线下活动开始以线上的形式举行。与此同时，人们对体育赛事、电竞赛事等娱乐活动的关注度逐年提高。线上制作和赛事直播成为了人们的核心诉求。

通常一个完整的赛事直播流程如下：赛事现场可能是遍布全球的，比如电竞赛事、世界杯足球赛等，首先通过远程低延时传输的方式，将远程采集到的音视频信号传输到制作中心，由于制作中心的成本较高，无法按照赛事场地的要求进行适配，因此需要一个全球化的媒体传输方案。然后，经过二次制作后，通过媒体源站，进行媒体处理、编码、封装。最后，通过CDN分发到观众的播放端上。因此，保证整个流程的稳定性和质量成为了一个关键。

接下来，将从3个点分别进行介绍。首先，如何通过优化媒体传输来提高源站的可用性。其次，针对播放端的体验，在协议和架构上的优化方面可以做些什么。最后，针对赛事场景，我们有哪些技术上的创新点。

2、媒体传输与高可用源站

在媒体行业里，有很多流媒体的传输协议，这里列举一些常用的协议。首先是最常用的基于TCP的RTMP，它的历史较为悠久，目前也是国内、海外最常用的流媒体协议。但是它本身存在一些不足的地方，如因为版本维护等其他原因，它支持的编码格式不够完善，在传输H.265，AV1时可能需要一些私有化的改造。其次，基于TCP的RTMP在传输抗抖动性和延迟上相对其他协议做得并不太好。第二个介绍的是RTP，它是广电媒体行业里常用的流媒体传输协议，它的容器格式：MPEG-TS支持的编码格式比较完善，同时，基于UDP的RTP在延迟上做的比较好，但它本身存在最大的问题是不支持可靠传输的，所以通常采取FEC或SMPTE2022-07的标准，通过冗余发送和聚合去重的方式来提高稳定性。SRT是一个近年逐渐得到推广应用的协议，它具有低延迟，高抗抖动性的特性，同时有多路复用以及多路径的特点，目前逐渐成为一些大型赛事的首选流媒体传输协议，已逐渐替代RTMP成为主流。第四个介绍的是QUIC，严格来说它不是太适合，它更适合互联网场景，如在web生态等做得较好，目前成为HTTP3的传输标准。RIST与SRT有竞争关系，是近年逐渐得到应用的一个流媒体传输协议，它在延迟、高抗抖动性方面做得较好，但在标准化、多版本间的兼容性方面存在一些问题，这限制了它们在目前市场的占有率，但相信在未来更多场景会使用RIST。以上是公网的一些传输协议，但也有一些针对专业视频制作领域的局域网的传输协议，如NDI、ST 2110等，它们的主要特点是极低的延迟，传输的主要是未压缩或浅压缩的一些音视频信号，如ST 2110传输的JPEG-XS，只做了帧内预测，没有做帧间的运动估计，这样的好处是可将延迟降到一个帧的级别，但会有压缩效率低的问题。因此这些局域网的协议对传输网络条件要求较高，限制了它们在公网传输中的应用。

简单来说，针对直播流媒体在传输机制上需要做哪些优化？如在连接机制上面，通过优化信令来减少首帧的延迟，通过多路复用解决队头阻塞的问题。然后，在纠错和重传机制上面，我们基于更精确的RTT测量去动态调整重传间隔以减少不必要的重传，其次，除了NACK、超时重传以外，我们还通过FEC、RLNC等信道编码技术，通过冗余发送的方式来降低传输延迟。还有一个大家比较容易忽视的地方，就是乱序的处理问题，在传输过程中，要自适应地调整乱序容忍度，来减少不必要的重传带来的网络拥塞。在拥塞算法上，像bbr、cubic、以及WebRTC中的Transport-cc等，它们的思路不太一样，我们一方面基于延迟梯度的带宽估计，去做码率自适应的控制，但要注意在一些场景，如低RTT的场景，可能类似于基于RTT延迟或延迟变化的拥塞控制算法，反而没有基于丢包的算法更准确，所以需要根据实时的网络QoS去做自适应的调整拥塞控制算法。最后一个针对的是直播场景，特别是媒体新闻的场景，需严格控制整体的端到端延迟，因此需要传输协议能支持可选择性的丢包，即通过控制一段固定的Buffer来维持一个恒定的延迟。

我们主要基于SRT，也结合了QUIC、WebRTC中的一些优势，同时做了刚才提到的一系列优化，最终形成了一个针对流媒体远程传输的产品，同时，也提供了SDK的接入方式。通过与常规的RTMP，甚至QUIC的对比，发现它在卡顿和延迟上都得到很大的提升。

多路径传输是一个重点。现场可能有4G、5G、WIFI等多种网络并行，通过多路径传输的算法，可以很好地规避单一网络波动所带来的影响，如当4G、5G的使用人较多，现场可能出现信号中断，这时通过多条链路进行实时地补偿，可以做到下行的平滑切换。但这种方案有一些限制，如它要求现场必须有多种网络类型，但很多情况下不具备这样的条件。又比如，新闻外采等处于户外场景时，可能是在偏远地区，上行接入节点可能无法做到本地覆盖，这时通常可以采用多个上行节点备选的方式，在推流前进行探速，选择质量最好的节点进行推流，但当新闻或赛事持续时间长（如有些媒体领域需7×24h不间断直播），这样的方式无法适应网络的变化带来的影响。因此，提出多接入点的方案，允许接入端同时链接多个接入节点，在传输过程中，根据每条链路的QoS对比情况进行动态切换或调整发送的比例，来达到下行无感知的效果。

多路径传输的方案较多，最悠久的是MPTCP，目前已经形成了标准，它的原理是根据已创建的链接，通过子flow的方式定义一个新的子链接，同时借助token、随机数、HMAC等安全算法来确保建立子链接的安全和准确性。但它也有一些局限，如因为TCP与内核相关，在部署时有阻碍和瓶颈，并且MPTCP存在兼容性问题，如多路径版本的TCP与普通TCP存在兼容性问题。

MPQUIC沿袭了TCP的思路，包括通过迁移、协商的方式来建立新的链接。同时，它改进了一些机制，如在重传机制上，它允许一个链接的重传包在另一个链接上重传，这时因为两个链接的RTT可能不一样，因此若仍用RTT较大的链接进行重传，可能延迟会增加，而用RTT较小的链接进行重传，来补齐这个延迟。此外，相对TCP，QUIC的兼容性更好，因为没有在QUIC的包头额外新加字段。

SRT中的多路径方案为SRT-BONDING，它的大致原理是在handshake阶段，每个子链接会有一个group id，服务端根据group id将不同的srt\_socket“绑定”到一起。我认为bonding这个词用得比multipath要好一些。其实原本的SRT支持的是广播和Backup模式，在此基础上，我们新增支持聚合模式。聚合模式使用起来相对更复杂，需要根据实时的QoS的状态，如 RTT、重传率等来调整发送比例。

这个视频演示的内容是：在网络发生切换时，它能有一个很平滑的切换过程。

将现场的音视频信号传输到云端后，还要将音视频信号低延迟地远程传输到可能位于地球另一端的制作中心，因此需要一个云端的低延迟远程传输方案。我们的StreamLink能提供全球化的高速、稳定、低延迟的视频流媒体的传输服务和平台，解决现场到制作中心的低延迟远程传输的问题。同时支持协议间的转换，如由于设备的原因，上行只支持RTP，或只支持RTMP，甚至只支持UDP、TS这种，那么我们通过中间的传输环节，在制作中心转送适配的音视频传输协议。

除了媒体传输方面，我们还可在源站方面提高稳定性。比如在媒体层面，采用SMPTE2022-07等标准，该标准通过冗余发送的方式做到帧级别的冗余纠错。但这个标准存在一些局限，如它要求这个源是来自于相同编码器推两路流上来。那有可能现场有两个机位，它们编码器设置方面或者参数方面可能有些不一致，那么在这种场景下，我们还需要进行基于时间戳的GOP粒度的平滑切换，并对时间戳进行一些修改，而不能按照帧级别进行切换。在分发阶段，需要结合每条链路量化的QoS，去动态决策每个路由需发多少比例的数据，来达到整体的稳定性。

3、流媒体播放体验优化

接下来，针对这些播放协议，介绍我们有哪些优化手段。

除了卡顿、首帧和成功率等指标，直播场景下，我们对直播的播放延迟和画面质量也有很高的要求。

在媒体源站上，除了通过输入双通道提升稳定性，通过自动补帧等功能做到平滑效果外，我们还基于腾讯云智能极速高清编码技术，达到在相同画质的场景下码率更低的效果。

其次，在输出方面，首先通过独立的output group输出设置来满足不同场景的需求，并且隔离相互间的影响，比如设置不同的分辨率、码率组合等。还需注意的是，若要采用自适应多码率，要确保多码率间的切片边缘达到帧级别的对齐，这样切换码率时才能保证画面不前进或后退。另外，由于4K、8K视频流对CPU的消耗较高，当前的容器或云主机无法做到所有的码率组合，因此需要提供分布式转码任务和切片封装的能力，并在提升可扩展能力的同时，保障多码率间达到帧级别的对齐。

媒体行业里常用的一个平滑手段是continue，即在断流期间可以自动补齐静音、黑屏帧，但这样的效果不佳。另外，还可以自动补齐一张图片（如PPT右图所展示的图片）或提前准备好的一段广告。

在封装阶段，我们支持HLS、DASH、CMAF等自适应多码率的输出，也支持一些低延迟的输出，还支持DRM、多音轨等输出。同时，源站支持多CDN的接入，包括转存、回源、分发，这更适合多CDN场景的架构。

流媒体里的一个关键因素是延迟。相对其他协议，国内最常用的FLV的特点是较简单、

消耗较少、延迟较好（2、3秒级别），因此它是目前国内主流的播放侧的协议。但它最大的问题是由于版本维护等历史原因，支持的编码格式不多，比如对HEVC、AV1等格式支持得不太好，或需要一些私有化的改造，且在多码率、多音轨等方面做得不太好。

HLS、DASH很好地解决了上述问题，但同时它们的延迟较高，这是因为切片的粒度至少是一个GOP，因此带来的延迟是n个GOP，这样延迟相对于FLV，不能达到在一个GOP内也能够开始播放的效果。

因此，在这种场景下，低延迟流媒体应运而生。LL-DASH和LHLS，或者基于CMAF这种低延迟DASH和HLS，它利用chunked传输机制，能将延迟控制在和FLV的延迟同一个级别的场景。苹果官方的LLHLS可做到相对更低的延迟。若要达到1秒以内的延迟，需要借助实时音视频的王者，即WebRTC，它通过一些传输机制，如分级重传等机制，可将延迟控制在500毫秒，甚至更低。但它本身也存在一些不足：它的协议比较复杂，涉及到私有化的改造，需要更复杂的信令来实现多码率、多音轨，对于CDN的架构，改造的成本和挑战也较多。

低延迟切片的基础是分块传输编码，HTTP 1.1的版本已经对其进行了支持，但LL-DASH还做了容器化的改造，如支持Chunked CMAF，更重要的是在 CDN的分发系统里支持Chunked传输，这是CDN、媒体源要做的事情。

与此同时，LLDASH、社区版的LHLS（不是苹果官方的LHLS）也有各自的优化思路。LLDASH提供Manifest文件来告知播放器，在什么样的延迟下以什么样的播放速率去播放，这样在延迟较大时，可以按照比如1.1倍的速度进行播放，将延迟“追上来”。LHLS采用预加载的方式，通过manifest告诉播放器下一个分片是什么。

而苹果官方的LLHLS会成为低延迟LHLS的标准，社区版的LHLS会逐渐被废弃。LLHLS的改进点更多，它摒弃了chunk transcoding encoding，即分块传输编码，采用粒度更小的切片，直接在Manifest文件中展示出来，同时也提供预加载方式。此外，提供阻塞式更新和增量升级，它允许播放器在请求LLHLS时，带上当前已下载的menu sequence序列号，即已下载的分片，以及子分片的序列号，服务端会根据这个参数判断有无更新的切片产生，若没有新切片产生，通常的HLS直接返回旧的m3u8文件，而这种低延迟的HLS会阻塞住，一直等到有新的切片产生再返回，这样的好处是它能第一时间把信息推送给播放器，而不是等到轮询的方式再去获取信息，其次可以减少播放器的请求次数。还有一些其他手段，如更快的码率切换，它允许一个子码率的m3u8可以携带其他码率信息，这样播放器可以复用一个连接去快速请求其他码率的数据，还有一个是server push，但是我看它已经在最新的常案中被废弃了，因为它需要HTTP/2的支持。这些特性LLHLS也提供更灵活的播放端的控制，允许播放端带上一些参数来选择性地开启这些开关。

如果要想达到1s内的延迟，需要借助基于WebRTC的超低延迟直播，目前WebRTC更多地应用在实时音视频的场景，但我们也将其用在低延迟的直播场景，如电商、课堂互动场景。除了在传输上简化信令以外，也结合了直播流媒体的特点进行了深度优化，包括分级重传、选择性地丢帧等，这里不再赘述，总体上能够在弱网条件下，也能保证低延迟。

4、赛事场景探索与创新

最后，简单介绍针对赛事场景，我们一些比较有意思的创新。

比如直播时移。在直播过程中，将切片实时地存储起来，这样可以统一直播和时移的分片格式和分片内容。一方面，简化播放器请求的逻辑和参数，实现拖拽即时移的效果。另一方面，在直播过程中，动态地智能生成精彩点位的信息，具体做法是，在媒体处理阶段，进行视频帧分析，通过深度学习和智能分类技术，把画面中出现的热点事件（如英雄联盟中的五杀事件）捕捉出来，通过接口回调的方式推送给业务平台方的接口，业务平台方接收到信息后，可在其播放页面或播放器上展示出相应的效果。

另一个是广告插入，这个技术比较悠久，根据插入位置，可分为视频前广告、视频中广告和视频后广告，直播领域主要是前两种。从技术手段来讲我们主要分为3类。第一类，可达到千人一面的效果，即将提前准备好的视频广告在编码环节加入视频流里，这样大家看到的广告都是一样的。第二类，借助广电行业的标准：SCTE-35，SCTE-35是MPEG-TS里的事件信息标识的标准，将其应用在广告插入里能达到动态插入的效果，在最终的HLS、DASH、CMAF的Manifest文件里会打上相应的标签，播放器读到标签后，可以在它所指示的时间点做相应的行为，如开始一段广告、暂停或停止播放等。第三类，是个性化广告，让大家看到的广告都不一样，这包含了智能化技术，如通过视频帧的智能识别，识别到转场画面或特殊事件时，打上一个标记，播放器得到这个标记后，可遵循VAST等标准，去请求这个标记和源信息里包含的广告投放方的接口，广告投放方可根据历史画像，如IP信息、国家地区信息，去下发不同的广告内容，这样就实现了千人千面的广告效果。

最后是云导播。云导播是制作中心的一种低成本云端替代方案，在一些低成本的应用场景，更加适合采用云导播方式，实现在云端一键切流、混流、字幕、水印等一系列强大的音视频处理能力。

以上是本次的分享，感谢大家！

---

---