# Editorial Note #

视频引擎的应用场景多为需要低延迟的实时通讯场景，比如视频会议和娱乐直播。本次分享我们邀请到了网易云信的工程师韩庆瑞老师，为我们分享网易云信视频引擎技术的特点和落地方案。

文 / 韩庆瑞

整理 / LiveVideoStack

大家好，我是来自网易云信的工程师，我叫韩庆瑞。本次我分享的主题是网易云信视频引擎技术介绍。

本次分享主要分为以下三个部分，第一个部分是网易云信的视频引擎介绍，第二部分是视频引擎的相关关键技术介绍，第三部分是视频云信客户的相关落地案例。

#1. 云信视频引擎介绍

首先我们进入第一部分，网易云信的视频引擎介绍。

首先我想介绍一下视频引擎的应用场景。云信的视频引擎主要用于实时视频通讯场景，比如：视频会议，互动直播，互动教学，在线医疗等等。这些场景都有一个共同的特点就是低延时。

然后这张图是云信视频引擎服务的整个的一个网络部署图。然后云信视频引擎主要是位于一个端侧 ，包括各类的PC、MAC，各种的手机和pad上面。

这是视频引擎的架构图。从图上可以看出云信的视频引擎主要有六大板块。我们按照rtc的处理链路来介绍，第一个模块是视频前处理，第二个模块是视频的编码压缩，第三个模块是用于应对各种网络的视频QoE，然后是视频解码和视频后处理。为了保证云信视频业务的高效运行，我们还有一个视频控制类的模块。后面我会逐个给大家讲解每个模块一些关键的技术。

#2. 云信视频引擎关键技术

好，然后我们进入第二部分。这个部分里面我们给大家详细介绍一下在云信视频引擎内部各个模块的一些关键技术。

首先在视频采集之后我们首先会进行视频前处理， 然后云信的视频前处理的目的主要两个，一是提升实时通信中端到端的视频效果，第二是指导编码器更高效的压缩。目前的话我们视频引擎前处理主要是有三个技术点，第一个是视频降噪，第二个是视频AI增强，第三个是视频的显著性检测。

那么我们首先来看一下视频的AI增强。视频增强这个技术已经有多年的研究和应用的历史，但是实际上它用于RTC场景还有一些难点。比如说在一些RTC场景移动端，移动端居多，而且各种手机类型性能参差不齐，功耗敏感。所以说不能使用过于复杂的算法，对于深度学习来说的话它可能就只有采用小模型。但是采用小模型它的学习能力比较差，训练容易过拟合。这个就是第一个缺点。第二个缺点就是说在前端做增强的话，它的端到端的效果不一定好，因为增强后的图像，它的高频分量会增多，这样对后面视频编码压缩会有比较大的压力，如果处理不好视频质量会损失更大，尤其是在低码率下面整个损失会更大。比如我们可以看到右边这两个图，左边这个图它是没有增强的，右边这个图实际上是做了增强的，然后这两张图是在经过增强然后压缩到最终解码，最后这样的效果。可以看到增强之后，它的块效应其实是比没有增强的要明显一些的。

针对前面提到的困难，云信这里的解决方案是：我们设计了一个分级的网络，这个网络前面是有一个场景识别的模块，它能够识别出视频类型，根据不同的类型它能够走不同的小模型，或者说模型结构不一样或者说模型的参数不一样。然后针对前面提到的第二个困难，就是说有时增强之后的效果反而比不增强的效果编码之后视频质量要差，这个我们也可以通过场景识别的模块识别，对于这种场景的视频我们可以不经过场景增强，直接编码。然后我们的每个小模型他都是一个轻量级的模型。这个轻量级的模型呢大概参数量1k到2k，然后网络层数是八层。这个参数量和网络层数对于业界来说的话可能不算一个轻量级，因为业界轻量级可能只到几百个参数也是有可能的。但是我们为什么不用更小的模型？因为用更小的模型的话它会带来一个质量上的下降。但是参数量1-2k的模型的话，它的缺点是它的开销会大大增加。那么我们为什么有信心用1-2k参数而不担心它的开销，是因为我们有自研的高效的AI引擎，这个我们后面会介绍。

