姜健：VP9可适性视频编码（SVC）新特性

分享的主要内容包括以下几个方面：

1、 介绍VP9 SVC；

2、 对比SVC和VP8的一些参数；

3、 SVC中去噪功能的实现；

一、SVC (Scalable Video Coding) in VP9

首先向大家提出一个问题，我们为什么要用SVC用的视频编码难道不可以吗我们进行视频会议时，可能会有多方的参与者。如果其中一方参与者的 络状况不是很好，在不采用SVC编码时，则只有一个分辨率，包括空间和时间分辨率。这时，需要根据 络情况不太好的参与者来进行丢包，或者降低空间分辨率来适应其 络状况。又因为每个参与者收到的包都是一样的，这样其他 络情况好的参与者也就会同时受到影响。但是在采用SVC编码的情况下，我们就可以很好的解决这个问题。SVC可以编码不同的分辨率，服务器在分发的时候，它可以根据不同接收者的 络情况对应分发高分辨率或低分辨率的帧，当有参与者的 络情况不好时，就接受低分辨率的帧。这样一来，其他 络情况好的参与者可以不受影响的接收高分辨率的视频帧。

今天会主要介绍VP9 SVC的几种Feature。首先会给大家介绍一下SVC的参考帧预测，因为SVC包含空间和时间上的不同分辨率，所以在参考帧的预测上会有很大的区别。我们还添加了一些特殊的Feature，比如帧内编码帧，但是这个帧不是关键帧。另外，SVC的预测模式固定之后是可以更改的，即可以在编码的过程中，随时修改预测模式。还有一个就是我们最近加入的长时间尺度的编码帧预测，最后则是去噪部分。

1、SVC Superframe

上图是一个预测的例子，模式会稍微复杂一点，它把空间分辨率分为两层（SL0、SL1），时间分辨率分为三层（TL0、TL1、TL2），不同的时间分辨率相当于不同的帧率。在视频流里，编码速率是60帧/秒，时间分辨率TL2占了一半，即30 FPS，时间分辨率TL1占了1/4，即15FPS，最后一层TL0也是15FPS。在这个预测模式中，灰色的箭头代表LAST FRAME，它表示当前编码帧的前一帧；金色的箭头代表GOLDEN FRAME，在非SVC的定义为很早之前的一个帧，可能是第10帧、第20帧、第30帧，然后从它开始预测。但是，在SVC里面，我们改变了它的定义，GOLDEN FRAME表示是从更低分辨率的那一层去预测。在后面的预测过程中，我们会一直重复这样的一个模式。对比非SVC，在整个预测过程中，都是采用的离得最近的帧，包括LAST FRAME为当前编码帧的前一帧，在GOLDEN FRAME我们采用从更低分辨率的那一层去预测，而没有采用长时间的帧来预测，为了解决这一问题，我们后面又引入了一个新的Feature。

3、SVC Reference frame buffer and refresh

接下来介绍一下我们在不同分辨率帧之间进行预测添加的控制，如果你是用户，就可以通过API来控制不同帧的不同分辨率之间的预测是否开启。还有就是我们可以控制在非关键帧上关闭预测，在关键帧上开启不同分辨率帧之间的预测，这个在WebRTC里是用control prediction来设置的。这个API比较简单，下面这张图就是它的一些定义的类型。

下面我来讲一下SVC的丢帧过程。在非SVC里，某一帧丢掉就丢掉了，但是在SVC里由于一个超级帧里面有三个不同分辨率的帧，在丢帧时，则要考虑是丢整个帧,或者只丢掉其中的某些层。就像在前面第一个Feature讲的一样，我们因为控制不同层之间的预测，如果不同的层之间没有相互依赖的关系，当丢掉最高分辨率的层，也可以进行解码。如果不同帧互相之间是有依赖的，那么在丢最低分辨率层的时候，必须把最高分辨率层一起丢掉，否则就解不出来。我们现在有三个不同的设置，第一个设置就是更低分辨率的帧丢掉之后，更高分辨率的帧也就直接丢掉，这种情况适用于不同空间分辨率的帧之间互相有依赖的情况。第二个设置是任何一个空间分辨率的帧都可以随便丢，这种情况是不同分辨率的帧之间没有相互依赖的关系。第三个设置就是最低分辨率的帧可以丢，在最低分辨率的帧丢掉之后，整个超级帧都一起丢掉。这个跟第一个有点类似，它们有交叉的情况。下面给出的就是一个控制丢帧的API。

