了解流程注意事项：

本文转载自云加社区，本文作者（常青）为腾讯视频云终端技术负责人，2008年毕业加入腾讯，一直从事客户端研发相关工作，参与过PC QQ、手机QQ、IoT等产品项目。现于腾讯视频云团队负责音视频终端解决方案的优化与实施，帮助客户以可控的研发成本投入获得业界一流的音视频解决方案。我们目前的产品线包括：互动直播、点播、短视频、实时视频通话、图像处理、AI等。

为了方便大家消化，请参考本文的思维导图：

这款音视频小程序诞生于2017年4月一趟从深圳开往广州的列车上……

常青带着小程序音视频解决方案坐上直通车进微信事业群

偶然的合作

腾讯云与微信团队达成合作

早在 2016 年微信公测小程序之前，腾讯内部各个团队就已经收到消息，大家都知道小程序会给移动应用场景带来巨大的改变。不过当时我刚加入腾讯视频云团队，对这些信息比较关注，并没有多想。

2017 年初，随着大量客户的咨询，我和我的腾讯视频云团队开始意识到这方面的需求特别强烈。但因精力有限，以“小团队大成果”著称的微信工程团队几乎无法覆盖所有应用场景。在音视频方面，小程序只提供了一些基本的采集和播放能力，比如最熟悉的标签都是使用系统播放器实现的，因此只能支持 HLS 高延迟的直播和视频点播功能。

此时，经过一年多的打磨优化，腾讯视频云的 SDK 产品已经变得如同二战初期的零式战斗机，随时准备“砍瓜切菜”。虽然这边的合作机会并不确定，但我们团队还是从深圳总部坐大巴来到了广州 TIT。

经过多轮沟通以及各方帮助，这次合作虽然偶然，充满不确定性，但最终得以达成。

技术挑战

从 0 到 1 很困难

在音视频应用场景下，两个团队能够达成合作自然是好事。但微信的市场地位也决定了这是一个不容掉以轻心的战场，因此面临的挑战也极其严峻：

除了标准高，时间也是一个很不利的因素，整个项目给我们只有两周的时间来证明我们的能力，在短短的两周时间里，我们需要实施一个G2C项目，并顺利通过产品演示和方案验收。

简化复杂

面对这些挑战，我想到了苏联领导人卡拉什尼科夫设计的著名的AK-47。

毫不夸张地说，AK-47是世界上最成功的单兵武器，全球大约生产了1亿支这种枪，杀伤力极强，可靠性极佳，永不卡壳，不易损坏，无论是在沙漠还是雨林，都能稳定释放火力，操作非常方便。

它的成功原因在于其贯彻的简洁实用的设计理念：旋转锁紧确保安全，杜绝了随机事故的发生；结构简单，拆卸方便，因此它的生产不需要特别复杂的加工工艺，也不需要巨额的生产设备投入，即便是普通的小作坊就可以开始生产。

没错，把事情简单化，追求简单和可靠，这就是我们需要达到的目的。

克服技术困难

实现这些并不容易，我们的团队一步步攻克了技术难关。

1. 上行链路和下行链路

首先我们需要对腾讯视频云现有的音视频体系进行拆解和抽象，也就是将整个系统分解成一个个的构建块，其中最重要的两个是：音视频上行（推送）和音视频下行（播放）。

音视频上行（PUSH）

就是把你手机上的声音和画面实时上传到云端，我们通过视频云SDK实现了这个能力，并且封装成一个叫的标签。

音频和视频上行链路

SDK 内部实现机制如上图所示：首先我们需要采集摄像头图像，采集麦克风声音。但是原生采集的图像和声音需要进行预处理。直接采集的图像可能带有较大的噪声，需要进行图像降噪；比如原生采集的人像中，皮肤可能不符合人的预期，需要进行磨皮美颜；直接采集的声音也可能带有较大的环境噪声，需要进行前景和背景声音分离，然后抑制背景噪音。

经过预处理后，图像和声音一般都会比原图好很多，因为所有的预处理都是为了“取悦”人的视听感受，所以这个看似不起眼的部分会吸引很多公司在其中进行大量的技术投入。举个例子，以液晶平板电视为例，索尼的液晶产品线，没有自己的液晶面板（主要采用台湾和大陆的液晶面板），但总能在整体效果上领先其他公司，背后的秘密就是在图像处理（基于图像数据库的超分辨率显示）和背光技术（所有动物的眼睛对亮度最敏感）方面的不断积累和投入。