这个是我们AI增强的一个效果的展示，大家可以看一下。右边是我们的增强效果，其实从图上可以看出来右边在左边增强之后它的效果是很有改善的。这个视频是通过编码解码之后的对端解码之后显示的效果。

然后我想介绍第二个技术点是我们的视频降噪。视频降噪应该说在RTC场景里面是一个很常见的技术点。它的作用主要是在经过一些采集之后，高频噪声会消耗不必要的bit，通过降噪我们可以有用于编码器将bit用于编码有用的信息，从而提升端到端的视频质量。但是在RTC里面，降噪也是有很多难点的。

第一个当然也是通用的，就是我们RTC移动端居多，各种类型的pad和手机类型层次不齐，而且对于性能功耗特别敏感，复杂的算法无法使用，而一些速度快的算法效果不够好。第二个困难点是不合适的降噪，可能会在降噪同时滤除掉有用的边缘信息，导致整个的E2E的效果下降。

针对这两个难点，云信这里的解决方案是：我们的降噪分为以下的三个模块：首先也是比较常用的是噪声估计模块，我们会估计这个图像的噪声，当然可能噪声估计的特点是一个非常轻量非常快速的噪声估计。轻量噪声估计有一个坏处就是它可能噪声估计得不准。这个时候我们还有一个显著性检测模块。显著性检测可以检测出人眼最敏感的区域，它可以将图像中人眼敏感的区域进行分级，那么这样子对于人眼敏感的区域我们可能说降噪的尺度会小一点，而在人眼不敏感的区域我们会对降噪的系数和降噪的尺度大一点。因为人眼不敏感区域即使是说我们开大降噪尺度，把有些有用的信息模糊了，但是由于人眼不敏感，所以对整个主观的质量也是没有太大影响的。所以说我们用噪声估计和显著性检测这两个作为两个权重，然后送到各向异性的滤波里面去，得到出我们的图像。

所以我们第一个模块呢是视频前处理，完了之后它会进入第二个模块，也就是视频编码这个模块。视频编码在RTC里面主要作用就是它会把码进行高效的压缩，然后通过网络传输。云信的视频编码的一个特点就是我们的编码速度特别快，同时压缩质量特别高。云信视频编码主要有以下四个编码器组成，最主要的是我们自研的H264编码器，我们叫NE264，然后还有是我们自研的NE265和云信的私有编码协议NEVC，同时针对屏幕共享这个场景，在264这个场景下面我们针对屏幕共享这个场景进行了单独的优化，这个我们叫NE264-CC。

下面我们先介绍一下我们的NE264。NE264是云信自研的H264编码器。在其中我们自研了多个高效压缩算法，比如说快速模式决策，高效亚像素搜索，自适应参考帧，还有CBR码控等等。如下的表格是NE264和业界比较知名的几款编码器的比较，包括webrtc自带的编码器openh264，X264编码器的superfast档位，还有是苹果iPhone 11的编码器。从这个表里我们可以看出，我们的编码器编码质量和速度都是优于这几款编码器的，同时我们的码率波动性，码率控制这方面也是高于这几款编码器的。因为在实时传输网络中，尤其在弱网的情况下，码率波动性会对整个视频的质量会造成较大的影响。

然后我们也和x264-ultrafast，也就是x264里面最快的那个档位进行了一个比较。在这个比较里面我们可以看到我们的速度仅比ultrafast的慢了百分之二十五左右，它是 468fps，我们是350fps。但是我们的压缩率整整提升了接近百分之五十（49.85%，接近百分之五十）。

这就是我们的NE264。然后针对屏幕内容场景，我们用NE264针对屏幕内容进行了单独的优化。关于屏幕内容编码业界有若干种的解决方案，比如说有AV1，H265 SCC。还有一些业界的厂商是采用了SCC相关的一些编码方式移植到H264这样子的一些私有协议。这些都是很棒的方案。云信对于这块的思考是，针对屏幕内容场景，即使在编码端也是有很大的优化空间，配合文字的后处理完全可以达到很好的效果。同时用 H264是使用最广泛的协议，能保证各个设备的互联互通；H264速度很快，不会消耗过多的资源。所以我们用 H264 标准协议针对屏幕场景来进行了一个单独优化。下面是我们的优化结果，我们可以看到相对于不加屏幕内容优化的NE264 ，我们的压缩率平均提升了 36.72%。最大可以提升 62%，同时我们的速度仅减慢3% -- 基本上没有减慢。而如果我们相对于 webrtc内置的openh264屏幕压缩来说的话，我们的压缩率提升了41%左右，而速度基本不变。这就可以看到，我们没有添加任何新的压缩工具，仅通过对 H264 协议的编码优化，我们就能够做到压缩率提升40%，同时速度基本不变。