下面一个Feature是帧内编码的帧，但是它是非关键帧。举例说明，如果没有这个Feature，当我们现在有五个人用视频会议开会时，突然有第六个人加入进来，他没有任何关于当前视频的信息。如果想开始的话，所有人的视频帧都必须要插入一个关键帧，他才能看到所有人。但是，插入关键帧会有一个问题，关键帧会更新所有的关键帧的Buffer，这个会导致所有人重新开始，也就是这个视频流会重新开始一遍。然后我们想到，可以用帧内编码的帧，并且它不是关键帧，这样一来就不会去更新所有的参考帧的Buffer。

为了解决这个问题，我们在VP9中使用了另外一个Feature，用来显示已经存在的一个帧，称为show existing frame。在一个超级帧中，编码完帧内编码的帧后，把它的帧头部copy到另外一个帧里，然后把copy后的帧加上以前显示帧内编码的帧的标记。但是，因为我们只复制它的头部，它的编码数据还是来自于帧内编码的帧，整个超级帧的大小也基本上不会变化。通过这个我们很好的解决了新用户加入到视频会议后，所有人的视频流都要重启的问题。

7、Long Term Temporal Prediction

8、Scale partitioning in SVC

最后是一个很简单的Feature，我们会重复利用低分辨率的运动向量，把低分辨率下计算的运动向量表示成MV的两个方向，在更高分辨率的情况下，我们会利用已有的信息来进行运动向量的搜索。在我们需要寻找到新的运动向量时，就将搜索范围进一步缩小，从而更快的进行运动向量的搜索，这是加速的Feature，没有API可以控制。

二、VP9 SVC v.s. VP8 Simulcast

上图展示的是VP9 SVC的编码速度，数据中的最近时间是2018年2月份，已经相对比较老了。现在SVC的编码速度又相对提高了一些，有超过45%的提升，以前每编码一个超级帧大概需要25毫秒，现在大概是10在15毫秒之间。这个测试是在Mac设备上进行的，笔记本电脑也完全可以达到实时性的要求。并且，根据我们在Google内部的预测，没有接收过速度太慢之类的反馈，目前从速度和性能上来说还是不错的。

三、VP9 Temporal Denoiser

在非SVC情况下，我们可以把INTRA看成Source，就是摄像头直接拍下来的内容，LAST、GOLDEN、ALTREF是参考帧。在去噪的过程中我们会做运动补偿，比如说，上图中绿色的块，它的参考帧是LAST，我们对LAST进行运动补偿，并把它放到一个新的Buffer里面，上图中黄色的块，它的参考帧是GOLDEN，我们对GOLDEN块进行运动补偿并放到新的Buffer里面，然后对运动补偿过的帧进行去噪，并且只针对3个通道Y、U、V 中的Y通道做去噪。 

我们将去噪的控制权交给了用户，让用户来决定选择HD层还是VGA层进行去噪。用户可以通过一个Denoiser的API设置，如果将API设成1，去噪就只有最高分辨率的这一层，在这种情况下，当在Denoiser分配Buffer的时候，只用四个Buffer就好了。如果将API设成2，也就是现在要对两个分辨率层进行去噪。它会针对HD和VGA两层进行去噪，在Denoiser上就需要8个Buffer。

四、总结

总结一下，首先VP9已经开始在Google进行内测，我们也正在不停地改进，添加一些新的Feature进去，预计不久之后应该会将VP9 SVC加入到WebRTC中开放给大家。此外，VP9 SVC质量相比VP8来说还是非常好的，并且我们也在不停提高编码速度，这样一来，无论是使用笔记本电脑或台式机，VP9 SVC也完全可以满足实时性要求。

精品文章推荐

技术干货：

• Per-Title编码优化

• 2018:视频标准混战的元年序幕

• Demuxed：编解码器和压缩的未来

• Netflix：我们是如何评估Codec性能的/span>

• 编码压缩新思路:面向QoE的感知视频编码

• 编解码器之战：AV1、HEVC、VP9和VVC

• AV1：下一代视频标准—约束定向增强滤波器

• 基于QoE的实时视频编码优化：低功耗，低延时，高质量