解密华为云原生媒体网络如何保障实时音视频服务质量

Posted 2021-05-24 LiveVideoStack_

随着5G和AI的发展，内容表达视频化成为了当今的主流，很多行业对视频分发有非常旺盛的需求。我们非常荣幸地请到了华为云的资深视频架构师黄挺，为大家介绍基于互联网的实时音视频服务所面临的挑战，分享华为云原生媒体网络全方位保障实时音视频服务体验的实践。

文 / 黄挺

整理 / LiveVideoStack

大家好，我是来自华为云的黄挺，目前负责华为云视频架构设计的相关工作。今天我会给大家分享华为云原生媒体网络是如何保障实时音视频服务体验的实践。

我会从以上几个部分进行分享，首先，解释一下我们为什么需要一张媒体网络；其次，会介绍一下华为云原生媒体网络的整体架构设计，最后，会分享我们在如何改善实时音视频体验方面的实践。

#01

为什么需要一张媒体网络

1.1 内容表达视频化，各个行业都有视频分发的需求

为什么我们需要一张媒体网络呢？我主要总结了三大原因。第一个原因，我们看到内容表达视频化是目前一个很明显的趋势，有很多行业都对视频分发有非常旺盛的需求。举一个我亲身经历的小例子，在今年过年的时候，我的家人想把手上带了多年的戒指取下来，因为戴的时间比较久了，手指变粗了不少，取不下来。最开始我们第一反应是去商场找营业员帮忙取下来，后来我抱着试一试的心态，在抖音上搜索“取戒指”三个字。在搜索结果中找到了一个非常简单的办法，视频时间不长，照着做很快就把戒指取下来了，而且对戒指没有损害，手指也不痛。大家感兴趣可以去搜索看看。这其实就是知识内容表达视频化的一个表现，这个趋势在很多领域都已经出现了，除了短视频，比如现在的电商直播，在线教育，云游戏等行业也都出现了内容表达视频化发展趋势。

1.2 新媒体表达形式出现，对音视频技术要求越来越高

第二个原因，我们看到未来会出现很多新的媒体表达形式。比如VR和最近比较火热的自由视角，这些新的表达形式的出现，都会给用户带来更加沉浸式的体验。但它对音视频技术的要求是全方位的提升，主要包括带宽、时延、渲染复杂度等等。可以看到左边这张图，以VR为例，如果带上VR头盔去观看视频，要做到极致的视网膜体验，需要的码率非常大，通过简单的测算大概需要达到2Gbps的码率。而且影响VR体验的因素相较于平面视频也变得更多了：刷新率、视场角、分辨率、MTP低时延、姿态跟踪、眼动跟踪等等。

1.3 互联网对用户没有承诺服务质量

我们一般会从需求侧和供给侧两个维度来进行分析一个产品。前面两个算是需求侧的分析，接下来我们看一下供给侧的分析。实时音视频服务一个非常重要的供给侧就是互联网的基础设施。我们都知道互联网对用户的服务质量基本上是没有承诺的。怎么理解呢？首先，建设互联网的成本非常昂贵，比如，需要在海底拉光缆，这个铺设成本是非常昂贵的，这里包括人力的，物力的，另外一部分是无线频谱的成本，比如3G、4G、5G的频谱。所以互联网的建设一定是需要考虑共享，共享就需要使用复用和交换技术。怎么理解交换呢？看下下面这个简单的示意图。假设我们要建4个网络节点A、B、C、D；如果没有交换，两两互联需要6根线。但是如果使用了交换，则只需要4根线就可以了。所以从成本考虑，需要交换的技术；我们知道交换一般有两类技术，一类是Circuit switching ，另一类是Packet switching，Circuit switching的特点是容量预留，但是资源存在浪费，因为一旦预留，就算没有数据传输，带宽资源也是被占用。而Packet switching技术则是链路资源共享的，所以可以做到更低成本的交换。而当时互联网设计考虑到成本的因素，选择了Packet switching这个技术进行演进；因为选择了Packet switching，再加上best effort尽力而为的转发模式，所以带来了一系列丢包、重复报文、时延、乱序等问题。所以我们总结，丢包、重复、时延、乱序是这一代互联网的固有属性。