图像和声音经过“打磨”之后，就可以送到编码器进行编码压缩了。编码器的工作就是将图像和声音压缩成二进制数据，压缩后的体积比压缩前小很多。最后要做的就是将编码后的数据通过网络模块发送出去。在线直播场景下，一般使用的网络协议都是基于TCP，而在实时通话场景下，使用的网络协议主要是UDP。

音频和视频下行链路 (PLAY)

也叫播放，就是把编码后的音视频数据从云端实时下载下来，并实时播放，这样就可以看到远端的画面，听到远端的声音了。同样的，我们用视频云SDK实现了这部分能力，并封装成一个叫的标签。

音频和视频下行链路

SDK 内部的实现机制如上图所示：云端传来的数据会直接发送到网络模块，但网络并不是完美的，总会有速度波动，甚至会出现堵塞、闪断的情况。如果服务器收到一段数据，SDK 播放一段数据，那么网络稍有波动，画面和声音就会卡住。我们使用 () 技术来解决这个问题，就像是为网络传来的数据准备了一个小蓄水池，音视频数据会先在这里暂存一段时间再发送出去播放，这样在网络不稳定的时候，就有一些“应急”的数据可用。

数据缓冲之后就可以交给解码器进行解码了。解码就是把压缩后的音视频数据还原成图片和声音，然后进行渲染播放。图片的渲染和iOS的系统界面我们利用了图片的渲染和声音的播放。

2.信号放大器

通过这两个简单的标签，我们就可以进行初步的组合，搭建出第一个也是最简单的应用场景：在线直播。

信号放大器

在线直播是一个非常经典的单向音视频场景，只需要简单将两个标签组合在一起即可，第一个标签负责将本地的图片和声音实时上传到腾讯云，第二个标签负责实时从云端拉取音视频流。

如果是简单的上行+下行，那么我们只需要搭建一个中转服务器就可以解决问题。但是这只能在很小的范围内实现高质量的直播服务。要真正实现高并发、流畅不卡顿，还需要强大的视频云。

视频云在这里的作用就像是一个信号放大器，负责把一路来的音视频放大，传到全国各地，让大家能从离自己更近的云服务器拉到实时流畅的音视频流。因为原理简单，稳定可靠，支持百万人同时高并发观看，所以从在线教育到体育赛事，从游戏直播到花椒映客，都是基于这个技术。

但是在线直播方案只能解决单向的音视频问题，因为它有一个很明显的问题，那就是延迟普遍在2秒到5秒左右，这也是使用腾讯云视频云标签才能达到的效果。如果是标签的话，延迟会更长，最多能达到20秒以上，所以在一些对延迟要求非常严格的场景下已经不再适用。

3.减少延迟

在安防监控场景中，家用网络摄像机一般都具有云台旋转功能，也就是摄像机的方向会跟随遥控器转动。如果图像延迟比较大，那么观看者从按下控制按钮到看到图像移动需要等待的时间就会比较长，用户体验会特别差。

尽量减少延迟

再比如2017年非常流行的在线抓娃娃机场景，如果远程玩家的视频图像延迟很高，那么远程控制抓娃娃机就变得不可能，也就没有人能真正抓住娃娃。

既然要满足这么低的要求，那么普通的在线直播技术就不再适用了，我们需要引入两项新技术：延迟控制和UDP加速。

延时控制

网络不是完美的，是有波动的。在波动的网络中，服务器上的音视频数据并不是稳定地传到你的手机上的，而是时快时慢。慢的时候可能会看到卡顿，快的时候就会积累，积累的后果就是延迟增加。所以我们需要用到延迟控制技术。它的原理很简单，网络慢的时候播放慢一点，网络快的时候播放快一点，这样就起到了一定的缓冲作用。当然实际实施的时候，你会发现声音是个很不听话的“孩子”，处理好音效是一个很困难的技术活。

UDP 加速

既然网络不是完美的，总是时快时慢，那我们能不能改进一下呢？在经典的单向音视频解决方案中，一般会使用 TCP 协议，因为它简单可靠，兼容性强。但是 TCP 的拥塞控制特别注重公平性，天然有时快时慢的坏习惯，所以我们需要改用 UDP 协议。相比于为可靠传输而设计的 TCP 协议，UDP 可以更加稳定，速度更快。

