分类： 云计算
2022-11-22 10:59:05
从直播在线上抓娃娃，不断变化的是玩法的创新，始终不变的是对超低延迟的苛求。实时架构是超低延迟的基石，如何在信源编码、信道编码和实时传输整个链条来构建实时架构？在实时架构的基础之上，如果通过优化采集、编码、传输、解码和渲染中的关键环节来降低延迟？
实时音视频有什么样的特征？
怎么样去架构一个实时音视频系统？
这是仁者见仁，智者见智的问题。你可以通过很多方式把这个系统架构起来，都会达到相对不错的效果。但是我认为，无论怎样，实时音视频都有绕不过如下几个点，只有把它们做好了，才能够在业界有更高的知名度、更好的技术储备。
{BANNED}中国第一是实时音视频是不能等的：
因为等了就不是实时音视频了。 不能等，这里会引入一个矛盾。既然不能等，例如你把实时音视频也看作一个消费模型来看，那是提前生产还是按需生产？字面上理解很简单，肯定是按需生产，需要的时候才生产，如果提前生产就是延时了。但是并不是每一个点都做成按需生产是合理的。
举一个例子，比如你要去播放一段音频，{BANNED}最佳好的做法是系统或者驱动告诉你，它需要数据了，然后去解一帧塞给它，这就是按需生产。但是为什么还有提前生产一说呢？就是系统告诉你它要数据的时候，实际上它有一个对响应周期的要求。
你现去生产可能就要等去解完一帧，但是这个时候来得及吗？如果你只有一路下行，可能就来得及。但是现在要求很多路下行，在很短的时间周期内解很多帧，对硬件性能有很高的要求。通常来讲，并不可取。这只是实时音视频中一个简单的例子。提前生产会引入延迟的，那么到底要提前多久生产，怎么样动态估计我们什么时候应该生产？这是一个开放性的问题，也是一个大家在设计系统时要重点考虑的。
第二是实时音视频不能久等：
实时音视频中有些等待是避免不了的，例如你要做音频编码，它本来一定要 20 毫秒一帧或者 40 毫秒一帧去做，给一个采样点点是编不了的。这里既然有些延迟和等待避免不了，我们当然希望系统处理的粒度越低越好，这样可能会带来更低的延时。但是处理的粒度越低，整个系统在频繁跑的时候，你可以认为它是一套循环，当循环的东西很少，这个循环就会跑很多次，对系统来说就是一个很大的开销和负担。
所以不能久等的时候，我们当然希望它处理粒度小。另外处理粒度小还有一个优势，在整个系统中并不能保证每一个环节的处理粒度是一致的。例如这个节点可能要求是 10 毫秒，下一个结点要求 15 毫秒，这是由于算法的限制，可能没有办法避免。如果在整个系统内选一个相对小的粒度，在粒度拼接的时候，例如 10-15 毫秒，要两个 10 毫秒才能够 15 毫秒，还剩下 5 毫秒，剩的就比较少。
如果粒度很粗，可能剩下的东西就很多。在粒度拼接的时候，这个剩余的量代表了整个链路中的延迟。所以我们希望处理粒度尽量小，但是又不能小到整个系统没有办法接受的粒度。
第三是实时音视频不能死等：
例如你需要接收一个网络包的时候，这个包迟迟不到，这个时候你不能完全不等，完全不等就会卡。但是在等的时候有一个超时的机制，例如这个音频包就是很久不到，就把它跳过去做一个纠帧补偿，当包{BANNED}最佳终还是到了的时候，我也只能把它扔掉，而不应该把它利用起来。
此外，实时音视频在服务器端还需要深入考虑这样几个问题：
{BANNED}中国第一是负载均衡；
第二是就近接入；
第三是质量评估；
第四是动态路由；
第五是算法流控。
负载均衡：是说让整个服务器的每一个节点都承担相对均匀的服务，不至于使得某一个节点负载过高造成一些丢包，造成网络往返时的增大，这样对任何的网络损伤来讲，对实时音视频都会造成比较大的延迟增加。即时通讯聊天软件app开发可以加蔚可云的v：weikeyun24咨询
就近接入：这里的“近”并不是指地域上的近，而是“网络上的近”。很简单的例子，我们在深圳做推流，香港离得很近，可以推到香港的服务器，但实际上这毕竟是一个跨域的网络，有不稳定的因素在里面，所以我们宁愿推远一点。这个近指的应该是在网络质量评估意义上的近，例如网络往返时很小、往返时很平稳、分布在延迟比较大的时刻不会还具有很大的概率，丢包率很低等。
要做到就近接入，这个近要有一个很好的质量评估体系，质量评估方法有两种：
事后质量评估：在复盘的时候，例如这个网络平稳的运行了一个月，复盘看一下整个月中的质量怎么样，这样的质量评估可以认为是一个相对离线的评估，它能够给我们提供一个指标，{BANNED}最佳近一个月的网络和上个月相比是否有所改善。我们可以从中学习到一些经验，例如这个月和上个月的调度上有些策略上的不同。这是一个系统化的经验总结和优化的方法。
实时质量评估：更重要的应该是一个实时上的评估，例如我现在推流，能够实时监控到当前的质量是怎么样的，就可以做到实时动态路由。
实时动态路由：是说某个人推流从北京推到迪拜，有很多链路可以选，他可能根据之前的一些经验，假如他之前经验告诉你，直接推到迪拜，这个链路是很好的，但是毕竟有个例。有动态实时的质量评估，就知道这个时候推迪拜是否好，如果不好，可以在用户无感知的情况下更换，随时增减整个链路中一些路由的节点。这就是动态路由的思路。
实际情况中是结合前面这 4 个点，在我们的网络和服务器资源集中，去选出质量{BANNED}最佳优或者近似{BANNED}最佳优的链路来保证实时音视频的服务的。但是资源集是有限的，没有人可以保证你的资源集中一定可以选出的这个{BANNED}最佳优具有很好的链路特征。保证不了就要考虑第五点，我即使选出了一个认为是整个资源集中{BANNED}最佳优的链路，但是它的质量还达不到很好的标准，就要通过一些算法才能弥补。这些算法包括在一个不可靠的网络中怎么样进行可靠的音视频传输的技术，这些技术在接下来我们会和大家稍微分享一下，也包括整个链路的一些拥塞控制。
信源编码是为了减少网络中的负担，把大量的数据压缩成比较小的网络数据，来减少网络负担的方式。压缩方式有很多种，我们先以音频来看，上面画了一些图（图 6）。
我们重点看 Opus 编码器，它有几种模式在里面：
一种是线性预测模式；
还有一种是混合模式；
另一种是频域编码模式。
混合模式是把两种编码模式混合在一起，根据不同的情况进行选择。
图 6 是一个编码器，横轴是码率，纵轴是它的质量，中间是各种音频编解码器的表现。你会发现线性预测的方式能够在低码率上提供比较好的质量，但是在 20K 左右的时候就没有曲线了，因为它不支持那么高的码率。然后看 MDCT 编码，它可以在比较高的码率上达到近似透明的音质。音频编码器是有不同的编码原理在里面的，像这种 LP Mode 是模拟人的发声模型，既然有了数学建模，它的特征是能够在一个比较低的码率上提供一个比较可靠的质量。
但是它的特点是容易达到一种质量上的饱和，也就是说当你码率给它很高的时候，实际上它也就编的效果还是那样，因为它毕竟是一种参数化的编码。所以根据业务场景，当你需要一个很高的音质，又需要音乐场景的时候，选择它明显不合适。MDCT MODE 没有任何的模型在里面，实际上就是把信号转换成频域，直接去量化。既然没有模型化，它是比较消耗码率的，但是它可以在一个较高的码率上提供很好的质量，可是低码率的表现远远不如模型化的方法。