这里大家可以思考一个问题，为什么互联网在最开始设计的时候，并没有考虑在网络层解决这个问题。或者换一个更大的问题，如果今天重新设计互联网，我们会怎么做？会不会尝试让互联网去解决这些问题。第二个思考的问题就是，在大家的日常应用开发过程中是怎么解决丢包、重复、时延、乱序的问题。

1.4 对我们的启发

通过前面的分析带给我们一些启发，首先我们认为需要构建一张媒体网络，通过这张网络来弥补供给侧和需求侧之间的鸿沟，供给侧就是互联网的基础设施，需求侧就是飞速发展的音视频业务。第二点：通过这张网络来满足不同行业对音视频分发的旺盛需求。第三点，通过这张网络来应对未来出现的新技术的挑战。

#02

华为云原生媒体网络架构介绍

前面解释了为什么我们需要一张媒体网络。接下来我会介绍一下华为云原生媒体网络架构。

2.1 华为云原生媒体网络

大家可以认为华为云原生媒体网络是云原生视频服务的一个技术底座，基于这张云原生的媒体网络会构建上面一系列从生产到处理到分发到播放的云原生视频服务，比如CDN、直播、RTC等等，通过这些云原生的视频服务来支撑上面千行百业的客户。我们这张云原生媒体网络主要包括7大特点：扁平化、Mesh化、智能化、低时延、灵活性、多样性和端边云协同。

2.2 广覆盖：支持多种接入方式，实现全球互联互通

接下来我会介绍一下华为云原生媒体网络，三个比较重要的架构设计目标。因为我们的服务对象遍布全球，所以首先就要是一张全球部署的网络。这张网络主要解决三大问题：第一就是需要支持多种接入方式，其次是节点的互联互通；第三是要考虑一个高可用设计冗余覆盖。

首先，因为我们是一个paas类服务，所以客户很多，来自不同的行业，以云会议为例，很多客户对云会议的安全性和质量要求非常高，所以他希望能够从他的企业园区通过专线来接入这张网络。但有的客户，希望他的用户能够随时随地的接入这张网络来分发业务，比如一些互联网客户，这个时候就需要支持互联网的接入方式。另外，因为我们大量业务的流量在边缘终结所以国内我们主要通过电信、联通、移动单线接入，节省服务带宽成本；国内通过三线机房或者BGP资源，解决跨运营商网络资源交换的问题；在海外，我们会优先选择网络资源比较丰富的IXP节点接入；通过华为云基础网络设施或者优质的互联网资源实现跨国的互联。另外我们在部署规划的时候就要考虑高可用设计，高可用设计常见的手段是增加冗余，我们在规划的时候考虑了站点冗余和带宽冗余。我们会保证覆盖区域用户至少有3个站点可以提供对应质量要求的服务。另外，我们在做资源规划的时候，会按照业务需要的带宽的2倍以上进行规划，应对部分突发。

2.3 全行业：满足娱乐、通信、行业视频等不同业务要求

因为我们是一个Paas类服务，我们不能因为满足了一类客户的需求，就影响其他客户的特性，而且要尽量快速的满足不同客户的需求。这对技术提出了3个方面的要求：首先因为需要满足不同行业的不同业务需求，所以业务应用开发的敏捷性就非常重要，我们需要让新功能能快速上线到全球任意边缘节点，同时为了降低新特性上线的风险，我们需要支持新特性在不同edge的灰度上线。我们把这种开发方式叫做Living on the edge。

第二个技术要求，也是我们非常重要的设计原则——Edge Services是独立自治的。Edge Services就是我们围绕着媒体网络的网络节点，部署的一系列微服务，我们统称为Edge Services。每个Edge Services都必须是独立自治的，因为我们是一张分布式的媒体网络，肯定不希望某一个节点故障（比如网络故障），就会对我们造成全网业务的影响。所以每个Edge Services必须是独立。什么是自治呢？当边缘和控制中心网络出现一些暂时的故障，那我的架构上一定要保证Edge Services内部能够自治，也就是说它本地的服务还是可以提供的。我们可以看到左边简单列了四个微服务，其中局部调度就是为了减少对全局调度的依赖，当边缘和控制中心网络出现一些暂时的故障，边缘依旧可以提供服务。另外，我们在Edge Services内部的架构主要采用微服务进行划分。它的核心目的是帮助我们能够快速灵活的上线一些特性，例如我们在edge service内部有协议适配的微服务，这样当我们需要支持新的终端，适配一些协议的时候，可以快速上线一个新协议的适配微服务，这样可以快速上线，而且不会影响已经上线的终端的支持。