我们在标签中添加了时延控制和UDP加速技术，可以将端到端时延控制在20%左右，可以满足对操作时延要求更为严格的场景需求。

4. 从单向到双向

有了单向低延迟技术，双向视频通话自然就简单多了，通话双方A、B只需要各自开启一条低延迟链路即可。

例如在车险定损的场景下，遇险的车主通过小程序拨打保险公司电话，此时保险公司定损客服可以通过低延迟的链路看到车辆的事故情况。但这还不够，视频内容和图片一样，很容易被伪造和篡改，因此定损员需要有视频才能同时到达车主手中。这样，音视频两个通道就同时打通了，形成了一个典型的视频通话场景。由于车主和定损员可以通过视频进行沟通，诈骗和保险欺诈的风险就大大降低了。

单向到双向

虽然确实如此，但实现起来却没那么简单，相反，非常困难，因为我们需要引入很多额外的技术点：

噪音消除

噪声抑制的目的是为了去除用户环境中的背景噪声，良好的噪声抑制是实现回声消除的前提，否则声学模块无法从采集到的声音中区分哪些声音是回声，哪些声音应该保留。

回音抑制

在双向视频通话中，用户自己手机的麦克风会把扬声器中播放的声音再次录下来，如果不抹掉，这些声音就会传回到另一端的用户耳中，形成回声。

QoS 流量控制

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

数据包丢失恢复

无论网络有多好，丢包都是不可避免的，尤其是在WiFi、4G等无线网络中，由于传输介质本身不具有独占性，一旦受到干扰或者高速移动，就会造成大量数据包丢失，这时候就需要引入一些丢包恢复技术，尽可能的恢复丢失的数据。

我们还将上述四项技术点也加入到了和标签中，并且赋予了新的模式RTC（Real Time的缩写，有点儿意思），真正让实时音视频通话成为可能。

你看，在不脱离标签简洁易用的设计风格的情况下，保持功能到位，这可不是件容易的事。其实这里的四个技术点太难了，需要多年的技术积累和沉淀，所以我们现在都没有用到。俗话说，只有站在巨人的肩膀上，才能看得更远。这里的技术能力，正是腾讯音视频实验室的“天籁”引擎实现的。

5. 双向至多人

现在双人视频通话已经搞定，那么多人视频通话是不是也可以照做呢？你看，我们只要把 A 和 B 之间的 URL 替换掉，就变成了 A、B、C 甚至更多人之间的 URL 替换，不是吗？

思路还是对的，但要真正把功能做好、做成熟，只靠简单的 URL 交换是很粗糙的，需要继续介绍另外两个技术点：

双向至多人

客房管理

以 ABC 之间的多人视频场景为例，让每个人都知道其他人的状态（比如播放网址、是否有上行等）是非常困难的，如果做得不好，很容易造成各方信息错位。对于更复杂的情况，比如第四个人 D 进来了，或者第五个人 E 进来又走了，这种信息同步几乎是一场噩梦。

最好的办法是在服务器端把参与者的状态和信息全部收集起来，构建一个**房间**概念，这样所有的参与者都可以从服务器获取相同的信息，而不用单独进行维护。

通知系统

当有新的参与者进入房间或​​者有人离开时，需要向房间内的人广播信息，这就需要一个好的IM系统来发送和接收消息。例如，当D进入时，可以向房间内的其他成员广播“我在”事件，这样ABC就可以在自己的UI上显示D的视频画面。

添加房间管理和通知系统后，我们可以结合微信小程序的基础能力，构建各种功能强大、逻辑复杂的小程序应用。

一路上

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

小程序音视频技术体系图

第一步，把事情简单化，所有的音视频解决方案，都分解成上行和下行两个基本行为，最基本的在线直播功能，就是通过两个标签和的简单组合来实现的。

然后通过加速线路，控制延时，将音视频的延时缩短到以内；

后来我们又引入了噪音抑制、回声消除等声学处理模块，使得一个通道变成两个成为可能，这就构成了最简单的视频通话能力。

最后我们增加了房间服务和状态同步通知，将双通道音视频转化为多通道音视频，进一步扩大了应用范围。

图中UI截图是我们腾讯视频云小程序Demo的界面截图，您可以在微信小程序中搜索“腾讯视频云”即可体验以上基本功能。

关注“智小程旭”公众号，微信后台回复“开发”，即刻获取全套小程序开发技能。