如何在小程序上增加音视频？

　2017年第四季度，腾讯云终端团队和微信合作，将腾讯云多年积累以SDK的形式落到微信上，从而开放了音视频能力。今天我主要跟大家介绍一下关于小程序的音视频，然后先做一下自我介绍。我也是腾讯云的同学，我们有一个非常不错的视频云，大家看到的直播、点播包括实时通话等场景应用都是在腾讯视频云落地的。我这边主要负责视频云终端技术这一块的事情，这一块今天也是围绕着老本行，跟大家谈一谈我们怎么样把音视频技术在小程序上进行落地。

　　今天主要是这几个部分，首先我们为什么要干这个事情？因为很多朋友就说腾讯云讲这个东西一点不感兴趣我不要听，因为并没有那个需求。其实我们可以看一下再说，这里面有很多细分的场景，有很多的商业价值和挖掘空间的。

　　值得注意的是今天的主题主要讲原理，讲一下技术路线。这一块主要是分享了，没有太多打广告的意思。如果大家有时间可以耐心的听下来，我觉得是不错的。如果你之前没有了解过，我估计听下来你也可以成为半个音视频专家。最后我讲一讲快速的落地，黄老师刚说的WEBRTC我一直在用，它可以实现一个目标，让我一个人可以搞定一个很不错的东西，在此之前至少是两个人，一个前台一个后台。

　　小程序的优势大家都知道，没有安装成本，比如说平时去刷的百度的贴吧，你点开广告你就没有欲望去继续下载了。这些广告都是需要闪现的，到底有多少人装？这是一个数学游戏。

　　还有一些低频刚需的场景，如果你真的解决了APP的安装问题，比如说刚才黄老师也讲的摩拜单车，你以前没装APP，如果在多装这个APP真的会崩溃。所以这个时候这个场景就很有用。还有一个其实刚才说过，广告效应非常好，大家有没有刷朋友圈的时候遇到长按扫描二维码进入我们的介绍页或者介绍的小程序的情况，有很多的广告在小程序就是通过这个方式进行传播的。第一是在朋友圈传播的效果其实会容易，第二信息的传递比较好。

　　它既然有那么多好处，我这边自然会想我们的音视频这一块田地怎么去结合，如何去做这么好的场景？说我们有直播、点播还有音视频的应用。直播如映客、花椒、斗鱼等，点播如优酷、土豆、爱奇艺，还有视频，微信上大家开视频会议。这些场景结合微信小程序有很大的市场前景？

　　双面音视频

　　说一下双面音视频，如果两个人聊就是两个朋友或者关系很好的人，这叫交友。如果不认识的人聊，以前叫裸聊，这都是不健康产业。但是如果放在企业里面，放在客服系统上这就完全不一样了，比如在线的客服系统，就有很大的优势，相比于传统的一些电话系统。我们可以看这样一个场景，早晨开车上班，迟到了老板没有等到回报，很着急。这时候车擦了，你等着定审的人过来，堵塞交通一两千就罚掉了。这个时候特别希望在线视频就可以解决。我们有很多客户尝试使用APP解决相关问题。但是很多用户抵触心理很强。如果这个时候你跟他说点个链接，在小程序里面搜一个什么什么保险，就可以完成这个简单的流程，后续接入视频通话，在这里拍一个照，然后那边定损人员一看你权责，他权责，这样保险公司和用户都很喜欢。

　　再讲一个远程评审，之前我们跟法院合作还有这样的案例。法院在大城市里，原告被告分别是农村两个小伙子，因为一点琐碎的事情吵架。其实法院只需要简单远程做一个事情，这么一点小事，你非到大城市里面打官司，一场官司没有那么容易打的。后续还要来回跑好几趟。现在农村4G和WIFI覆盖面也不错，法院只需要远程解决的事情，这里面有很大的商业空间和利润空间。

　　这些场景有很多的可以结合的点，我们的功能非常多，直播、点播都有，这个成本很低。

　　原理

　　我今天的重点就是讲一下原理，这一部分其实是重头戏。

