把延迟降低

在安防监控的场景里，家用 IP 摄像头一般都带有云台旋转的功能，也就是摄像头的指向会跟随远程的遥控进行转动，如果画面延时比较大，那么观看端按下操控按钮到看到画面运动所需要等待的时间就会比较长，这样用户体验就会特别不好。

延迟做到最低

再比如 2017 非常流行的在线夹娃娃场景，如果远程玩家视频画面的延时非常高，那么远程操控娃娃机就变得不太可能，没有谁能真正抓到娃娃。

既然要达到这么低的要求，普通的在线直播技术就不再适用了，我们需要新引入两个新的科技点：延时控制 和 UDP加速。

- 延时控制

网络不是完美的，网络是波动的。在有波动的网络下，服务器上的音视频数据并不是稳稳的来到您的手机上，而是忽快忽慢。慢的时候您可能会看到卡顿，快的时候就会产生堆积，而堆积的后果就是延时的增加。所以，我们需要采用延迟控制技术，它的原理很简单，当网络慢的时候就播的慢一点，当网络快的时候就播得快一点，这样就起到一定的缓冲作用。当然，真正实现时就会发现，声音是个很不听话的“孩子”，要处理好声音的效果是一个非常高难度的技术活。

- UDP加速

既然网络不那么完美，总是时快时慢，那我们是不是可以改善一下呢？在经典的单向音视频方案中，一般采用的都是 TCP 协议，因为它简单可靠且兼容性极好。然而 TCP 的拥塞控制特别注重公平，天然就有时快时慢的坏毛病，所以我们需要用 UDP 协议替代之，相比于设计目标定位于可靠传输的 TCP 协议，UDP 可以做得更稳且更快。

我们将 延时控制和 UDP 加速技术加入到 标签里，可以将端到端的延时控制在 500ms 左右。这对于操作延时要求比较苛刻的场景，就可以满足需求了。

单向变双向

有了单向低延时技术，那么双向视频通话自然也就比较简单了，只需要通话的双方 A 和 B 各自拉通一路低延时链路就可以了。

比如在车险定损的场景里，遇险的车主通过小程序呼叫保险公司，这个时候保险公司内部的定损客服只要通过一路低延时的链路就可以看到车子的出险情况。但是仅仅这样还不够，视频内容跟图片一样，都容易被实现伪造和作假。所以定损员就需要有一路视频同样到达车主那里，这样两路音视频同时连通，就构成了一个典型的视频通话场景。由于车主和定损员可以通过视频进行交流，因此造假骗保的风险就被极大地降低了。

单向变双向

虽然这样说是没错，但实现上可不是那么简单的。恰恰相反，它非常困难，因为我们还需要引入额外的很多科技点：

- 噪声消除

噪声抑制的目的是将用户所处环境里的背景噪音去除掉，好的噪声抑制是回音消除的前提，否则声学模块无法从采集的声音辨别出哪些是回声，哪些是应该被保留的声音。

- 回音抑制

在双向视频通话中，用户自己手机的麦克风会把喇叭里播放的声音再次记录下来，如果不将其抹除掉，这些声音会被反送给对端的用户，从而形成回声。

- Qos流控

网络不可能一直都很完美，尤其是中国大陆地区的上行网速一直都有政策限制。Qos流控的作用就是预测用户当前的上行网速，并估算出一个适当的数值反馈给编码器，这样一来，编码器要送出的音视频数据就不会超过当前网络的传输能力，从而减少卡顿的发生。

- 丢包恢复

再好的网络也难免会有丢包的情况，尤其是 WiFi 和 4G 等无线网络，由于传输介质本身就不是可以独享的，所以一旦受到干扰，或者高速运动都会产生大量的丢包，这时就需要引入一些丢包恢复技术，将失去的数据尽量补救回来。

以上四个科技点，我们也加入到了 和 标签中，并给他们赋予了一个新的模式 RTC（ Real Time Chatting 的 首字母缩写，有点 Chenglish 的味道），这才真正把实时音视频通话搞定。

你看，要保持功能到位，又不能跳出标签这种简单易用的设计风格，这不容易吧。实际上这里的四个科技点实在是太难了，需要很多年的技术积累和沉淀，以至于我们也不是现用现做的。正所谓站在巨人的肩膀上才能看得更远，这里的技术能力是由腾讯音视频实验室的“天籁”引擎所实现的。

双向变多人

既然双人视频通话已经搞定了，是不是多人也就照葫芦画瓢就可以了？您看，我们只需要将 A 和 B 之间的 url 置换，变成 A、B、C 甚至更多人之间的 url 置换，不就可以了吗？

思路依然正确，但是真正要将功能做到好用且成熟，仅依靠简单的 url 交换是非常粗糙的，我们需要继续引入额外的两个科技点：

双向变多人

- 房间管理

以上图所示的 A B C 之间的多人视频场景为例，要让每一个人都很清楚其它人的状态（比如播放url，以及当前是否有上行等等），这个事情可是非常困难的，搞不好就容易出现各方信息不对齐。对于更复杂一点的情况，比如当有第四个人 D 进来的时候，或者第五个人 E 进来又出去的时候，这种信息同步几乎就是一场噩梦。

最好的办法就是把参会人的状态和信息都收拢在服务器端，构造一个 房间 的概念，这样就可以确保参会人都能从服务端获得同样的信息，而不需要各自去维护。

- 通知系统

当有新的参与者进入房间，或者有人离开时，就需要对房间里的人进行信息广播，这就需要一个不错的 IM 系统负责收发消息。比如当 D 进入时，就可以向房间内的其它成员广播这个 “I'm coming” 的事件，这样 A B C 就可以在自己的 UI 上展示 D 的视频画面了。

加入房间管理和 通知系统以后，我们就可以将 和 和微信小程序的 websocket 等基础能力组合在一起，构建各种功能强大、逻辑复杂的小程序应用。

一路走来

一路走来，大家可以看到我们在小程序音视频的技术体系上所做的种种努力可以用如下的技术图谱勾勒出来：

小程序音视频的技术体系图

• 首先是化繁为简，将所有的音视频解决方案拆解成两个基础行为：上行和下行，并通过两个标签 和 的简单组合，实现最基本的在线直播功能。
• 之后是通过加速线路和延时控制，将一路音视频的时延缩短到 500ms 以内；
• 再之后，我们通过引入噪声抑制和回声消除等声学处理模块，让一路变两路成为了可能，这也就构成一个最简单的视频通话能力。
• 最后，我们又通过加入房间服务和状态同步通知，将双路音视频变成了多路音视频，从而将应用范围进一步扩大。

问答
怎样部署小程序？
相关阅读
教你1天搭建自己的“微视”
教你从0到1搭建小程序音视频
教你快速搭建一场发布会直播方案
云学院 · 课程推荐 | 知乎KOL，与你分享机器学习中如何做选择

此文已由作者授权腾讯云+社区发布，完整原文请点击

搜索关注公众号「云加社区」，第一时间获取技术干货，关注后回复1024 送你一份技术课程大礼包！

海量技术实践经验，尽在云加社区！