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

编者按： 赛事直播场景与普通直播场景有一定差异，赛事直播场景对码率、画质、延时等性能要求更高。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 信息、国家地区信息，去下发不同的广告内容，这样就实现了千人千面的广告效果。

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

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