　　这一块实际上在讲这个东西之前先说一下故事，跟微信团队也是有一个合作，当时我们希望腾讯云的技术直接放在微信的APP里面去。微信的同学就说我们提一些要求，就是像美国的国防部给别人去提要求，你需要达到多少技术指标，要求非常高的。微信提了几个标准，第一简单易用，第二要可扩展、可定制，我们的开发者可以拿到做各种场景的需求，第三实现音视频直播，第四，第五、第六、第七、第八、第九，我觉得这个需求太夸张了。

　　我这个人喜欢被挑战。你知道前苏联卡拉斯克夫曾经做了一把很牛的枪，这个武器在当时越南打阻击主要的武器，其实很大一个就是在设计理念上简单。像阿富汗那个小作坊几个老头就可以做。第二可靠；从不卡壳，关键时刻站住，一按就出来。不像印度造的枪，该打的时候打不出火来。威力很厉害。这把枪的设计理念我们应该去延续。

　　我们也在想，我们能不能去想想怎么设计这样一个理念，做这样很有优势的一个解决方案。最后结果当然比较理想，我们算是朝这个方向做了一些努力，也做了一些成绩。

　　首先技术架构就不说了，说说我们在微信里面内嵌了音视频组件吧，它是一个免费使用的版本，这个产品我们已经打磨了已经有两年多了，而且现在每个月都一两次更新。而且这里面SDK有两部分组成的，一个是音视频上行，另一个是音视频下行。

　　上行解决什么问题？上行叫推流，就是把本地的画面经过采集然后进行预处理，有人可能问处理要干什么？比如说美颜，这个很接地气的需求。再有要降噪，声音也需要降噪，可能音频其他背景很不好的情况下，听着也很不舒服了。然后再进行编码，我们需要以数量级十倍、二十倍把这个数据量压下去。再最后通过网络模块传到云端上去，现在基本上音视频研发都是依赖于这个的，但是效果和稳定性都比较查，不过现在网络成本已经开始降下来了，所以没必要再这样做了，现在直接就可以使用腾讯云。

　　然后下行，俗称拉流。原来上去的，现在下来，这个就叫播放。播放的话，其实就是从上至下，尤其是网速时快时慢时候，你会发现播放一卡一卡的，这种效果优化就不好，所以一定要加一个缓存，像一个蓄水池一样，合适的时候在优化，再进行解码，进行渲染。

　　有了上行，有了下行，有了播放，这就是架构。微信里面从标签到下面的SDK，再到网络再到另一端，这样就把这个链路串起来了。有了链路之后我们相当于有了两个基本的原则，就可以组合成多彩的事件。

　　技术演化，第一个就是播放对应上行，有了这两个标签之后我们靠云在中间就进行直播功能，就是大家看到映客、斗鱼、花椒等可以体验一下，基本上可以把该有的东西都做到，包括各方面的这些消息、还有各方面的延迟都是很好的，但是全屏效果不如做的原来的做的好。

　　这个方案为什么我说要加个云呢？我手里的这个麦，是整个会场的音频系统的一个部分，它负责把声音采过去，其实就像我刚才说的推流，进行一个处理。我估计在这个地方会有一个数字处理电路，会对声音进行一些清洗相应的整合，然后再教给后面的系统进行逐级放大。逐级放大是什么程序？可能我们腾讯云的全国上万台机器，全国各地都要看要扩大到一万台机器。你可以把云当成信号放大器，将一个单点的圆，无限的拷贝，让每一个人都能在就近的一个机房里面拉到一个高质量的音视频流，这样就可以解决卡顿的问题和流畅性的问题。

　　当您有了这样一个放大器之后，加上上行和下行，才能构建出一个高并发的解决方案。好处是比较便宜，像腾讯云价格可以看一下，价格很低。再加上它的质量很不错，而且可以做多清晰度的切换，但是因为有很大的数据，所以延迟至少2秒以上。

