从互动直播到在线抓娃娃，实时视频超低延迟架构的思考与实践

作者介绍：

关旭，即构科技音视频引擎核心专家，硕士毕业于南开大学数学系，先后就职于中兴通讯、腾讯等公司负责音视频相关的研发工作，在实时音视频技术上有多年积累，当前在即构科技主要负责音视频引擎核心开发。
责编：钱曙光（qianshg@csdn.net）
声明：本文为作者原创投稿文章，禁止任何形式未经授权的转载行为。

---

编者按： 2017年12月23日，由即构科技主办的RTC Meetup实时音视频开发者沙龙第一期在深圳圆满结束。会上，即构科技音视频核心工程师关旭就如何打造低延迟的实时音视频架构做了精彩分享，以下是对他演讲内容的整理。

大家好，今天我分享的内容主要分如下几部分：

• 实时音视频场景——从直播到线上抓娃娃
• 实时架构的若干点思考
• 关于信源编码的思考
• 关于信道编码的思考
• 引入延迟的环节和降低延迟的思路

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

图 1

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

图 2

图2是即构互动直播的实时架构图，我们把互动直播分为两部分，一个是主播侧，需要更低的延迟，另一侧是普通观众，对延时不太敏感，中间通过一些旁路的服务把这两个集群连接起来。

在超低延时部分，我们提供的服务包括流状态更新、房间管理等，以及一些流媒体服务，主要起到分发的作用。我们通过单独的服务器集群（和观众侧不太一样），提供实时分发的功能。此外还提供了动态调度的服务，帮助我们在现有的资源网络上找到更好的线路。后面的观众集群是另外一个集群，把它们分开是出于一些业务方和我们自己成本上的考虑，另外会提供存储、PCB加速、分发的功能。

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

图 3

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