第三个技术要求是Overlay网络需要能够灵活的定义它的路由。举个例子，例如华为云会议，它需要支持大量高规格的政府级会议，而这个对安全性和质量要求就非常高，我们需要让进入我们媒体网络的这张会议的所有报文都走我们华为云的骨干网，避免使用互联网资源传输。还有一些客户对价格比较敏感，对于这类客户我们就会尽量使用性价比较高的网络资源来转发他的报文。这就需要有一个可编程的overlay网络实现灵活的网络路由和转发。

2.4 全流程：提供媒体生产、处理、分发、播放全流程服务

第三个比较重要的设计目标是，我们的架构需要能够提供端到端的，从生产到处理到分发到播放的全流程服务。我们把客户主要分为两类，一类是云原生，很多互联网客户，在诞生之初，就是在云上的，所以可以很方便的使用我们的云上服务。但是有些客户，需要从传统的线下转型到线上，为了服务于这样的客户，我们的生产和处理系统是基于华为统一的Huawei Cloud Stack统一技术栈，支持在线上线下灵活、快速部署，同时我们还提供了方便的SDK，它能够跨终端、低功耗的来帮助客户覆盖更多的终端。最后一个技术要求是整个实时媒体处理流水线是能够做到灵活编排，动态管理的。举个例子，我们去年和斗鱼联合创新的项目，帮助斗鱼把在端侧的特效算法上移到了Edge services。这样直接给斗鱼带来了三个好处，第一个好处是开发工作量变少了，原来的特效算法需要适配不同的终端，不同的芯片。第二个好处是特效算法的迭代速度变快了，只需要把特效算法在Edge services更新部署，客户就能够体验到。第三好处是覆盖的终端机型变多了，因为传统在端侧去开发的特效，其实有很多低端机是没法体验到的，如果把它放在我们的Edge services上，就可以快速去满足很多低端机型的要求。

2.5 架构分层设计：适应互联网的特征

最后分享一下我们一个非常重要的的架构分层的设计思想。我们借鉴了计算机网络系统的设计思想。可以想象一下，如果没有现在这套计算机网络分层系统，我们的应用开发是怎样的体验。可能我需要去list整个网络拓扑的节点，需要去寻找最优的路径，把我的消息从a发到目的地b，在这个过程中还要去处理各种网络的异常，比如丢包、重传、乱序等等，这显然是对应用开发非常不友好的。

计算机网络系统设计就是解决这些问题。首先就是layering分层的思想，底层有链路层，屏蔽不同链路传输技术的差异性，比如我们支持5G之后上层的应用是不用修改的。在往上就是网络层，它主要有2大功能，转发和路由，所以不需要每个应用自己去定义转发路径。在往上是End to End layer。这是对上面传输层、表达层。应用层的一个统称。而分层的目的就是模块化，降低耦合度，每一层聚焦解决每一层的问题。

而我们云原生媒体网络架构分层也是借鉴了这个思想，我们在网络层进行增强设计，改善报文转发的时延和到达率。我们通过在End to End layer的自研实时传输协议来让上层的实时音视频应用开发更加简单。这样我们的应用开发就可以更加聚焦业务逻辑。同时我们抽象出媒体处理模块，这样音视频相关的编解码技术，前后处理技术，就可以独立演进，快速创新。

2.6 架构分层设计-Network Layer

在介绍我们在网络层和End to End layer的一些关键设计之前，首先来看一下网络层有什么问题。互联网在设计之初有一个非常重要的质量属性，就是互联互通的高可用性，我们知道互联网是由上万个ISP组成的，任何一个ISP故障，网络还是可以正常的通信。其中BGP协议就是一个非常重要的设计，他主要考虑了联通性，但是并没有去做一些服务质量的感知。我们可以看到左边这个图，用户A要发一个消息给用户B，跨运营商，它很有可能会经过互联网穿越很多个不同的ISP，这就会带来很多问题，比如会加重丢包重传，而且这些关键问题很多是非技术因素，比如很多运营商针对某一个网络的网络策略不一定是质量最优，它可能是成本最优，比如有一些冷土豆或热土豆的路由策略。

