实时视频通话超低延迟架构的思考与实践（二）——关于信源编码的思考

信源编码是为了减少网络中的负担，把大量的数据压缩成比较小的网络数据，来减少网络负担的方式。压缩方式有很多种，我们先以音频来看，上面画了一些图，我们重点看Opus编码器，它有几种模式在里面，一种是线性预测模式，还有一种是混合模式，还有一种是频域编码模式。混合模式是把两种编码模式混合在一起，根据不同的情况进行选择。

上图是一个编码器，横轴是码率，纵轴是它的质量，中间是各种音频编解码器的表现。你会发现线性预测的方式能够在低码率上提供比较好的质量，但是在20K左右的时候就没有曲线了，因为它不支持那么高的码率。然后看MDCT编码，它可以在比较高的码率上达到近似透明的音质。音频编码器是有不同的编码原理在里面的，像这种LP Mode是模拟人的发声模型，既然有了数学建模，它的特征是能够在一个比较低的码率上提供一个比较可靠的质量。但是它的特点是容易达到一种质量上的饱和，也就是说当你码率给它很高的时候，实际上它也就编的效果还是那样，因为它毕竟是一种参数化的编码。所以根据业务场景，当你需要一个很高的音质，又需要音乐场景的时候，选择它明显不合适。MDCT MODE没有任何的模型在里面，实际上就是把信号转换成频域，直接去量化。既然没有模型化，它是比较消耗码率的，但是它可以在一个较高的码率上提供很好的质量，可是低码率的表现远远不如模型化的方法。

整体总结起来，音频包括语音和音乐两种，因此有适合语音的codec和适合音乐的codec。第一种codec适合语音，语音可以模型化，适用于语音的codec能够在低码率上提供很好的质量，提供一个相对高的压缩比,但是它容易达到饱和，不能够提供一个近似于透明的音质。另外一种codec的编码原理不一样，能够把音乐、语音都编得很好，但是特点是不能够提供太高的压缩比，指望它能够在低码率下提供很高的编码质量是做不到的。

关于视频编码，最简单的几个点有I帧、P帧、B帧。I帧是自参考，P帧是向前参考，它会参考历史帧的特性进行编码。B帧是双向参考，它可以参考前面的帧，也可以参考后面的帧。B帧可以带来更高的压缩比，提供更好的质量。但是因为它会参考将来的帧，所以会引入延迟，因此我们在实时音视频系统中是很少用到B帧的。

想要做好实时的音视频系统，流控是一定要做的，流控对视频的编解码有什么要求？至少有一点，编解码器的码控一定要很稳定。为什么？举例说，我现在有一个很好的拥塞控制策略，带宽估计做得很好，一点差错都没有，估计出某一个时刻可分配视频的带宽就是500kbps，就可以让视频编码器设置成500kbps。但是，如果码控不是很稳定，你设置500kbps的时候，视频编码器可能就跑到600kbps了，这样就会带来一些阻塞和延迟。因此，我们希望选择的codec具有很好的码控策略。

实际上一些开源代码都是有做码控的，但是直接拿来用并不是适合你的场景，因为这些开源代码做起来，可能或多或少的考虑其他的场景，并不只是实时音视频场景。比如说某个codec是用来是压片的，希望半个小时或者一个小时之内达到预定的码率就可以，不会管这一秒钟或者下一秒是什么样子的，但是实时音视频就是要求要把时间窗做得很小。

另外我们希望codec有分层编码的能力。什么是分层编码？为什么要有分层编码？分层编码也分两种，一种是时域上的分层，一种是空域上的分层。前者是编码的时候是当前帧不参考上一帧，而是有隔帧参考的策略；后者可以认为使用较低的码率先编码一个小的画面，然后使用剩余的码率编码增量的部分，得到更高分辨率的画面。 为什么要这样做？实时音视频中并不是很多场景都是一对一的，当不是一对一，要做流控的时候，不可能因为某一路观众的下行不好，就把主播上行推流的码率降下来，因为可能还有一千个观众的网络很好，这些网络好的观众也会因为个别观众网络不好，而只能看到不那么清晰的画面。所以要分层，可以在服务器端选择给用户到底下发哪一层的，因为有分层策略，如果这个人线路不好，只要选择其中一个比较小的层次发给他就可以了，例如核心层，这样可以紧紧利用核心层把整个视频还原，可能会损伤一些细节或者帧率偏低，但是至少整体可用。

最后，我想说一下，很多人认为，视频的数据量很大，视频的延时比音频应该更高才对，实际上不是。因为很多的延迟实际上是编解码自有的延迟，如果编解码中没有B帧的话，你可以理解为视频编码是没有任何延迟的。但是音频编码或多或少都会参考一些将来的数据，也就是说音频编码器的延时一定是存在的。因此，通常来讲，音频的延时比视频的延时更高才对。