　　接下来我们就开始做能力+，做升级。直播场景搞出来了，但是DS场景还需要做的。DS场景什么时候需要？我现在要做远程调控，2017年在线夹娃娃场景，要求是极其苛刻，这个延迟是极高的，300毫秒行不行？如果你能做到100毫秒真的很牛，所以我们要加科技点了。我们想了两个方案，一个是UDP加速，一个延时控制。娃娃机是一个远程遥控，正常看是2到5秒，真正的机器要求是500毫秒以内把它传递到机器那面过去。这个其实我们要需要做什么样额外的科技点的积累呢？UDP协议当时设计者设计的时候是本着天下为公的理念。所以大家的理念就是你让一让，我让一让，这个场景就变成一个问题，稍微一堵，它就开始网速就下来了。你来做高延时的场景是会被伤掉的，有时候非常希望脾气硬一点。那怎么办呢？我们可能要换一下，我用UDP。当网络差我也要继续发。第二个颜色控制，这个功能其实让我们腾讯云在去年年底做风险大会的时候，解决方案是傲视群雄的，延迟控制不用对着时间戳，因此我们保证了直播到观众的延迟控制在3s以内。

　　有了这样一个链路，远程的遥控、远程的互动都可以做，但是这还是单向的。

　　有了单向的东西，又延迟又很低，我跟你一路延迟很低的单向，你再跟我一路，咱们这个事情是不是就搞定了？所以专业音视频功能就出来了？其实没有那么简单，我们还需要修很多的科技点。噪声、消除、回音抑制等。

　　咱们先说一路上行，一路下行是单向，两路就RTC模式，现在模式选择RTC之后，两边的延迟都是500毫秒，双向通话就可以解决了，背后在技术层面我们需要做这样一个东西。比如说假设我的延迟有点大，那么延迟控制小一点不行吗？但是数据丢了效果一定非常差。大学的时候老师会说音视频解决方案你用UDP就行了，但是压缩后的编码和数据真要丢了就解不出来了，所以真不能丢。那怎么办呢？我们可能就是要在你察觉不到的地方把时间给缩回去。我现在在说四五十分钟的演讲，中间漏掉一两个字大家都能接受。我们做的是删掉多余的时间空隙，人说话里面是有大量的空隙是可以做文章的。比如说我们可以在这各点上做点文章，把我们认为不太重要的数据切掉，这样的情况下声音也没有褶皱，，感觉跟原来有一点点不一样，但是内容很正常。所以在这种情况下我们的时间也压回去了。

　　双向音视频的时候有时候会有破音、爆音的问题，解决这种问题的时候功能学的角度也是比较简单的，我要把声音变的柔和一点，做一些回声抑制，比如说我现在说话，你看他没有一个劲的循环，其实里面是有回音消除的电子元件的。我们要上就是软件解决方案，就是把本来播出去的声音给它消除掉，这样就会做到回声抑制，否则两个人打电话就会听到无限回声。

　　以上声学处理的部分不是一两天能搞定的，，这一块以你可能要养一个研发团队，这个团队有很多声学专家、音视频专家，现在小程序有好处就是RTC搞定。我觉得我们还是做了一件相对比较技术普世的东西。

　　有了这个双向音视频之后，我们继续把技术往上提，把房间这个IM也拉下来。因为双人你一路我一路，很简单，很清晰，多人的时候，就很麻烦，所以不能这样玩，所以需要一个总控系统，去协调各个端的状态，协调各个端的输出，然后包括谁说话，谁不说话进行一些协调，这个就需要有一个房间的概念，房间的管理。再加上IM，做的程序，就可以把多人的解决方案搞定了。

　　其实多人解决方案里面服务端要多做一些事情，还需要一个类似于房间管理的概念，把A、B、C三个人拉里面，进行状态同步。我们其实在小程序里面没有内置这么多的东西，其实有一点是说微信以简单为主，不要搞的那么复杂。所以就提了一个rtcroom解决方案，就是附及一些额外的逻辑，这一块在腾讯云移动直播解决方案里面是可以找到相应的东西的，或者在小程序音视频里面也可以找到相应的资料。