下面介绍一下我们自研的 NE265。NE265是云信自研的 H.265编码器。针对H.265压缩率高但协议复杂的特点，我们在三个方向做了努力，一是设计了高效的编码器架构，NE265的软件架构对cache极为友好。二是高效的快速算法设计，我们设计和实现了超过 20种的快速算法，三是底层的汇编优化，对密集型计算的模块，我们都使用了simd指令进行了非常精细的优化。下面一些测试结果反映了我们的努力。比如首先是我们和x265 veryslow档位对比。x265 veryslow档位是x265里面编码质量最好的档位。但我们相对这个档位来说，在 RTC 场景下面，我们的PSNR和SSIM的BDRATE都是相差不多的，我们大家可以看到。我们采用的测试序列是官方提供的 25 个标准序列，再加上我们云信业务的一些序列，还有就是社交娱乐场景相关的一些序列，都是从业务相关的一些序列。总共55 个视频。我们可以看到基本上在BDRATE上面我们是相差不多的，相差不到百分之一，但是我们的速度相对于x265 veryslow档位来说 提升了40 倍。然后我们也和H.264 进行了比较，我们和 x264 的faster档位进行了比较，我们的平均压缩率可以提升接近35%，同时我们还比它的速度快10%。

当然云信的努力不止于此，我们还研发了自己私有的编码协议，称之为NEVC。这个协议的一个核心点是采用了云信自研的多尺度的视频压缩技术，当然同时我们也借鉴了AV-1的一些压缩工具。相对于NE265来说我们的平均压缩率可以提升12%，其中在官方序列下面我们可以接近18%的提升，同时我们的速度是和NE265是差不多的。

说完视频编码，我们进入视频QoE的环节。因为视频引擎是RTC业务，视频编码之后的数据它会经过网络传输到视频解码。但是网络的状况是千变万化的，有的网络好，有的网络差，有的网络带宽低，有的网络丢包多。视频QoE模块就是保证我们在任何网络情况下面的用户都有一个最佳的视频体验。我们视频体验实际上就是从视频流畅度，画面清晰度还有质量平稳度这些视频内容这几个维度的综合评分。视频QoE的第二个作用就是它减少因为数据丢失而引起的卡顿。

这里面我想介绍一下云信自研的智能网络自适应技术。讲之前我首先要提一下Netflix的Per-Title技术。Per-Title技术指出了对于视频并不是码率和分辨率越高越好，当码率或分辨率增加到达一定的阈值时，再增加并不能提升视频的主观效果；而不同场景的视频的阈值是不一样的；Netflix通过对视频进行离线学习找到了每个视频对应的最佳码率和最佳分辨率。云信扩展了这个技术，使之可以用于RTC场景。

我们通过深度学习对视频进行分类。首先我们会制作数据集，对数据集中的每个视频我们都会用不同的码率和分辨率进行编码然后通过视频质量评价算法进行打分，找到最佳的码率和分辨率，生成标签；利用数据集训练分类器。然后在实际应用的时候对每一个输入图像我们都会送入这个分类器里面，通过分类器我们选择一个最佳的分辨率，然后将码率和分辨率然后和当前这个视频一起送入编码器进行编码。编码之后传到网络，网络之后再通过解码，解码之后再通过上采样。这样，我们能够实时根据网络的变化来寻找一个最佳的视频分辨率，来获得最佳的用户视频体验。

我们的视频QoE也有长参考帧和时域SVC的技术。当然这两个技术可能大家都是应该是比较熟悉的。在云信，长参考帧主要用于1vs1 的这样一个场景下面的保护，时域SVC主要适用于在一对多情况下面下行的这样一个数据保护。

QoE模块之后我们会进入一个视频解码。云信的视频解码特点是：他可以支持市面上几乎所有视频格式包括视频和图像格式的解码和互联互通。

