实时视频通话超低延迟架构的思考与实践（一）——实时架构的若干点思考

以下是即构科技音视频核心工程师关旭就如何打造实时视频通话超低延迟架构的精彩分享。

嘉宾简介：

关旭，即构科技音视频引擎核心工程师，硕士毕业于南开大学数学系，先后就职于中兴通讯、腾讯等公司负责音视频相关的研发工作，在实时音视频技术上有多年积累，当前在即构科技主要负责音视频引擎核心开发。

精华内容

· 实时音视频场景——从直播到线上抓娃娃

· 实时架构的若干点思考

· 关于信源编码的思考

· 关于信道编码的思考

· 引入延迟的环节和降低延迟的思路

由于篇幅限制，今天先给大家带来前两点的内容。

实时音视频场景——从直播到线上抓娃娃

上图展示了实时音视频两种不同的应用场景——连麦互动直播和线上娃娃机。虽然这两种都是互动，但是对于实时音视频的要求却不同。第一个实时连麦是语音视频流的互动，例如其中一个说了一句话，另外一个人听到了，再回复一句话，这个实时性只是对语音视频流的实时性要求很高。而第二种线上抓娃娃则对信令的延迟提出了更高的要求，操纵者无需说话，看到的是娃娃机传回来的视频流结果。如果考量互动直播是用实时音视频的延迟，那么线上抓娃娃则是用信令和视频流的延时。随着时代的发展，我们对实时语音视频的定义会慢慢有一些不同，将来可能还有更多的因素需要考虑。

上图是即构互动直播的实时架构图，我们把互动直播分为两部分，一个是主播侧，需要更低的延迟，另一侧是普通观众，对延时不太敏感，但对流畅性敏感，中间通过一些旁路的服务把这两个集群（一个集群叫超低延迟集群，另外一个集群叫围观集群）连接起来。在超低延时部分，我们提供的服务包括流状态更新、房间管理等，以及一些流媒体服务，主要起到分发的作用。我们通过超低延迟服务器集群（和观众侧不太一样），提供实时分发的功能。此外还提供了动态调度的服务，帮助我们在现有的资源网络上找到更好的链路。后面的观众集群是另外一个集群，把它们分开是出于一些业务方和我们自己成本上的考虑，另外会提供存储、PCB加速、分发的功能。

中间的旁路服务包括混流、转格式（主要是转码）、转协议等。为什么要混流？举一个比较简单的例子。当主播一侧有9个人连麦，如果没有混流服务，观众端就会同时拉9路音视频，这样对带宽压力很大。普通观众是通过围观服务器集群（延迟相对大的集群）去拉这些流的，这个集群的延迟可控性相对比较弱，有可能会出现这9路画面之间的不同步现象，通过混流服务，观众拉的都是合成好的音视频流，就不会出现各路流之间的不同步问题。还有转格式转码的服务，前面集群提供的是很低延迟的服务，里面一些，比如说编码码流，不能够在传统的CDN网络分发，如果想在传统的CDN网络上分发，就要服务端的转码。还有就是转协议，因为前面提供一个更低延时的服务，后面要在CDN网络上分发，所以协议也需要转。

上图是线上娃娃机的APP版本的架构图，这里的特色是线上娃娃机可以实时推两路视频流，上机玩家可以随时任意去切其中一路画面去看。这两路视频流首先通过我们超低延时服务器集群，同时上机玩家也可以推一路流上去，可以给围观观众方看到这个人在抓娃娃时候的一些表情、反应、语言，增加一种互动性。此外，玩家需要通过手机远程操控娃娃机，因此还需要实时信令的分发。

接下来是娃娃机的H5架构图。在推流方面和APP版本没有太大的区别，娃娃机一侧还是走的私有协议。不同的地方是因为私有协议没有办法直接让H5拉到流，所以中间会加入一个媒体网关，作用是把我们的私有协议翻译成H5可以识别的码流格式，然后H5端通过websocket方式把这路流拉下来，这里需要媒体网关做到超低延时的转换。简单来看，这里的网关服务器只是做了一个分发服务，好像不会引入延时，实际上不然。因为websocket拉的是TCP的流，但是我们推的是UDP的，当视频帧很大的时候，一个帧数据就要切割成很多UDP包上行，服务器需要将这些UDP包攒起来，凑成一个完整的帧后才下发给H5,这样才能保证不花屏，才能跑得通，所以这个攒包组帧的过程是会有延迟的。信令部分和APP部分基本是相似的。

实时构架的若干点思考

刚才介绍了实时音视频的两种场景，下面提出一点思考：实时音视频有什么样的特征？怎么样去架构一个实时音视频系统？

这是仁者见仁，智者见智的问题。你可以通过很多方式把这个系统架构起来，都会达到相对不错的效果。但是我认为，无论怎样，实时音视频都有绕不过的几个点，只有把它们做好了，才能够在业界有更高的知名度、更好的技术储备。