　　这一部分说完我们整个技术路线就走下来了，从简单的直播到DNS再到双向，其实大部分音视频的场景都可以涵盖了。但是这个时候有人跳出来跟我说，我们做Webrtc的，苹果也跟它搞在一起了。这个时候我们想说一下区别，然后我们是怎么优化Webrtc的。

　　区别的话，现在你如果直接在微信里面去做Webrtc还是有很多限制的，第一个浏览器内核，在不同的手机可能不太一致，碎片化严重。苹果是内嵌，如果这个东西你要用的话，小程序没办法实施。目前在Webrtc这一块它的任何功能的加持都是苹果和谷歌两边达成一致，这个过程是很漫长的过程。所以在小程序这一块就是做一些接地气功能，不会去看苹果爷爷和谷歌爸爸的眼色。

　　再有就是说在设计理念上也会有一些不同，Webrtc很多理念都是基于不可靠链构的，我们小程序是可以用比较廉价的云解决的，这是跟Webrtc的对比。

　　我们不是竞争，我们其实是可以跟Webrtc可以搞成一家的。腾讯云后台最近打算把两套系统打通，微信4月份版本发布之后，你们就可以在小程序上和Chrome进行互通。这一部分有点难，有兴趣的朋友可以看一下解决方案还是有技术含量的。

　　说到打通之后，这涉及到另一套解决方案，小程序+Webrtc，这一块在原来基础上把协议换成rom打头的就可以了。

　　快速上手，原来需要给他搭后台，搭前台，非常痛苦，现在大家可以直接在黄老师的系统上直接可以找到相应的包，我们可以把里面的包传上去。而且调试特别方便。我今天分享就到这儿，看看大家有什么问题。

　　QA:

　　Q：我作为一个个人开发者，比如看有时候个人开发者一些开放内幕，比如说音视频相关的这些没有开放，我想开发这样的产品，它需要办理资质的成本很高。所以小程序在音视频这方面将来会不会更开放，让成本更低一点。

　　A：好像有一些比较简单的，你看直播内幕是很难。实际上我是非常希望它全开放的，我也主动找了好几次微信的领导谈这个事情。微信的同学给我说了一个很现实的担忧，以前做APP如果出现涉黄涉政跟APP没关系，所以这个问题他们是非常谨慎的。这里面其实资质的提交核心就是一个问题，如果出现问题靠这个资质我们会在这边做一个控制手段，它只是想做一个自保的方案。个人开发者是个人相关调试的能力，还有一些内幕的话，相应来说其实是比较容易去提交上去的。

　　Q：点播和直播都会在中间加上缓存做吗？

　　A：实际上缓存是比较少的，像优酷、土豆是点播，视频是传上去，你可以从中间看，开头看，这是点播。直播是我现在摄象头开着，实时往上传，如果你多了之后可能产生跟高的延迟。腾讯内网是打通的，没必要做那么多缓存，真正缓存主要是大家刚刚看到播放这一块，这一块会有我们的缓存区，这里面有一系列的优化算法，这个是多大然后来去做缓存。其实整个系统里面唯一的缓存就这一块。

　　Q：我刚才想加缓存就是延迟性变高了。还有常老师提到涉黄涉政这一块，您在演讲的时候说对声音处理就可以做到每秒钟间隔就可以停调了，做视频的时候，会有一些美颜，这样这些内容你们的把控性其实很高的。这样的话，在中间到了类似于关卡那种，检测出涉黄涉政的直接就可以屏蔽掉了。

　　A：现在有这种系统，这种系统需要人为干预。我现在是这样一个态度，目前还没到完全撒手不管的状态，现在是有误报的，主持人可能是我的状比较黄，所以涉黄了，这就需要人为过一道，这里面就有延迟。先把人为举报到检测系统，观众越多的线路，你误报产生的代价越高。

　　Q：因为在做直播的话，虽然可以做一些涉黄、视频的处理，通过一些AI和监控，我们有没有可能做一些录播，如果一旦出现什么事情的话我们还要出现一些举证。您说的东西在我们平台上是有直接的需求的。

　　A：是录播吗？

　　Q：直播的情况下有没有可能录播？