视频解码之后我们进行到视频后处理。因为云信的业务场景主要可以分为两类：一类是使用camera的场景，比如视频通讯，另一类是屏幕内容分享这样的场景，所以我们的视频后处理一个是对于camera图像的视频超分，另一个是针对屏幕内容的视频屏幕优化这两个技术。云信视频引擎后处理目的主要是恢复或改善视频的画质。

我们先介绍视频超分，同样的在视频超分里面我们是用了自研的轻量级网络。当然这里的轻量是要加引号的，因为我们参数量是1k到2k，网络层数实际上也是8层，对于业界来说可能不算是轻量。但是我们有自研的AI推理引擎，然后我们有独有的数据集处理技术，我们对数据集会有我们自研的一些预处理技术。这样在同样的网络下面通过对这些数据集的预处理，我们的超分效果也会更明显。右图是我们超分之后的这样一个CPU占用率，可以看到无论是安卓，mac还是Windows，我们的超分开销比不开启超分CPU增长率都不是很大，基本上也在5%以内。然后我们还可以看到就是我们视频的客观质量。AI超分的话我们的视频质量比不开启超分明显要好的。

这是一个我们视频超分的对比图。右边是有视频超分的，左边是没有视频超分的。大家可以看到实际上右边的视频质量是明显要比左边好的。

进入下一个，桌面共享优化。桌面共享优化的话在RTC的主要挑战是，桌面共享大部分是一个大屏幕，以1920x1080的居多，深度学习来做的话开销过大。那我们解决问题的思路是首先会对有文字的区域做文字识别，然后在针对文字的区域做AI优化。这样就会把分辨的尺寸就会降低很多。第二个的话也是一个带引号的轻量级网络。因为我们有NENN，我们后面会介绍。

下面是我们桌面共享优化的一个效果。可以看到右边的文字会比左边清晰很多。

我们进入下面的最后一个部分，视频控制部分。这个部分实际上主要包括两个部分，一个部分是视频策略，一个是AI推理引擎。

我们先讲一下AI推理引擎。AI引擎是我们云信自研的一个AI推理引擎，我们叫NENN。当然业界我们知道有很多开源的知名的引擎，那这块我们和他们不同的地方是，首先我们针对云信自己的模型做了精细的优化，支持更多op，第二个是我们做了优化了数据的拷贝和排布，对稀疏矩阵的计算NENN会更高效。然后对于一个推理引擎框架来说，性能是一个主要的，另外易用也是一个主要的。在NENN我们支持30种以上的图像处理算法。所以在使用时不需要另加第三方的图像处理库就可以直接使用。右边的话是我们推理速度的对比，上面的是MAC平台，下面的是我们手机上那个平台。可以看到NENN无论是在标准的模型上还是在我们自研的模型上，都会比其他的模型有一个更快更好的优势。

然后就是我们的视频策略。视频策略主要是因为视频引擎主要面对的是终端平台类型众多，有不同的平台，比如说有高性的电脑，有低性的电脑，有笔记本，还有不同的手机和平板。这些平台他的类型不同，性能也不同，所以我们需要在设备初始时根据不同的平台类型来配置不同的算法，不同的种类，参数，还有软硬编解码。比如说对于一些比较好的设备的话，我们开启的算法可能比较复杂，开启的算法种类可能会比较多。对于差的设备，我们会使用一些简单的算法。因为云信的业务是遍布全球，对于全球不同区域网络特点不一样的话我们也会设置不一样的算法种类和参数。第二个在实际运行方面我们云信有Control Engine这样一个模块，他可以实时监控当前设备的CPU和网络状况和网络状况，然后根据这些状况来进行策略的动态调整，动态调整编码和参数，软硬编解码，来实现无论什么时候用户体验的最优。如上就是视频引擎的关键技术。

#3. 视频引擎客户案例

现在我们进入第三部分，视频引擎的一些相关的客户案例。

目前云信视频引擎服务服务于全球1000家以上的企业。这里面比较有代表性的就是网易云音乐，网易云音乐的Look直播，网易云音乐的心遇和在线KTV，这些知名的app都用了云信的视频引擎。

然后就是会议类，诸如网易会议，然后还有会议的通讯工具，网易popo，还有一些第三方的产品，都应用了视频引擎。

以上就是本次分享的全部内容，谢谢大家！