第一是实时音视频是不能等的，因为等了就不是实时音视频了。不能等，这里会引入一个矛盾。既然不能等，例如你把实时音视频也看作一个消费模型来看，那是提前生产还是按需生产？字面上理解很简单，肯定是按需生产，需要的时候才生产，如果提前生产就是延时了。但是并不是每一个点都做成按需生产是合理的。举一个例子，比如你要去播放一段音频，最好的做法是系统或者驱动告诉你，它需要数据了，然后去解一帧塞给它，这就是按需生产。但是为什么还有提前生产一说呢？就是系统告诉你它要数据的时候，实际上它有一个对响应周期的要求。你现去生产可能就要等去解完一帧，但是这个时候来得及吗？如果你只有一路下行，可能就来得及。但是现在要求很多路下行，在很短的时间周期内解很多帧，对硬件性能有很高的要求。通常来讲，并不可取。这只是实时音视频中一个简单的例子。提前生产会引入延迟的，那么到底要提前多久生产，怎么样动态估计我们什么时候应该生产？这是一个开放性的问题，也是一个大家在设计系统时要重点考虑的。

第二是实时音视频不能久等。实时音视频中有些等待是避免不了的，例如你要做音频编码，它本来一定要20毫秒一帧或者40毫秒一帧去做，给一个采样点是编不了的。这里既然有些延迟和等待避免不了，我们当然希望系统处理的粒度越低越好，这样可能会带来更低的延时。但是处理的粒度越低，整个系统在频繁跑的时候，你可以认为它是一套循环，当循环的东西很少，这个循环就会跑很多次，对系统来说就是一个很大的开销和负担。所以不能久等的时候，我们当然希望它处理粒度小。另外处理粒度小还有一个优势，在整个系统中并不能保证每一个环节的处理粒度是一致的。例如这个节点可能要求是10毫秒，下一个结点要求15毫秒，这是由于算法的限制，可能没有办法避免。如果在整个系统内选一个相对小的粒度，在粒度拼接的时候，例如10-15毫秒，要两个10毫秒才能够15毫秒，还剩下5毫秒，剩的就比较少。如果粒度很粗，可能剩下的东西就很多。在粒度拼接的时候，这个剩余的量代表了整个链路中的延迟。所以我们希望处理粒度尽量小，但是又不能小到整个系统没有办法接受的粒度。

第三，实时音视频不能死等。例如你需要接收一个网络包的时候，这个包迟迟不到，这个时候你不能完全不等，完全不等就会卡。但是在等的时候有一个超时的机制，例如这个音频包就是很久不到，就把它跳过去做一个纠帧补偿，当包最终还是到了的时候，我也只能把它扔掉，而不应该把它利用起来。

此外，实时音视频在服务器端还需要深入考虑这样几个问题：第一是负载均衡。第二是就近接入，第三是质量评估，第四是动态路由，第五是算法流控。

第一，负载均衡是说让整个服务器的每一个节点都承担相对均匀的服务，不至于使得某一个节点负载过高造成一些丢包，造成网络往返时的增大，这样对任何的网络损伤来讲，对实时音视频都会造成比较大的延迟增加。

第二是就近接入，这里的“近”并不是指地域上的近，而是“网络上的近”。很简单的例子，我们在深圳做推流，香港离得很近，可以推到香港的服务器，但实际上这毕竟是一个跨域的网络，有不稳定的因素在里面，所以我们宁愿推远一点。这个近指的应该是在网络质量评估意义上的近，例如网络往返时很小、往返时很平稳、分布在延迟比较大的时刻不会还具有很大的概率，丢包率很低等。

要做到就近接入，这个近要有一个很好的质量评估体系。质量评估方法有两种：

1）事后质量评估。在复盘的时候，例如这个网络平稳的运行了一个月，复盘看一下整个月中的质量怎么样，这样的质量评估可以认为是一个相对离线的评估，它能够给我们提供一个指标，最近一个月的网络和上个月相比是否有所改善。我们可以从中学习到一些经验，例如这个月和上个月的调度上有些策略上的不同。这是一个系统化的经验总结和优化的方法。

2）实时质量评估。更重要的应该是一个实时上的评估，例如我现在推流，能够实时监控到当前的质量是怎么样的，就可以做到实时动态路由。实时动态路由是说某个人推流从北京推到迪拜，有很多链路可以选，他可能根据之前的一些经验，假如他之前经验告诉你，直接推到迪拜，这个链路是很好的，但是毕竟有个例。有动态实时的质量评估，就知道这个时候推迪拜是否好，如果不好，可以在用户无感知的情况下更换，随时增减整个链路中一些路由的节点。这就是动态路由的思路。

实时动态路由是说某个人推流从北京推到迪拜，有很多链路可以选，他可能根据之前的一些经验，假如他之前经验告诉你，直接推到迪拜，这个链路是很好的，但是毕竟有个例。有动态实时的质量评估，就知道这个时候推迪拜是否好，如果不好，可以在用户无感知的情况下更换，随时增减整个链路中一些路由的节点。这就是动态路由的思路。

实际情况中是结合前面这4个点，在我们的网络和服务器资源集中，去选出质量最优或者近似最优的链路来保证实时音视频的服务的。但是资源集是有限的，没有人可以保证你的资源集中一定可以选出的这个最优具有很好的链路特征。保证不了就要考虑第五点，我即使选出了一个认为是整个资源集中最优的链路，但是它的质量还达不到很好的标准，就要通过一些算法才能弥补。这些算法包括在一个不可靠的网络中怎么样进行可靠的音视频传输的技术，这些技术在接下来我们会和大家稍微分享一下，也包括整个链路的一些拥塞控制。