导读：移动互联网的兴起为人类信息传播带来了更便捷的通道、更立体的视角和更丰富的选择。视频直播等多媒体通信技术在新的时代背景下逐渐崭露头角并不断渗入到人们的日常生活中，以提高人们的信息传输效率、降低信息传输成本。
文｜郑文彬
网易云信云平台融合通信技术团队负责人/架构师
直播概览
进入后疫情时代，视频直播技术在众多行业市场的应用日益广泛，也吸引了众多的从业者投入到相关技术领域的学习、研究和应用开发中来。一方面，在电商营销、社交娱乐、在线教育、金融服务等垂直行业，视频直播技术能够推动企业生产经营活动进一步提升价值、控制成本，帮助企业实现开源节流的同时加速推动企业进入数字化转型的快车道；另一方面，5G 网络基础设施的加速建设、云计算和人工智能技术的大幅推广进一步催化和加速了视频直播产业的升级和发展壮大。如图1所示，在未来的三年里，国内企业直播服务市场的规模预计仍将延续较高的增长势头。
直播架构
对组织者而言，准备一场直播活动，所需要的工具和依赖的平台既可以很简单，也可能非常复杂。
在简单使用场景下，主播端借助常见的推流工具（如 OBS）就可以实现音视频数据的采集和编码，并将媒体流推送到云端，而播放端也可以借助常见的媒体播放工具（如 VLC）直接拉流播放，如图2所示。
但是，在某些特定的直播场景，组织者可能会对直播活动的规模和品质提出多样性的要求。最典型的需求是支持媒体流的多个码率输出以适配不同观众所处环境的网络状况，其次是支持大量观众同时在线观看。甚至在一些大型直播活动中，比如网络在线演唱会，活动方希望能够对活动现场的多个媒体源或摄像机位进行直播切换控制。为了支持这些复杂的直播特性和需求，开发者需要引入更复杂的直播服务架构，如图3所示。
直播流程
一个典型的视频直播完整流程如图4所示。
主播端负责音视频数据的采集、预处理、编码压缩，并将封装后的媒体流推送到云端的直播媒体网关。
直播媒体网关在接收到来自主播端的媒体流之后，将其转发给媒体处理服务（MPS）进行云端的媒体加工处理，比如添加水印、转码等等。处理后的媒体流通过直播媒体网关转推到 CDN 网络，或者通过 CDN 回源拉流的方式，进行媒体流的分发。
最后，播放端通过访问直播 URL 地址从 CDN 的下行边缘节点拉取指定的媒体流，对其进行解码并做必要的后处理，然后再输出到渲染模块进行播放。
QoS 指标
在一场直播活动中，影响观众直播体验（QoE）的因素有哪些呢？下面我们介绍在视频直播过程中需要关注的一些 QoS 指标。
首屏时间：即播放器从发起直播请求到显示第一帧视频图像所需要花费的时间。这个时间越短，用户体验越好。
尺寸：即视频图像的分辨率（长度x高度，单位为像素值）。一般情况下视频的尺寸越大，清晰度越高。
帧率：又叫帧速度，即每秒钟采集的视频图像的帧数量（Frame per Second，fps）。一般而言，视频帧率越高，播放流畅度也越高，但是较高的帧率也导致了较大的数据传输量。
码率：即视频采样数据经过编码压缩后，在网络上正常传输的速率（Bitrate）。在同等编码条件下，码率越高，意味着传输的媒体数据量越大，因此在音视频的清晰度和流畅度上会带来更好的播放体验，另一方面，高码率的媒体流将对传输网络的带宽带来更大的压力。
延迟：即一帧视频图像从开始采集到最终播放，期间所花费的时间。延迟越小，意味着视频直播的实时性越高。从上面的直播流程可以看出，视频直播从媒体数据采集到最后渲染播放经历了很多环节，所以影响延迟的因素也很多。
抖动：即视频数据包在传输过程中由于网络拥塞、传输缓存或路由变化导致偏离正常传输延时的现象。媒体传输的抖动问题会影响到播放的连贯性，引起卡顿等不良体验。
关键技术
视频直播的关键技术主要涉及媒体处理和媒体传输两个方面。从视频直播技术应用伊始，针对这两个技术领域展开的一系列的创新研究和优化升级就从未停止。
媒体处理
结合视频直播业务的特点，我们根据直播流程中的不同阶段将媒体处理分为三大类：主播端媒体处理、云端媒体处理和播放端媒体处理。主播端媒体处理又可细分为预处理和编码，而播放端媒体处理又可细分为解码和后处理。
主播端处理
常规的图像增强处理方法在视频预处理环节依然发挥着主流的作用，比如降噪、补偿、平滑、锐化、图像增强（饱和度/对比度）等等。随着视频业务在社会生活中应用场景的不断拓展，一些有趣的媒体应用处理技术也在视频直播场景中逐渐普及开来，比如美颜、瘦脸、换脸、打码、背景虚化/替换、AR/VR 等等。
另一方面，如何提高视频编码压缩效率是业界面临的主要挑战之一。视频编码本质上是一种有损压缩过程。通常情况下，为了获得更低的视频传输码率，编码器需要增大图像编码压缩率，而这势必引起更多视频图像细节的失真和损耗，从而导致视频播放质量的下降。所以，如何在获得更低传输码率的基础上保证足够好的视频播放用户体验，成了图像处理领域研究者和视频引擎技术开发人员需要研究的重要课题。近些年来，人们尝试结合人眼视觉系统（Human Visual System, HVS）对事物感知存在内容偏好的生理特性，将人工智能技术特别是神经网络和深度学习方法引入到了视频图像预处理和编码压缩算法中，并在基于显著性的视频预处理、基于纹理分析和综合的预处理、端到端神经视频编码等研究方向上[2]均取得了一些积极的进展。
网易云信技术团队投入了大量研发资源，致力于 HVS 和 AI 技术相结合的视频图像处理算法和应用的研究工作，而且在图像纹理增强 、显著性检测处理和 JND 感知编码技术等方面的开发已经跨出了卓有成效的一步。该系列技术研究的成果正在逐步应用到云信的直播、点播和 RTC 等业务中，为云信的客户带来更好的播放体验和更高的业务价值。
图5 网易云信视频引擎优化效果
云端处理
除了主播端的媒体处理之外，在很多情况下需要在云端对媒体流做进一步的加工处理，以满足直播业务的特定需求。比如为了输出单路媒体流需要将多路媒体源进行混屏混音、为了支持多种码率或编码格式需要进行转码（转换分辨率、码率或编码格式）等，甚至为了支持一些个性化的需求还要实现添加水印、生成字幕、数据加密等扩展能力。如前所述，这块儿加工处理的工作是由云端的媒体处理服务（MPS）负责实现的。
网易云信搭建了一套全新的 MPS 服务，支持跨区域的分布式弹性部署和媒体源的就近接入，为云信的音视频业务提供了丰富的可定制化的实时媒体处理能力。在不久的将来，我们希望能将这些媒体处理能力进一步开放给外部客户和合作伙伴，提供多种服务接口，以支持云信生态系统上的客户和合作伙伴更好地发展他们的多媒体业务。
网易云信 MPS 设计实现了一个实时的媒体处理流水线模型，如图6所示。该模型封装并打通了媒体流接收、发送、编解码和加工处理等全流程的各个环节，大幅提升了媒体数据收发和处理的效率，并提供了灵活便捷的媒体处理扩展能力。
播放端处理
播放端的视频处理方法包括两大类，即图像增强技术和超分辨率技术（Super Resolution，SR）。这两类图像处理技术的一个显性区别是，图像增强技术不会改变视频图像的分辨率，而超分技术则主要通过算法推理提升图像分辨率的方式，达到优化视觉效果的目的。
基于 AI 的超分技术相比传统的基于差值或重构的计算方法，在超分效果上具有巨大的优势。不过在多媒体实时传输应用领域，AI 超分技术也面临着两大挑战：一方面，网络视频流通常都是经过大幅压缩编码后的媒体数据流，这种有损压缩很容易造成图像纹理细节的失真和画质的严重退化，如果将这类图像直接进行拉伸，压缩损失很容易被放大，因此超分的效果将大打折扣；另一方面， 当今流行的 AI 超分算法，如各种深度卷积神经网络算法，对播放设备的计算能力提出了更高的要求。由于播放设备机型品类繁多、算力良莠不齐，播放端的媒体处理能力和播放实时性都受到了较大的影响。常规的解法是为播放端 SDK 设置一份机型白名单，SDK 只能在指定型号的设备上对媒体数据进行渲染播放前的有限优化处理，而对于算力要求较高的 AI 超分技术，则几乎绝迹于各种智能移动播放设备。
网易云信提出了一个基于编码损失复原的视频超分算法方案，采用数据驱动和网络设计双管齐下的策略，通过数据处理模拟失真场景，从模型设计到工程落地进行了多重优化，对制约 AI 超分技术的两大问题进行了一定的突破，在模型实时性和真实场景超分效果方面均取得了不错的效果。该算法具有模型小、参数少、实时性好等特点，能够适配更多的播放设备。我们通过图8可以直观地对比一下在视频图像细节上的算法优化效果（左图为传统超分方法，右图为网易云信 AI 超分算法）。
媒体传输
如果将媒体处理过程比喻为烹饪一道美食，那么传输技术则是为了把这道美食及时而又安全地派送到观众手中。媒体传输技术涉及到两个细分领域，即传输协议的选型和传输网络的保障。
传输协议
视频直播常见的媒体传输协议规范包括 RTMP、 HTTP+FLV 以及基于 HTTP Adaptive Streaming（HAS）技术的协议，如 Apple HLS、Adobe HDS、MPEG DASH 等。一般而言，RTMP 和 HTTP+FLV 相比 HAS 协议可以获得更低的直播延迟，但是 HAS 协议具备更好的网络自适应能力，可以针对网络可用带宽的实时动态变化选择传输相应码率的媒体流片段。近几年来，HAS 协议设计者们陆续推出了各协议的低延时版本，如 LL-HLS（Low-Latency HLS）[3][4]和 LL-DASH（Low-Latency DASH）[5]，这些改进版本在理想情况下可以将直播的端到端延迟缩短到2秒左右。
从网络协议四层模型来看，以上这些应用层的直播协议都是基于传输层的 TCP 协议实现的。然而，TCP 协议在当今的多媒体通信应用领域存在着诸多缺陷，如建连握手时间长、拥塞控制不灵活、队头阻塞问题严重、抗弱网能力差等等。为了解决 TCP 协议的这些问题，一个全新的运行于用户态的传输层标准协议 QUIC[6]应运而生。QUIC 协议设计了一个基于 UDP 的多路复用且安全可靠的传输机制，为应用程序提供了区别于传统流式传输协议的重要特性：
快速的连接握手。支持 0~1RTT 建立连接
连接多路复用。支持连接内的 multiple streams，避免了队头阻塞问题
连接迁移。通过 Connection ID 绑定连接，解决了 NAT 映射失效和移动设备多网切换等问题
灵活的拥塞控制机制。在用户空间（而不是内核空间）实现，可结合应用场景灵活配置和调优
另一方面，在多媒体数据传输如视频直播的应用场景，选择合适的拥塞控制算法对提升传输效率、降低传输延时尤为重要。Google 公司在2016年提出了一个全新的拥塞控制算法：BBR（Bottleneck Bandwidth and Round-trip time）[7]。相比基于丢包检测的传统拥塞控制算法（如当前 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 等方面带来了大量的收益[8]。
QUIC 协议和 BBR 算法的珠联璧合为业务应用的优化带来了新的选择。网易云信视频直播系统在推流端和拉流端同时集成了对 QUIC 协议和 BBR 算法的支持，在直播活动上下行的第一公里或最后一公里通过 RTMP over QUIC 进行媒体流的传输能够有效地改善媒体数据的传输效率以及抗弱网和抗抖动的能力，进一步提升了视频直播的用户体验。
传输网络
常见的视频直播传输网络环境包括公共互联网（公网）、专线网络、CDN 网络和RTN 网络等。
公网是运营成本最低的传输网络，但是它的缺点也很明显，那就是网络可靠性（带宽、延迟、抖动等）缺乏保障，所以通常被用于直播的最初或最后一公里链路。
使用专线网络可以解决网络可靠性的问题，但是缺点是使用成本较高。
CDN（Content Delivery Network）是一种在互联网中被广泛使用的网络基础设施。在视频直播应用场景中，CDN 可以为直播用户提供廉价的跨区域的大规模的数据分发能力，它的主要问题是传输延迟较大（秒级）且各 CDN 厂商的服务能力参差不齐。
RTN（Realtime Transmission Network），顾名思义，就是设计用于提供实时数据传输能力的大规模分布式网络传输系统。RTN 基于公网基础设施，通过纯软件方式实现，不依赖硬件也不借助专线网络进行优化，而能够将端到端的延迟控制在百毫秒级别。另一方面，为了实现 RTN 实时稳定的数据传输能力，RTN 厂商不仅要投入研发资源进行路线探测、路由调度等各种算法的持续升级调优，也需要在网络节点部署、带宽租用等方面投入大量的资金，其投入成本堪比 CDN。
网易云信自研推出了新一代大规模分布式传输网络，即WE-CAN（Communications Acceleration Network）。WE-CAN是一个架设在公网之上，通过智能链路探测算法和智能路由调度策略将数据从全球任意端点快速、稳定、高效地发送到任意目标端点的多功能实时传输网络系统，如图10所示。
相比传统的 RTN 网络，WE-CAN 的传输速度更快，传输成本更低，适用场景也更加丰富。WE-CAN 不仅能够对 RTC 媒体流进行高到达、低延迟的传输，也能对视频直播流进行大规模、低延迟的分发，还能对信令、即时消息（IM）和其他业务数据进行可靠传输。WE-CAN 的媒体数据传输在全球范围内延迟不超过 250ms，而优质传输率则达到了 99% 以上。
通过集成 WE-CAN 和国内外众多主流的 CDN 厂商，网易云信设计实现了一套基于推流线路智能切换和融合 CDN 智能调度的高可用直播服务框架，如图11所示。
在传输网络上，网易云信直播服务具备以下几个主要特点：
上行推流多线路智能切换。 通过主备推流多条线路的自动识别和切换机制，保障了上行推流的高可用；
下行融合多CDN智能调度。根据实时的 CDN QoS 监控机制进行播放拉流的调度分配，保障了下行拉流的最优解；
端到端的全链路数据安全。除了常规的传输层加密、防盗链和推拉流黑白名单等安全应用，还支持在媒体封装层进行加密，该层加密对媒体传输协议和网络透明，且只有授权的客户端才能进行解密播放；
支持低延时直播应用场景。通过集成 WE-CAN 网络和最后一公里的 WebRTC 技术，可以做到1秒以内的端到端直播延迟；
千万级用户并发在线能力。得益于融合 CDN 解决方案的落地和 WE-CAN 系统的大规模部署节点覆盖，网易云信已经具备了支持千万量级大型直播活动的技术能力。
技术趋势
如同自然界万物生灵周而复始、生生不息地繁衍进化，视频直播技术也在不断地迭代演进发展中。近年来，随着视频直播应用场景的不断拓展和深入，相关技术的研究和应用方向呈现出两个明显的发展趋势，一个是低码高清，另一个是降低延迟。
低码高清
所谓低码高清技术，就是在更低码率的传输条件下为用户呈现出更清晰流畅的视频播放效果。“既要马儿跑得快，又要马儿不吃草”是驱动低码高清技术不断向前发展的永恒的追求。通过低码高清技术的应用实践，视频直播活动可以适配更差的用户网络带宽状况，覆盖更多的观众群体，带来更好的视频播放体验，同时，也能大幅降低企业的媒体数据传输成本。
网易云信在视频图像预处理、视觉感知编码和 AI 超分等低码高清技术领域的研发方面已经迈出了坚实的一步，相关技术成果通过持续的迭代优化正在逐步落地应用到 RTC、直播和点播等业务中来。
降低延迟
在某些特定的视频直播场景中，主播和观众之间除了要推送直播媒体流之外，还需要传递实时的互动信令，如在线抢答、文字互动、抢红包等，这对媒体流的传输延迟提出了更高的要求。传统的直播技术动辄5秒以上的端到端延迟已经无法满足这类场景的互动需求，即便是 LL-HLS 和 LL-DASH 技术想方设法将延迟缩短到最小2秒左右，也难以带来令人满意的用户体验。真正的低延时直播应用需要将端对端的延迟控制在2秒以内，甚至在1秒左右。
业界在降低传输延时技术方向上进行了诸多探索和尝试，引入了 RTN 并应用了一些基于 UDP 的实时数据传输协议，如 QUIC、SRT、RTP 等，如图12所示。目前主流的低延时直播技术，在推流端主要通过 RTMP（或 RTMP over QUIC）进行推流，在云端通过 RTN 网络将媒体流快速分发到各个下行边缘节点，最后利用 RTC 技术将媒体流实时传输到播放端，完成最后一公里的投递。
网易云信在低延时直播技术领域也进行了布局，通过集成 WE-CAN 网络和 NE-RTC 技术，网易云信直播服务可以提供1秒以内的端到端直播延迟能力。
总结展望
我们生活在一个数字化的时代，视频直播技术依然处于信息传播应用普及的黄金赛道，发展前景向好。将来随着新业务应用形态的不断涌现，必将产生新的技术诉求及其应对之道。
网易云信在视频直播技术领域积累了丰富的经验，特别在大型直播高可用解决方案、分布式媒体处理服务、低码高清直播和低延时直播等技术方向逐渐建立起了自身的核心技术竞争力。网易云信将继续顺应技术发展趋势，持续优化打磨媒体处理和传输能力，持续研究创新技术，以更好地助力客户和合作伙伴内生成长、创造更多美好的价值。
作者介绍
郑文彬， 网易云信云平台融合通信技术团队负责人、架构师，在实时多媒体处理和传输技术、网络会议和视频直播系统等技术领域深耕多年。
参考文献
[1] 艾瑞咨询. 2021年中国企业直播服务行业发展研究报告.
[2] Dandan Ding, Zhan Ma, Di Chen, et al. Advances in Video Compression System Using Deep Neural Network: A Review and Case Studies.
[3] APPLE.COM. Enabling Low-Latency HLS. https://developer.apple.com/documentation/http_live_streaming/enabling_low-latency_hls
[4] Roger Pantos. HLS 2nd Edition. https://datatracker.ietf.org/doc/html/draft-pantos-hls-rfc8216bis
[5] DASH-IF. Low-latency Modes for DASH. https://dashif.org/docs/CR-Low-Latency-Live-r8.pdf
[6] Jana Iyengar, Martin Thomson. QUIC: A UDP-Based Multiplexed and Secure Transport. https://datatracker.ietf.org/doc/html/rfc9000
[7] Neal Cardwell, Yuchung Cheng, C. Stephen Gunn, et al. BBR: Congestion-Based Congestion Control. https://dl.acm.org/doi/pdf/10.1145/3012426.3022184
[8] 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
相关阅读推荐
6194
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