第二个原因，有可能运营商今天晚上要做一个设备升级，需要运维人员操作一些配置变更，而配置变更过程中有可能出现人为出错造成链路故障，还有可能就是这些区域有一个热门事件，可能会造成拥塞。

为了解决这个问题，我们决定对网络层进行增强，这里我们主要有2个技术手段；一个是underlay，一个是overlay。

1）首先是underlay，我们通过华为云全球网络基础设施，改善网络的接入和互联质量，一旦进入我们的underlay网络就可以避免和互联网其他流量竞争带宽，既改善了质量，又保障了安全性。

2）其次是overlay部分，我们除了自建骨干网，还会部署一些overlay的节点，实现基于不同Qos目标优化报文传输路径和高效转发，而不是让报文任意转发。我们在网络层的设计原则也是非常经典的控制面与数据面分离的设计思想，简单来说，控制面负责路由，控制整个网络的运行，数据面负责转发。

我们为了让数据转发能够更加简单，也采用了网络中非常经典的一个设计思想：源路由算法的思想，核心目的也是为了降低转发设备的复杂度。具体来说，就是当一个报文进入我们网路的第一转发节点的时候，系统就会把报文要经过的所有转发节点信息，包括目的节点都封装在报文头中，这样每个转发节点收到报文后，只需要解析报文头，就知道下一跳要发送到哪里，这样可以大大降低转发设备的复杂度。

另外还有1个非常重要的设计原则，就是我们对网络层不做可靠性承诺要求，虽然我们不保障可靠性，但是我们依旧会利用冗余纠错、多路径传输等技术改善报文转发的时延和到达率。这也是我们为什么把这层叫做网络层的原因，他依旧关注的是路由和转发。只是做了一些增强。

2.7 架构分层设计-End to End layer

网络层的增强能够帮助我们去实现更低时延的转发以及更高的到达率。再往上是我们的End to End layer，这里大家可以先思考一个问题，前文提到互联网有这么多固有属性，丢包，乱序，重传，看上去对开发者非常不友好。但是互联网的发展却非常的繁荣，有一代代互联网的应用email、web、IM、audio、video各类业务出现，这又是什么原因？

这里分享下我的思考，非常重要的一点就是协议，在End to End Layer出现了很多重要的协议，大大降低了我们应用开发者的技术的门槛，比如我们从TCP到HTTP到QUIC等，每一代的互联网的应用发展背后都有一个协议的出现。End to End layer核心设计目标就是要定义一个好的协议和开发框架，让应用开发变得简单。

怎么做到这一点呢？可以看到左边这个图，中间部分是我们的自研实时传输协议大致的功能图，我们会在它的北向提供一个统一的接口。通过这一套北向接口可以让我们既能够开发实时音视频业务，又能开发可靠的消息类的业务，同时我们再看一下它的南向，通过协议栈屏蔽了底层使用UDP或是ADNP协议的差异性，这样应用开发也会变得更加简单。

协议栈设计的目的是为了让应用开发变得简单。所以我们还抽象了两个模块，NQE和QOS，通过这两个模块提供回调的方法把网络的信息能够快速反馈给上层应用，比如编码模块。编码模块就可以快速的自适应网络的条件，来调整它的编码参数。

另外一个非常重要的设计原则就是高效。因为我们知道，前面提到了在未来有很多的端是IoT端，IoT端有一个很大的特性，就是对功耗的要求非常高，我们希望在协议栈设计之初就要考虑这个问题。所以我们不希望轻易的在这一层去增加额外的一些没必要的拷贝，这里遵循的是ALF的设计原则，这个原则也是非常经典的。RTP当时设计的时候也是遵循了这个设计原则。

另外，我们的协议栈设计也参考了quic的设计思想。支持多路复用、网络多路径、华为LinkTurbo、优先级管理等功能。这里分享一下我们的一个小经验，就是在开发自由视角和VR这类业务，对带宽的要求非常高，这个时候我们就会开启多路径的功能，可以获得比较大的体验上的改进。

2.8 华为云原生媒体网络目标架构

