阿里云 GRTN QoS 体系 — 构建实时音视频产品最佳体验

良逸（阿里云视频云团队）

我们简述 3 种典型的实时音视频业务场景，并分析各场景异同。

(1) 音视频通话：疫情的出现使得音视频通话业务得到了广泛的使用和长足的发展。2020 年三季度，Zoom 实现总营收同比增长 367%，公司人数超 10 人的客户同比增长 485%。参会方每个人均可推送音频、视频、屏幕共享流，以及拉取其他人推送的媒体流。音视频通话场景对 QoS 要求极高，端到端语音延时在 300ms 内才能保证良好的用户体验。此外，音频是传达信息的主要媒介，重要性高于视频。

(2) 直播：《天猫双 11 淘宝直播商家数据报告》显示，2020 年商家参与数量增幅超过 220%；双十一期间，淘宝直播 GMV（包括直播直接成交、预售定金、支付尾款金额）增幅超过 100%。在直播场景中，直播间中往往有 1 路主播推送的音频流和 1 路主播视频流，其余人在直播间中拉取音视频流进行收听和观看。

直播场景对 QoS 要求比 RTC 场景略低，传统基于 RTMP 协议的推流延时可能达到5秒甚至更高。然而，直播场景下的一些新型业务模式也对 QoS 提出了新的要求。第一是直播连麦，部分观众会与主播连麦进行实时互动，或者主播之间会连麦互动 PK，这要求连麦具备接近音视频通话场景的延时。第二，在直播电商场景下，降低直播传输延时有助于观众在直播间中实时抢购，形成更好的购物体验和更高的转化率。

(3) 在线教育/娱乐：COVID-19 导致学校大规模停课，在线教育得到广泛青睐。据艾瑞咨询统计测算，2020 年中国在线教育市场规模约 4003.8 亿元，同比增长 24.1%。疫情后在线渗透率将有望进一步提升。在线教育/娱乐场景类似于音视频通话和直播场景的混合。房间中有多位讲师或主持人实时互动，同时有大量观众收听和观看。音视频传输质量将直接决定授课/娱乐体验，乃至最终的产品营收。

从端到端角度来看，GRTN 网络中，移动多媒体传输可以分为 3 个阶段，如图 2 所示。

• 移动传输（上行）：推流端采集音视频，并对之进行前处理和编码，通过 Wi-Fi 或 LTE 等移动网络资源将媒体数据发出。
  
  
• 有线传输：多媒体数据会接入运营商有线网络，到达拥有全球 2800+ 节点的阿里 CDN 网络中，通过有线网络传递到拉流端附近的 CDN 末端节点，直至拉流端接入的基站或 AP。
  
  
• 移动传输（下行）：媒体最终通过 Wi-Fi 或 LTE 等移动网络资源触达拉流端。拉流端获取到音视频流后，会进行解码、渲染并进行播放。
  
  

上述各个阶段的各个环节均有可能对音视频体验带来影响。图 3 以直播场景为例，拆解了端到端音视频传输的各个环节带来的延时。其中，播放侧环节会贡献高达 78% 的延时，主要来自于网络的延时和播放器的缓存。由于上行/下行网络的丢包、拥塞、抖动，音视频帧到达播放端的时间会高于预期，甚至会由于丢包重传、关键帧请求等，导致播放端获取到音视频帧的时间无法估计。播放端必须缓存多帧，确保播放的流畅性。从上述数据中，我们可以看出，我们需要一套移动传输 QoS 框架，在上行/下行移动传输环节对抗弱网，确保用户体验。

传输 QoS 是保障实时音视频服务质量的核心要素，但做起来并不简单。其难点如图 3 所示，比起有线网络，移动信道复杂多变，面临拥塞、Wi-Fi 信道干扰、用户移动、运营商带宽限速等情况，导致丢包（拥塞/随机丢包）、延时（大延时/延时抖动）、缓存模型（大缓存/小缓存）等多种网络状态及其杂糅。传输 QoS 技术必须能够识别和动态适配上述各种网络场景，最优化用户收听观看音视频的体验。

移动链路上存在的弱网场景可以分为丢包、延时抖动、带宽受限、多种弱网混合且频繁变化的动态弱网共四大类。面向不同的弱网类型，我们在 GRTN QoS 中采用不同的技术加以应对。以下将首先概述 GRTN QoS 体系如何对抗各类弱网场景，然后简介部分关键技术。

上图展示了面向四类主要弱网场景，阿里云 GRTN 音视频传输 QoS 的技术体系。我们针对音频、视频两种媒体类型选用并研发了不同技术。其中，在对抗延时抖动方面，我们参考并调整了 WebRTC 原生的音频 NetEQ、视频 Jitter Buffer 和音视频同步技术，这里不重点介绍。

