视频直播的关键技术是什么
本文将从媒体处理和媒体传输两个方面向大家介绍视频直播的关键技术。
l 媒体处理
结合视频直播业务的特点，我们根据直播流程中的不同阶段将媒体处理分为三大类：主播端媒体处理、云端媒体处理和播放端媒体处理。主播端媒体处理又可细分为预处理和编码，而播放端媒体处理又可细分为解码和后处理。
主播端处理
常规的图像增强处理方法在视频预处理环节依然发挥着主流的作用，比如降噪、补偿、平滑、锐化、图像增强（饱和度/对比度）等等。随着视频业务在社会生活中应用场景的不断拓展，一些有趣的媒体应用处理技术也在视频直播场景中逐渐普及开来，比如美颜、瘦脸、换脸、打码、背景虚化/替换、AR/VR 等等。
另一方面，如何提高视频编码压缩效率是业界面临的主要挑战之一。视频编码本质上是一种有损压缩过程。通常情况下，为了获得更低的视频传输码率，编码器需要增大图像编码压缩率，而这势必引起更多视频图像细节的失真和损耗，从而导致视频播放质量的下降。所以，如何在获得更低传输码率的基础上保证足够好的视频播放用户体验，成了图像处理领域研究者和视频引擎技术开发人员需要研究的重要课题。近些年来，人们尝试结合人眼视觉系统（Human Visual System, HVS）对事物感知存在内容偏好的生理特性，将人工智能技术特别是神经网络和深度学习方法引入到了视频图像预处理和编码压缩算法中，并在基于显著性的视频预处理、基于纹理分析和综合的预处理、端到端神经视频编码等研究方向上[1]均取得了一些积极的进展。
播放端处理
播放端的视频处理方法包括两大类，即图像增强技术和超分辨率技术（Super Resolution，SR）。这两类图像处理技术的一个显性区别是，图像增强技术不会改变视频图像的分辨率，而超分技术则主要通过算法推理提升图像分辨率的方式，达到优化视觉效果的目的。
基于 AI 的超分技术相比传统的基于差值或重构的计算方法，在超分效果上具有巨大的优势。不过在多媒体实时传输应用领域，AI 超分技术也面临着两大挑战：一方面，网络视频流通常都是经过大幅压缩编码后的媒体数据流，这种有损压缩很容易造成图像纹理细节的失真和画质的严重退化，如果将这类图像直接进行拉伸，压缩损失很容易被放大，因此超分的效果将大打折扣；另一方面，当今流行的 AI 超分算法，如各种深度卷积神经网络算法，对播放设备的计算能力提出了更高的要求。由于播放设备机型品类繁多、算力良莠不齐，播放端的媒体处理能力和播放实时性都受到了较大的影响。常规的解法是为播放端 SDK 设置一份机型白名单，SDK 只能在指定型号的设备上对媒体数据进行渲染播放前的有限优化处理，而对于算力要求较高的 AI 超分技术，则几乎绝迹于各种智能移动播放设备。
l 媒体传输
如果将媒体处理过程比喻为烹饪一道美食，那么传输技术则是为了把这道美食及时而又安全地派送到观众手中。媒体传输技术涉及到两个细分领域，即传输协议的选型和传输网络的保障。
传输协议
视频直播常见的媒体传输协议规范包括 RTMP、 HTTP+FLV 以及基于 HTTP Adaptive Streaming（HAS）技术的协议，如 Apple HLS、Adobe HDS、MPEG DASH 等。一般而言，RTMP 和 HTTP+FLV 相比 HAS 协议可以获得更低的直播延迟，但是 HAS 协议具备更好的网络自适应能力，可以针对网络可用带宽的实时动态变化选择传输相应码率的媒体流片段。近几年来，HAS 协议设计者们陆续推出了各协议的低延时版本，如 LL-HLS（Low-Latency HLS）[2][3]和 LL-DASH（Low-Latency DASH）[4]，这些改进版本在理想情况下可以将直播的端到端延迟缩短到2秒左右。
从网络协议四层模型来看，以上这些应用层的直播协议都是基于传输层的 TCP 协议实现的。然而，TCP 协议在当今的多媒体通信应用领域存在着诸多缺陷，如建连握手时间长、拥塞控制不灵活、队头阻塞问题严重、抗弱网能力差等等。为了解决 TCP 协议的这些问题，一个全新的运行于用户态的传输层标准协议 QUIC[5]应运而生。QUIC 协议设计了一个基于 UDP 的多路复用且安全可靠的传输机制，为应用程序提供了区别于传统流式传输协议的重要特性：
· 快速的连接握手。支持 0~1RTT 建立连接。
· 连接多路复用。支持连接内的 multiple streams，避免了队头阻塞问题。
· 连接迁移。通过 Connection ID 绑定连接，解决了 NAT 映射失效和移动设备多网切换等问题。
· 灵活的拥塞控制机制。在用户空间（而不是内核空间）实现，可结合应用场景灵活配置和调优。
另一方面，在多媒体数据传输如视频直播的应用场景，选择合适的拥塞控制算法对提升传输效率、降低传输延时尤为重要。Google 公司在2016年提出了一个全新的拥塞控制算法：BBR（Bottleneck Bandwidth and Round-trip time）[6]。相比基于丢包检测的传统拥塞控制算法（如当前 Linux 内核默认的拥塞控制算法 CUBIC）而言，BBR 基于传输带宽和往返时延估计的拥塞发现机制更加与时俱进，更适用于新时代的互联网基础设施部署环境。
图9显示了一个 TCP 连接中从一端向另一端发送数据时，数据传输速率和 RTT 与 inflight 数据量（已发出尚未收到 ack 的数据量总和）之间的关系。在网络拥塞尚未发生时（即 app-limited 阶段），随着数据传输速率的持续提升，RTT 可以保持稳定。当 inflight 数据量增加到 BDP（传输瓶颈带宽 BtlBw 与往返时延 RTprop 的乘积）之后，拥塞开始发生，瓶颈路由节点开始缓存数据，RTT 开始变大，数据传输由此进入到 bandwidth-limited 阶段。当 inflight 数据量持续增加到 BDP+BtlneckBufSize 之后，意味着 bottleneck buffer 已满，只能进行丢包处理，数据传输也随即进入到 buffer-limited 阶段。
显而易见，理想的情况下我们希望在 inflight 数据量恰好达到 BDP 时就可以检测到网络拥塞的发生。然而，基于丢包检测的 CC 算法需要等到 buffer-limited 阶段（即丢包开始发生时）才能发现这一点。这将带来两个问题：当 BtlneckBufSize 比较大时，因 bottleneck buffer 溢出丢包才确定拥塞很容易引起高延迟、高抖动等 bufferbloat 问题；而当 BtlneckBufSize 较小时，丢包不一定就意味着拥塞的发生，此时的误判将会促使发送端减小发送窗口，从而造成传输吞吐量迟迟无法提升上去。BBR 的设计思路就是在数据传输过程中通过对 BtlBw 和 RTprop 进行持续地探测和更新评估，计算出动态的 BDP 值，从而达到发现网络拥塞的目的，并依此进行数据发送节奏的控制。BBR 算法在 GCP（Google Cloud Platform）上的部署应用为 Google 服务在优化传输延迟、提升吞吐量和 QoE 等方面带来了大量的收益[7]。
QUIC 协议和 BBR 算法的珠联璧合为业务应用的优化带来了新的选择。网易云信视频直播系统在推流端和拉流端同时集成了对 QUIC 协议和 BBR 算法的支持，在直播活动上下行的第一公里或最后一公里通过 RTMP over QUIC 进行媒体流的传输能够有效地改善媒体数据的传输效率以及抗弱网和抗抖动的能力，进一步提升了视频直播的用户体验。
传输网络
常见的视频直播传输网络环境包括公共互联网（公网）、专线网络、CDN 网络和RTN 网络等。
公网是运营成本最低的传输网络，但是它的缺点也很明显，那就是网络可靠性（带宽、延迟、抖动等）缺乏保障，所以通常被用于直播的最初或最后一公里链路。
使用专线网络可以解决网络可靠性的问题，但是缺点是使用成本较高。
CDN（Content Delivery Network）是一种在互联网中被广泛使用的网络基础设施。在视频直播应用场景中，CDN 可以为直播用户提供廉价的跨区域的大规模的数据分发能力，它的主要问题是传输延迟较大（秒级）且各 CDN 厂商的服务能力参差不齐。
RTN（Realtime Transmission Network），顾名思义，就是设计用于提供实时数据传输能力的大规模分布式网络传输系统。RTN 基于公网基础设施，通过纯软件方式实现，不依赖硬件也不借助专线网络进行优化，而能够将端到端的延迟控制在百毫秒级别。另一方面，为了实现 RTN 实时稳定的数据传输能力，RTN 厂商不仅要投入研发资源进行路线探测、路由调度等各种算法的持续升级调优，也需要在网络节点部署、带宽租用等方面投入大量的资金，其投入成本堪比 CDN。
参考文献
· [1] Dandan Ding, Zhan Ma, Di Chen, et al. Advances in Video Compression System Using Deep Neural Network: A Review and Case Studies.
· [2] APPLE.COM. Enabling Low-Latency HLS. https://developer.apple.com/documentation/http_live_streaming/enabling_low-latency_hls
· [3] Roger Pantos. HLS 2nd Edition. https://datatracker.ietf.org/doc/html/draft-pantos-hls-rfc8216bis
· [4] DASH-IF. Low-latency Modes for DASH. https://dashif.org/docs/CR-Low-Latency-Live-r8.pdf
· [5] Jana Iyengar, Martin Thomson. QUIC: A UDP-Based Multiplexed and Secure Transport. https://datatracker.ietf.org/doc/html/rfc9000
· [6] Neal Cardwell, Yuchung Cheng, C. Stephen Gunn, et al. BBR: Congestion-Based Congestion Control. https://dl.acm.org/doi/pdf/10.1145/3012426.3022184
· [7] GOOGLE.COM. TCP BBR congestion control comes to GCP – your Internet just got faster. https://cloud.google.com/blog/products/networking/tcp-bbr-congestion-control-comes-to-gcp-your-internet-just-got-faster
以上就是视频直播的关键技术的内容。
| 相关阅读
1、网易云信：融合通信云服务专家、通信与视频 PaaS 平台
集网易 24 年 IM 以及音视频技术打造的融合通信云服务专家，稳定易用的通信与视频 PaaS 平台。提供融合通信与视频的核心能力与组件，包含 IM 即时通讯、5G 消息平台、一键登录、信令、短信与号码隐私保护等通信服务，音视频通话、直播、点播、互动直播与互动白板等音视频服务，视频会议等组件服务，并联合网易易盾推出一站式安全通信方案「安全通」。目前，网易云信已经成功发送 1.6 万亿条消息，覆盖智能终端 SDK 数累计超过 186 亿，我们期待每个智能终端都有云信的融合通信能力。
2、网易云信：自主研发新一代大规模分布式传输网络即WE-CAN
WE-CAN是一个架设在公网之上，通过智能链路探测算法和智能路由调度策略将数据从全球任意端点快速、稳定、高效地发送到任意目标端点的多功能实时传输网络系统相比传统的RTN 网络，WE-CAN 的传输速度更快，传输成本更低，适用场景也更加丰富。WE-CAN 不仅能够对RTC媒体流进行高到达、低延迟的传输，也能对视频直播流进行大规模、低延迟的分发，还能对信令、即时消息（IM）和其他业务数据进行可靠传输。WE-CAN 的媒体数据传输在全球范围内延迟不超过 250ms，而优质传输率则达到了 99% 以上。