最后我对整个媒体网络的目标架构做一个简单的总结。

1）简单来讲就是把复杂问题简单化，分而治之，通过分层的设计来让每一层能够相互解耦，快速演进；

2）每一个Edge services都是独立自治的，来提高整个服务的可用性；

3）通过把Edge services按照微服务进行划分，能够让到我们更加灵活的去适应客户的需求，实现按照微服务级别的快速上线。

#03

实时音视频服务质量保障实践

第三部分我会分享一下我们在实时音视频服务质量保障上的一些实践，这里主要是一些算法设计上的思考，前文主要是架构上的一些思考。

3.1 视频、音频、网络是影响体验的关键系统因素

如上图所示，我们做了一个影响体验的相关维度的分析。从客观指标到主观指标，再到QoE的关系做了一个简单的映射图。我们通过分析，发现影响实时音视频服务体验质量核心的三个系统性因素是视频，音频和网络，接下来我就分别针对这三部分的算法实践进行介绍。

3.2 视频编码技术

首先我们来看一下视频编码。我们把视频编码技术按照设计目标进行了一个简单的分类，第一类，它的设计目标是如何科学的减少视频编码的冗余，降低编码失真对人眼主观感受造成影响。因为我们的实时音视频业务还是主要面向人的，所以有一些非常经典的优化思路，比如：从人出发，分析人眼的视觉特点，基于这些特点来优化编码算法，图中简单列了几大类和编码相关度比较高的人眼视觉特点。

还有一种优化思路，就是从源出发，也就是从内容出发，我们会分析不同场景内容的特点优化编码算法，比如计算机生成图像的特点有低噪、大平坦区域等等。

第二个设计目标是如何科学的增加冗余来抵抗弱网传输对人员主观感知的影响。这边简单列了几类增加冗余的编码，比如极端的全I帧编码、帧内刷新的模式以及长期参考帧和SVC编码。在一些空间视频的业务里面，我们为了改善在空间定位的时延，会使用一些全I帧编码结合一些普通编码来使用，减少空间定位的时延。我们在云游戏里为了减少大I帧的突发，会采用帧内刷新的编码方式。在实时音视频服务中，长期参考帧和SVC是比较常见的编码方式。

3.3 PVC感知编码

下面介绍一下我们具体的一些编码技术。我们云视频团队联合华为2012中央媒体技术院，从分析人眼视觉系统出发，改进了PVC感知编码算法。我们的算法经历了几轮迭代。最新的感知编码2.0算法实现了1Mbps码率提供了1080P 30帧高清画质的体验；算法的主要改进思路是：首先通过预分析和编码反馈信息，对场景和区域进行区分，实时通话场景主要的高敏感区域包括：人脸区域和静态区域。针对不同场景和区域，采用不同的编码参数和码率分配策略，例如非高敏感区域分配较低的码率；2.0算法在1.0的基础上，我们在码控方面加入了AI的技术，相较于之前，固定的码率和分辨率组合，新的方法，我们基于AI的感知码控，获取不同场景下最优的码率和分辨率组合，达到低带宽下更优的主观效果。

3.4 SCC编码

第二编码技术是SCC编码，它主要应用于计算机生成图像的编码，比如在教育或者会议里的屏幕共享场景，我们的算法相较于x265 ultrafast档位，它编码的压缩性能提升了65%，在相同的计算资源的情况下，我们的编码速度提升了50%。针对屏幕共享的场景，我们也解决了它特有的一些问题。在共享的时候，经常会共享一些图文，比如word或者ppt。这一类相对是比较静止的，这个时候编码参数一般会采用低帧率，尽量保证它画质的编码方式，但很多时候共享图文之后会切换到共享视频。如果不能很好的去感知这一点，我们观看视频的体验就是不连续的画面，类似于gif。

为了解决这一问题，我们采用了基于视频时空域的复杂度分析，来自适应视频编码帧率的办法。这样在静态的图文画面下能够有一个高品质的图像，切换到视频共享时，也能够保证流畅性。