• 音频 RED 冗余：为对抗丢包和大 RTT，我们对于音频采用了类似于 RFC 2198 的 RED 技术，通过大量冗余，确保即使在高达 70% 丢包情况下，对端也能解出绝大部分乃至所有音频报文，避免重传带来的二次延时。在音视频会议场景中，音频作为核心交互媒体类型、重要性较高，因此我们会根据丢包率、RTT 动态计算 RED 的冗余倍数，并为之预留充分带宽。
  
  
• 视频 RSFEC 冗余：视频带宽非常高，我们必须对冗余带宽精打细算。原生的 WebRTC 支持 FlexFEC 和 ULPFEC 两种模式，均基于异或计算生成冗余包，抗丢包能力较差。为兼顾抗丢包能力和低带宽开销，我们采用了 RSFEC 技术。作为一种基于矩阵运算的编码，RSFEC 利用伽罗华域特性，兼顾了确定性抗丢包能力和可接受的带宽开销。
  
  
• 视频长期参考帧 LTR：即使添加 RSFEC 冗余，丢包依旧难以避免，这导致依旧存在拉流端发起 I 帧请求的可能，而庞大的I帧可能会进一步加剧拥塞。为降低 I 帧请求带来的带宽开销，我们采用了长期参考帧 LTR 技术，大幅降低 I 帧大小。
  
  

• 语音：对于一位音视频会议的参会者来说，如果他没有发出任何声音，采用原有的码率发送音频会造成带宽的浪费。我们采用了语音 DTX（Discontinuous Transmission) 技术，在不活跃的语音周期中，大幅降低音频码率，减少带宽占用。此外，在多人会议场景下，同时发声人数超过 5 人时，语音会变得非常嘈杂，且传输大量语音会浪费带宽。因此，我们实现了 Audio Ranking 功能，可以对当前会议中发布者的声音进行排序，选取订阅者订阅的发布端中音量较大的几个流进行转发，从而节省带宽。

  
  

• 视频 SVC+ 抽帧：与上行移动传输阶段不同，下行移动传输阶段无法直接控制视频编码码率。因此，当带宽受限时，我们需要一种方式支持下行视频码率调节。我们采用的方法是在推流端对视频源进行时域 SVC（Scalable Video Coding）分层编码，将视频编为基础层（Base layer，BL）和多个增强层（Enhanced layer，EL）。其中，基础层不依赖增强层进行解码。这使得在下行移动传输阶段，我们可以丢弃增强层的视频帧，从而降低码率。

  
  

• 视频大小流 Simulcast：在实时音视频场景中，往往有多个人订阅同一条流。然而，不同拉流端下行带宽可能差别很大，如质量好的拉流端有 2Mbps，质量差的可能只有 500kbps。在这种情况下，如果推流端按照质量最好的拉流端带宽编码，则质量差的拉流端会遇到频繁卡顿；若按照质量最差的拉流端带宽编码，则质量好的拉流端看到的画质较差。为解决此问题，我们选择了视频大小流 Simulcast技术，要求推流端同时编码并发出多条分辨率、码率不同的流。同时，我们为拉流端的下行带宽进行分档，为不同档位的带宽选择与之最为匹配的分辨率，从而实现不同下行网络质量拉流端之间的带宽隔离。

  
  

• 屏幕共享 SCC 编码：音视频会议中，屏幕共享是常见且重要的场景。但与摄像头采集的视频流（720p 及以下即可）不同，屏幕共享流要求清晰度更高（1080p）。但由于屏幕共享时，画面往往长时间不变（如讲解某页 PPT），所以屏幕共享流编码帧率较低(6fps 即可)，帧间距可能达到 200ms。我们选用了 HEVC-Screen Share Codec（SCC）技术，同时强化 H264 编码器，使之也能对屏幕共享流采用 SCC 的方式编码。SCC 将屏幕共享流大小降低 30%~40%，I 帧大小降低高达 60%，确保在极限带宽受限情况下屏幕共享的可用性。

  
  

• 带宽分配：实时音视频业务中，一个参与方可能会订阅多条音视频流，这些媒体流共享参会方的下行带宽。在带宽受限时，如何将有限的带宽分配给合适的媒体流，是确保用户体验的关键问题。为此，我们研发了场景化的带宽分配机制。根据用户主窗口流类型、是否存在屏幕共享、各音视频流的分辨率和码率，同时结合丢包率、RTT、带宽等网络参数，作出能最优化用户 QoE 的决策，实现在用户静态观看、动态切换窗口、增删订阅关系时，都能快速收敛到最优带宽分配，最大化用户体验。

（3）视频流对抗动态弱网（丢包、RTT、延时抖动等条件的程度和类型频繁切换）

经过多个团队的共同努力，GRTN QoS 效果已经能够对标业界头部竞品。GRTN 不仅服务于阿里内部淘宝直播、音视频会议等场景，也希望能够依托于阿里云 CDN 全球2800+ 节点，将优秀的音视频传输能力输出给外部客户。欢迎感兴趣的人和我们联系！同时，我们也在研究面向 5G、结合机器学习的新型 QoS 体系，进一步提升 GRTN QoS 的场景识别和智能决策能力，也欢迎同行交流讨论。QoS 优化没有止境，我们永远在路上！