腾讯技术分享：微信小程序音视频技术背后的故事
一、引言
微信小程序自2017年1月9日正式对外公布以来，愈来愈受到关注和重视，小程序上的各类技术体验也愈来愈丰富。而音视频做为高速移动网络时代下增加最快的应用形式之一，在微信小程序中也固然不能错过。本文来自腾讯视频云终端技术总监rexchang（常青）的技术分享，讲述的是微信小程序中音视频技术构思、设计和实现等方方面的内容，但愿能为你的音视频技术实践带来启发。php
若是您能微信小程序开发没什么了解，能够从这篇微信官方的《小程序开发简易教程》开始。html
学习交流：程序员
- 即时通信开发交流3群：185926912[推荐]web
- 移动端IM开发入门文章：《新手入门一篇就够：从零开发移动端IM》数据库
（本文同步发布于：http://www.52im.net/thread-1799-1-1.html）小程序
二、关于做者
rexchang（常青）：腾讯视频云终端技术总监，2008 年毕业加入腾讯，一直从事客户端研发相关工做，前后参与过 PC QQ、手机QQ、QQ物联 等产品项目，目前在腾讯视频云团队负责音视频终端解决方案的优化和落地工做。微信小程序
三、一次偶然的合做
2016年微信开始启动小程序内测以前，腾讯内部的各个团队就已经开始接到消息。咱们每一个人都能预感到小程序将会对移动应用场景产生很大的改变。但在当时，我也是刚加入腾讯视频云团队不久，对于这样的信息更多的是关注，而并没有太多细致的思考。缓存
2017年伊始，随着大量客户的咨询，我以及我所在的腾讯视频云团队都开始意识到这里的需求特别的旺盛。但因为精力有限，以“小团队大成绩”著称的微信工程师团队很难有精力覆盖全部的应用场景，在音视频这里，小程序仅提供了一些基础的采集和播放能力，好比你们最为熟知的 video 标签就是采用了系统播放器来实现，因此只能支持 HLS 高延时直播和视频点播功能。安全
而就在此时，腾讯视频云的 SDK 产品在通过了一年多的打磨优化以后，已经像是二战初期的零式战机，随时准备“砍瓜切菜”。这里和合做机会虽然不定，但咱们团队依然坐上了从深圳总部开往广州 T.I.T 的班车。服务器
通过屡次的沟通，以及 jianx 的努力帮助下，这个合做虽然偶然且充满了各类不肯定，但最终达成。
幕后：音视频小程序诞生在2017年4月一辆从深圳开往广州的C7172列车上
四、技术的挑战
在音视频应用场景下，两个团队可以达成合做天然是个好事情，可是微信的市场地位也决定了这是一个不容儿戏的战场。
因此咱们所面临的挑战也异常严峻：
1）接口必须简单易用，最好一两个标签就能解决问题；
2）知足多种应用场景，既要支持直播又要可以支持实时视频通话；
3）功能必须可扩展，开发者能够根据自身的须要构建出各类个性化应用场景；
4）可维护性好，开发者可以自助排查一些技术问题，而不须要自己是个音视频专家；
5）安装包体积增量足够小，否则微信的安装包体积控住不住。
除了高标准的要求之外，时间也是一个很是不利的因素。整个项目留给咱们能够证实自身能力的时间只有两周，在短短两周的时间里，咱们须要在一个 G2C 项目落地且成功经过产品演示和方案验收。
五、化繁为简
面对这些挑战，我想到了苏联卡拉什尼科夫所设计的名枪 AK-47 ：
说 AK-47 是世界上最成功的单兵武器一点也不为过，这把枪全世界一共生产了约一亿支。它具备不俗的杀伤力和极为优秀的可靠性。从不卡壳，不易损坏，无论是沙漠仍是雨林，都能稳定地倾泻火力，而且操做还很是简单。
之因此这么成功，源于其所贯彻的简单实用的设计理念：回转式闭锁确保了安全性，杜绝了随机事故的可能性；结构简单易拆卸，所以要生产它并不须要特别精密的加工技术，也不须要投资巨大的生产设备，甚至一个普通小做坊就能开工生产。
没错，化繁为简，追求简单可靠，这就是咱们须要达成的目标。
达成上述的技术目标并不容易，须要咱们团队一步一步的攻克技术难关。
六、攻克技术难关之上行和下行
首先，咱们要对腾讯视频云现有的音视频体系进行拆解和抽象，也就是把整个体系打散成一个个积木，其中最重要的两块就是：音视频上行（push）和音视频下行（play）。
6.1 音视频上行（PUSH）
就是把本身手机上的声音和画面实时的上传到云端。咱们将这部分能力用视频云 SDK 进行实现，并封装成一个叫作 的标签。
SDK 内部实现机制如上图所示：首先，咱们要对摄像头的画面进行捕获，对麦克风的声音进行采集。可是，原生采集和捕获的画面和声音是须要进行预处理的，直接采集的画面可能有不少噪点，因此咱们要进行图像降噪；好比， 原生采集的人像里，皮肤可能并不符合人们的预期，因此咱们须要进行磨皮和美颜；直接采集的声音可能也有不少的环境噪音，因此咱们须要进行前景和后景音的分离而后进行底噪抑制。
通过预处理以后的画面和声音相比于原始采集的通常会有较大改善，由于全部的预处理都是以“讨好”人类的视听体验为目的，因此这一看似不起眼的部分会吸引不少公司在其上作很多的技术投入。举个身边的例子，以 LCD 平板电视为例，SONY 的 LCD 产品线都没有自家的液晶面板（以台湾和大陆液晶面板为主），却能在整体效果上一直领先其它公司，其背后的秘密就是在图像处理（基于图像数据库作超分辨率显示）和背光技术（全部动物的眼睛都是对亮度最为敏感）上的不间断的积累和投入。
画面和声音都通过“粉饰”以后，就能够送给编码器进行编码压缩了。编码器的工做是将一张张的画面和一段段的声音压缩成 0101001... 的二进制数据，而压缩后的体积要远小于压缩前。最后要作的工做就是将编码后的数据经过网络模块发送出去。在在线直播场景中，通常采用的网络协议都是基于TCP的，而在实时通话场景中，所采用的网络协议则是 UDP 为主。
6.2 音视频下行（PLAY）
也叫播放，就是从云端把编码后的音视频数据实时下载下来并实时的播放，这样一来，您就能看到远程的画面，听到远程的声音。一样的，咱们将这部分能力用视频云 SDK 进行实现，并封装成一个叫作 的标签。
SDK 内部实现机制如上图所示：来自云端的数据会直接送给网络模块，但网络不是完美的，总会有时快时慢的波动，甚至会有可能发生阻塞和闪断。若是服务器来一段数据， SDK 就播一段数据，那么网络稍微一波动，画面和声音就会表现出卡顿。咱们采用抖动缓冲（VideoJitterBuffer）技术解决这个问题，就像是为网络过来的数据准备一个小的蓄水池，音视频数据先在这里暂存一小会儿再送去播放，这样就能够在网络不稳定时有必定的“应急”数据可使用。
数据通过缓冲之后，就能够送给解码器进行解码，解码就是把压缩后的音视频数据还原成图像和声音，而后进行渲染和播放。咱们采用了 openGL 进行画面的渲染，使用 iOS 和 Android 的系统接口来播放声音。
6.3 信号放大器
有了这两个简单的标签，咱们就能够进行初步的组合，构建出第一个最简单的应用场景：在线直播。
在线直播是一个很是经典的单向音视频场景，您只须要简单的将两个标签组合在一块儿便可， 负责将本地画面和声音实时上传到腾讯云， 则负责从云端实时拉取音视频流。
若是是简单的一路上行 + 一路下行，那么咱们随便搭建一个中转服务器就能够解决问题了，但这样只能在很小的范围内实现高质量的直播服务，真正要作到高并发和流畅无卡顿，就须要一个强大的视频云。
视频云在这里的做用就像一个**信号放大器**，它负责未来自 的一路音视频进行放大，扩散到全国各地，让每个 都能在离本身比较近的云服务器上拉取到实时且流畅的音视频流。因为原理简单、稳定可靠且支持几百万同时在线的高并发观看，因此从在线教育到体育赛事，从游戏直播到花椒映客，都是基于这种技术实现的。
但在线直播方案只能应用于解决单向音视频问题，由于它有个明显的问题，就是延时通常都是在 2秒 - 5秒左右，这是使用 标签配合腾讯云视频云能够达到的效果。若是是video标签，这个延时会更长，能够到 20 秒以上，那么在一些对时延要求很苛刻的场景下就再也不适用了。
七、攻克技术难关之把延迟下降
在安防监控的场景里，家用 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 等基础能力组合在一块儿，构建各类功能强大、逻辑复杂的小程序应用。
十、一路走来
一路走来，你们能够看到咱们在小程序音视频的技术体系上所作的种种努力能够用以下的技术图谱勾勒出来。
总结一下，咱们的实现思路就是：
1）首先是化繁为简，将全部的音视频解决方案拆解成两个基础行为：上行和下行，并经过两个标签 和 的简单组合，实现最基本的在线直播功能；
2）以后是经过加速线路和延时控制，将一路音视频的时延缩短到 500ms 之内；
3）再以后，咱们经过引入噪声抑制和回声消除等声学处理模块，让一路变两路成为了可能，这也就构成一个最简单的视频通话能力；
4）最后，咱们又经过加入房间服务和状态同步通知，将双路音视频变成了多路音视频，从而将应用范围进一步扩大。
图中的 UI 截图使咱们腾讯视频云小程序Demo的界面截图，你们经过在微信小程序里搜索“腾讯视频云”就能够体验上述基础功能了。
若是您但愿本身也动手来试一试，不妨看一下咱们的技术文档：
小程序入门导读：https://cloud.tencent.com/document/product/454/12517
标签使用指引：https://cloud.tencent.com/document/product/454/12518
标签使用指引：https://cloud.tencent.com/document/product/454/12519
双人或多人音视频：https://cloud.tencent.com/document/product/454/15364
直播+连麦：https://cloud.tencent.com/document/product/454/15368
WebRTC互通：https://cloud.tencent.com/document/product/454/16914
常见问题：https://cloud.tencent.com/document/product/454/13037
附录1：微信、QQ的文章汇总
[1] QQ、微信团队原创技术文章：
《腾讯技术分享：腾讯是如何大幅下降带宽和网络流量的(图片压缩篇)》
《腾讯技术分享：腾讯是如何大幅下降带宽和网络流量的(音视频技术篇)》
《腾讯技术分享：Android版手机QQ的缓存监控与优化实践》
《微信团队分享：iOS版微信的高性能通用key-value组件技术实践》
《微信团队分享：iOS版微信是如何防止特殊字符致使的炸群、APP崩溃的？》
《腾讯技术分享：Android手Q的线程死锁监控系统技术实践》
《QQ音乐团队分享：Android中的图片压缩技术详解（上篇）》
《QQ音乐团队分享：Android中的图片压缩技术详解（下篇）》
《腾讯团队分享 ：一次手Q聊天界面中图片显示bug的追踪过程分享》
《微信团队分享：微信Android版小视频编码填过的那些坑》
《微信团队披露：微信界面卡死超级bug“15。。。。”的前因后果》
《月活8.89亿的超级IM微信是如何进行Android端兼容测试的》
《微信客户端团队负责人技术访谈：如何着手客户端性能监控和优化》
《微信团队原创分享：Android版微信的臃肿之困与模块化实践之路》
《微信团队原创分享：微信客户端SQLite数据库损坏修复实践》
《腾讯原创分享(一)：如何大幅提高移动网络下手机QQ的图片传输速度和成功率》
《腾讯原创分享(二)：如何大幅压缩移动网络下APP的流量消耗（下篇）》
《腾讯原创分享(三)：如何大幅压缩移动网络下APP的流量消耗（上篇）》
《如约而至：微信自用的移动端IM网络层跨平台组件库Mars已正式开源》
《开源libco库：单机千万链接、支撑微信8亿用户的后台框架基石 [源码下载]》
《微信新一代通讯安全解决方案：基于TLS1.3的MMTLS详解》
《微信团队原创分享：Android版微信后台保活实战分享(进程保活篇)》
《微信团队原创分享：Android版微信后台保活实战分享(网络保活篇)》
《Android版微信从300KB到30MB的技术演进(PPT讲稿) [附件下载]》
《微信团队原创分享：Android版微信从300KB到30MB的技术演进》
《微信技术总监谈架构：微信之道——大道至简(PPT讲稿) [附件下载]》
《微信海量用户背后的后台系统存储架构(视频+PPT) [附件下载]》
《微信异步化改造实践：8亿月活、单机千万链接背后的后台解决方案》
《架构之道：3个程序员成就微信朋友圈日均10亿发布量[有视频]》
《微信团队原创分享：Android内存泄漏监控和优化技巧总结》
《微信团队原创Android资源混淆工具：AndResGuard [有源码]》
《移动端IM实践：Android版微信如何大幅提高交互性能（一）》
《移动端IM实践：Android版微信如何大幅提高交互性能（二）》
《移动端IM实践：WhatsApp、Line、微信的心跳策略分析》
《移动端IM实践：谷歌消息推送服务(GCM)研究（来自微信）》
《信鸽团队原创：一块儿走过 iOS10 上消息推送(APNS)的坑》
《腾讯TEG团队原创：基于MySQL的分布式数据库TDSQL十年锻造经验分享》
《微信多媒体团队访谈：音视频开发的学习、微信的音视频技术和挑战等》
《了解iOS消息推送一文就够：史上最全iOS Push技术详解》
>> 更多同类文章 ……
[2] 有关QQ、微信的技术故事：
《技术往事：微信估值已超5千亿，雷军曾有机会收编张小龙及其Foxmail》
《2017微信数据报告：日活跃用户达9亿、日发消息380亿条》
《技术往事：创业初期的腾讯——16年前的冬天，谁动了马化腾的代码》
《技术往事：史上最全QQ图标变迁过程，追寻IM巨人的演进历史》
《开发往事：深度讲述2010到2015，微信一路风雨的背后》
《开发往事：记录微信3.0版背后的故事（距微信1.0发布9个月时）》
《前创始团队成员分享：盘点微信的前世此生——微信成功的必然和偶然》
《即时通信创业必读：解密微信的产品定位、创新思惟、设计法则等》
>> 更多同类文章 ……
附录2：更多音视频开发资料
《即时通信音视频开发（五）：认识主流视频编码技术H.264》
《即时通信音视频开发（九）：实时语音通信的回音及回音消除概述》
《即时通信音视频开发（十）：实时语音通信的回音消除技术详解》
《即时通信音视频开发（十一）：实时语音通信丢包补偿技术详解》
《即时通信音视频开发（十三）：实时视频编码H.264的特色与优点》
《即时通信音视频开发（十五）：聊聊P2P与实时音视频的应用状况》
《即时通信音视频开发（十六）：移动端实时音视频开发的几个建议》
《即时通信音视频开发（十七）：视频编码H.26四、VP8的前世此生》
《学习RFC3550：RTP/RTCP实时传输协议基础知识》
《基于RTMP数据传输协议的实时流媒体技术研究（论文全文）》
《还在靠“喂喂喂”测试实时语音通话质量？本文教你科学的评测方法！》
《实现延迟低于500毫秒的1080P实时音视频直播的实践分享》
《技术揭秘：支持百万级粉丝互动的Facebook实时视频直播》
《理论联系实际：实现一个简单地基于HTML5的实时视频直播》
《首次披露：快手是如何作到百万观众同场看直播仍能秒开且不卡顿的？》
《腾讯音视频实验室：使用AI黑科技实现超低码率的高清实时视频聊天》
《七牛云技术分享：使用QUIC协议实现实时视频直播0卡顿！》
《实时视频直播客户端技术盘点：Native、HTML五、WebRTC、微信小程序》
《微信多媒体团队访谈：音视频开发的学习、微信的音视频技术和挑战等》
>> 更多同类文章 ……
（本文同步发布于：http://www.52im.net/thread-1799-1-1.html）
- 1. 互动影视《他的微笑》技术er背后的故事
- 2. 腾讯FPGA云-背后的技术
- 3. 为你揭秘小程序音视频背后的故事......
- 4. 小程序音视频背后的故事
- 5. 仿腾讯视频-微信小程序
- 6. 微信团队分享：微信每日亿次实时音视频聊天背后的技术解密
- 7. 腾讯微信技术架构
- 8. 直播技术视频教程分享
- 9. 腾讯实时音视频（TRTC）研究技术文档
- 10. 音视频编解码技术（二）：AAC 音频编码技术
- 更多相关文章...
- • XML 相关技术 - XML 教程
- • Hibernate的快照技术 - Hibernate教程
- • Docker容器实战(一) - 封神Server端技术
- • 三篇文章了解 TiDB 技术内幕——说存储
-
每一个你不满意的现在，都有一个你没有努力的曾经。