我们解决的第二个问题是从YUV444下采样到YUV420场景带来的色彩度的失真问题，因为我们知道很多时候屏幕共享静态的图文，对色彩度的要求是比较高的。但是把它从YUV444下采样到YUV420的时候，UV域的信号会出现很大的衰减，左图是没有使用新算法之前的效果，右图是应用了新算法之后的效果，明显可以看到右图字体会更加清晰，色彩度的失真会更加小，这里的核心是使用了低复杂度色彩校正的算法。

3.5 自适应长期参考帧编码

前面两个编码技术是降冗余，而自适应长期参考帧编码技术是科学的提升冗余。为了更好的理解，我们先把复杂问题简单化，理解一下什么是固定长期参考帧，我们看到左边上面的图，红色的是I帧，绿色是长期参考帧，蓝色是正常的P帧。通过这样的一个参考帧的方式，打断了原来正常的Ipppp前向参考的依赖关系，这样当它的P2或者P3丢失的时候，后面P5的解码是不会受影响的，还是可以继续解码，这就会改善它的流畅性。但是还是有不足的，比如这种绿色的长期参考帧P5丢失了，因为之后的P帧都依赖它，所以都无法解码。第二个问题就是固定，因为长参考帧的关系，它会带来一定的冗余，就会导致相同带宽下的质量会有所下降，所以我们希望在网络好的时候，能够尽量让冗余变小一点，来改善画质，所以我们就提出了自适应长期参考帧的办法。

自适应长期参考帧的核心思路就是两点，第一个是增加反馈机制，在解码端增加一个反馈机制，告诉编码端这个长期参考帧我收到了，编码端知道这个帧收到之后，后面就参考这帧进行编码。第二个是增加一个动态mark长期参考帧的机制，也就是我会根据网络的QOS情况去动态优化长期参考帧编码的步长，在网络好的时候步长调短一点，网络差的时候调长一点。

但是在增加反馈机制之后会带来一个问题，当在一些网络模型RTT比较长的时候，我的反馈周期会比较长。而且反馈报文还可能会丢失，需要再次反馈，这样就会导致长期参考帧的步长变得非常长，一旦步长变长之后，它的编码质量就会进行下降，甚至会下降到业务无法接受的地步，在我们优化算法的时候也考虑到这一点，当长期参考帧的步长太长，我们会强制P帧去参考离它最近的长期参考帧，而不会完全去依靠反馈机制。这样做会带来两个比较好的优化效果，一个是在突发丢包场景下它的画面流畅性变好了，同时它有一个比较好的网络自适应的能力，能够兼顾流畅性和画质。

3.6 网络传输技术：求互动性与质量的最优解

前面是视频编码技术的一些分享，接下来看一下我们在网络传输上的实践。我们对网络传输的定义，核心目标就是要求互动性和质量的最优解。我们知道网络传输技术，主要抵抗丢包，抵抗时延，抵抗抖动。常见的技术比如ARQ、FEC、不对等保护，还有抖动估计、缓存伸缩等等，除了做到抗抖动抗丢包，还需要有拥塞控制，拥塞控制的核心目的就是让 “发送速率”尽可能去逼近“可用速率“，同时尽可能保持低延迟，如果发送速率和网络可用带宽不匹配，会造成丢包、抖动或者带宽利用率低。还有一个非常重要的就是信源信道联动，我们前面看到的动态长期参考帧就是通过信道的信息动态调整编码参数的一种实现方式，基于这个联动，才能够更好的去改善我们的体验。

3.7 基于强化学习，提升带宽预测精度，改进QoE体验质量

无论是拥塞控制，还是信源信道联动，在这个过程中带宽预测的算法都是非常重要的。传统的做法是利用人工的经验，通过一些决策树算法，针对不同网络模型下的带宽做一些预测，但是在复杂场景下，这种做法的效果不是特别理想，所以我们希望通过强化学习的方式来改进这一点。

主要思路是基于接收端反馈的网络QoS，主要反馈四个信息：接收速率、发送速率、丢包率和时延抖动，基于这些信息，通过强化学习的方法来提高带宽的预测准确率。算法优化后，我们的高清占比得到了30%的提升，卡顿率下降了20%。

3.8 音频3A技术：改善音频清晰度

最后我会分享一下在音频方面的技术实践。好的3A算法对于语音清晰度体验至关重要。我们把AI技术应用到3A算法中来改善语音的体验。

首先，我们把AI应用在回声消除上，回声消除是整个3A里非常重要的一个步骤。传统算法在稳态的环境下做的回声消除，已经比较成熟，一般都处理的比较好，但是当环境出现一些变化，比如我拿着手机免提打电话，在家里，从房间走到阳台，这个时候环境出现了变化，回声消除就会遇到很多挑战，通过AI的方式能够比较好的处理这些问题。特别是针对双讲的场景，我们新的算法很好的解决了漏回声和丢字的问题。

其次就是降噪，传统的噪声，比如像风扇、空调这种稳态的噪声，相对来说比较好抑制，而我们基于AI的降噪算法不仅能较好的处理平稳噪声，在应对例如键盘、鼠标敲击的声音或者是喝水、咳嗽这种突发的噪声的场景下，我们也可以快速的进行噪声抑制。

另外一个3A中比较重要的环节就是自动增益，在通话场景下，自动增益主要是通过基于对人声的识别来进行增益。这个时候，对人声的检测VAD是非常重要的，这一块我们也是通过AI的技术来提升了人声检测的精确度，改善自动增益的效果。

3.9 音频丢包恢复技术：降低丢包对音频体验的影响

另一个和视频技术有些差异的是音频的丢包恢复的技术，左边这个图也是一个比较经典的丢包恢复的技术地图，它主要分为两类，一类是基于主动的丢包恢复，一类是基于被动的丢包恢复。

主动丢包恢复技术主要包括常见的FEC、ARQ等。被动恢复主要有三种方法，插值法，插入法还有重新生成法。算法优化思路和视频一样，都是从研究人出发，视频是研究人眼到视觉特点，那么音频是研究人的发声机制，基频的信息一定程度反映了声带的振动频率情况。而包络的信息，则一定程度反映了嘴型的情况，基于这两个信息结合AI的声码器技术可以做到100毫秒左右的音频报文丢失的恢复水平。我们知道一个中文字的发声一般是150毫秒到200毫秒，传统的PLC基于信号的恢复方式，一般可以做到50ms音频信号的恢复，现在我们基于AI的方式是可以做到100ms音频信号的恢复。

3.10 案例1：华为畅连，全球首款全场景音视频通话产品

最后分享两个案例。我们的产品不仅要服务外部客户，也要对内支撑华为很多其他的产品服务。我一直开玩笑说，支持内部客户其实是更难的，而且比支持内部客户更难的是支持华为的内部客户，他们的要求是非常高的，现在我们支持了华为手机的畅连服务，畅连是全球首款全场景（除了支持手机，还会支持华为的大屏、华为的平板、华为的笔记本、手表、手环的通信）的实时音视频通话类产品，我们帮助畅连实现了在1Mbps码率条件下，提供高品质1080p30帧的通话效果。

3.11 案例2：网络研讨会：会议+直播融合体验，开大会更简单

比支持一个华为内部客户更难的是支持两个。我们支持的第二个内部客户就是华为云会议，华为云会议的网络研讨会的场景也是基于我们的实时音视频服务开发的，我们现在可以做到的单场网络研讨会同时支持三千方的观众，其中有一百方是互动的，在今年下半年我们的云会议产品会做到单场网络研讨会同时支持一万方的观众，五百方互动。

#04

总结

最后我对今天分享的内容做一个总结。首先，我们可以明显的看到视频业务正在驱动整个互联网技术发展，包括音视频编码/传输技术，以及边缘计算和边缘网络等技术。所以我们需要一个服务或者系统来弥补互联网基础设施（供给侧）和快速发展的视频业务（需求侧）之间的鸿沟。

第二点，今天的分享仅仅只是开始，随着实时音视频技术应用场景的增加，数据的驱动，会使得我们的云原生媒体网络架构和各类算法持续优化。

最后，希望华为云原生视频服务能够和大家一起，携手走进视频“新时代”。

谢谢大家。

The cover from Pexels.

讲师招募 LiveVideoStackCon 2021 北京站

LiveVideoStackCon 2021 北京站（9月3-4日）正在面向社会公开招募讲师，欢迎通过 [e-mail] 提交个人及议题资料，无论你的公司大小，title高低，老鸟还是菜鸟，只要你的内容对技术人有帮助，其他都是次要的，我们将会在24小时内给予反馈。