在2017年的第四季度，腾讯云终端团队携手微信，将腾讯云长期积累的技术以SDK的形式成功应用于微信平台，此举使得音视频功能得以开放。今天，我将重点向大家阐述小程序中的音视频功能，并先简单自我介绍一下。我是腾讯云的一员，我们团队拥有一款非常出色的视频云服务，大家所看到的直播、点播以及实时通话等应用场景，都是基于腾讯视频云实现的。我主要负责的是视频云终端技术领域的工作，今天的话题依旧紧扣我的专业领域，我将与大家探讨如何在微信小程序中实现音视频技术的实际应用。

今天主要涉及这几个方面，首先，我们为何要着手这项工作？不少朋友表示对腾讯云所讲述的内容毫无兴趣，不愿聆听，理由是缺乏相关需求。实际上，我们不妨先看看再说，其中包含众多细分场景，蕴藏着丰富的商业价值和发展潜力。

需注意的是，今日讨论的核心是基本原理，并对技术路径进行了阐述。此部分内容以分享为主，广告成分相对较少。若各位能抽出时间细心聆听，我认为这会是一次不错的选择。即便您对此领域此前并无涉猎，相信经过一番聆听，您也能对音视频领域有所掌握，成为半个专家。最后，我要谈谈快速实施的方法。黄老师所提及的方法，我一直在实际操作中运用。这种方法能够帮助我独立完成一件相当不错的工作。在此之前，至少需要两个人共同完成，一人负责前台，另一人负责后台。

大家对小程序的优点都有所了解，它无需安装，就像我们平时浏览百度贴吧时，一旦点击广告，就很少再有继续下载的冲动。这些广告往往需要迅速闪现，那么，究竟有多少人会去安装呢？这实际上是一场数字游戏。

存在一些需求频率较低但至关重要的场景，若能成功解决APP安装难题，例如黄老师提到的摩拜单车案例，以往未曾安装该APP的用户，若额外安装此应用可能导致系统崩溃。在这样的情况下，该功能显得尤为实用。实际上之前已经提及，广告的推广效果相当显著，大家是否在浏览朋友圈时遇到过通过长按扫描二维码进入我们介绍页面或小程序的情景？众多广告在小程序中正是通过这种方式进行传播的。首先，朋友圈的传播效果相对容易实现；其次，信息的传递效果也较为理想。

既然它拥有众多优势，我自然会思考如何将我们的音视频领域与之融合，创造出优质的体验场景。我们拥有直播、点播以及音视频应用等多种形式，如映客、花椒、斗鱼等直播平台，优酷、土豆、爱奇艺等点播平台，以及微信上的视频会议功能。这些场景与微信小程序的结合，是否具有广阔的市场潜力？

双面音视频

谈谈双面音视频，若涉及两人对话，通常为朋友或亲密关系，这可视为交友行为。然而，若涉及陌生人之间的交流，过去称作裸聊，这些都属于不健康的产业。然而，若将这种视频应用于企业，特别是在客服系统中，情况就截然不同了。例如，在线客服系统便具有显著优势，相较于传统的电话系统。在这样一个情景中，清晨驾车赶往工作岗位，由于迟到，老板未能如愿得到汇报，显得十分焦虑。这时，车辆不幸发生了擦碰，不得不等待定损人员到来，而由此造成的交通拥堵，可能导致罚款高达两千元。此刻，内心迫切地希望有在线视频服务可以解决这一问题。实际上，我们已有多位客户尝试通过使用应用程序来处理此类问题。然而，不少用户对此表现出强烈的抵触情绪。若此刻向他提及在应用内查找相关保险的链接，通过搜索便能轻松完成操作，接着进行视频通话，在此环节拍摄照片，对方定损人员仅需审视双方的权责，如此一来，保险公司与用户均感满意。

提及一个远程审判的例子，我们之前与法院有过类似的情况。那家法院位于繁华的大都市，原告和被告均为来自农村的年轻人，他们因一些微不足道的小事发生争执。实际上，法院只需进行简单的远程操作，这类小事根本无需当事人长途跋涉至大城市打官司。毕竟，一场诉讼并非易事，而且后续还需多次往返。目前，我国农村地区4G和WIFI的覆盖范围已经相当广泛，对于法院可以通过远程处理的事项，其中蕴藏着巨大的商机和盈利潜力。

这些场景中存在众多可融合之处，我们的功能十分丰富，涵盖了直播和点播等多种形式，而且运营成本相对较低。

原理

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

在讲述这个主题之前，先来聊一聊背后的故事。我们与微信团队有过合作，当时我们期望将腾讯云的技术直接嵌入微信APP中。微信的同事们提出了一些要求，这些要求就如同美国国防部对他人提出的要求一般，需要达到相当高的技术标准。微信提出了多项要求，首先需操作简便，其次需具备扩展性和定制性，以便开发者满足不同场景的需求；再者，需支持音视频直播功能。至于第四、第五、第六、第七、第八、第九点，我认为这些需求过于夸张。

我热衷于接受挑战。你可能听说过前苏联的卡拉斯克夫曾设计出一款性能卓越的枪械，这款武器曾是越南战争中重要的防御武器。其设计理念的一大亮点在于其简单性，就如同阿富汗小作坊里的几位老匠人也能轻松制作。其次，它的可靠性极高，从未出现过卡壳问题，关键时刻总能稳定发挥，一键即可发射。相比之下，印度制造的枪械在关键时刻往往无法正常射击。这款枪械的强大威力令人印象深刻。我们应该继承并发扬这种设计理念。

我们也在思考，如何构思一个这样的理念，打造一个极具优势的解决方案。最终，结果自然令人满意，我们在这方面付出了努力，并取得了一定的成绩。

关于技术架构的部分暂且不提，接下来我要说的是，我们在微信中集成了音视频功能模块。这个模块是免费提供的，我们对其进行了超过两年的精心优化，并且每月都会进行一到两次的更新。此外，该模块的软件开发工具包（SDK）由两部分构成，一部分负责音视频的上传，另一部分则负责音视频的下载。

上行技术解决了哪些问题？所谓的上行，即推流，它涉及将本地画面先进行采集，再进行预处理。有人会疑问，预处理究竟有何作用？例如，美颜功能就是一个非常贴近实际需求的应用。此外，还需要进行降噪处理，声音同样需要降噪，以防在音频背景杂乱的情况下，听众感到不适。接下来，还需进行编码，我们的目标是将其数据量压缩至原来的十分之一、二十分之一。最终，数据将通过网络传输至云端，目前音视频的研发工作大多依赖这一方式。尽管如此，其效果和稳定性尚不尽如人意。然而，随着网络成本的逐渐降低，我们已无需继续采用这种方式。目前，直接使用腾讯云即可满足需求。

接着向下传输，通常称作拉流。之前上升的内容，现在转为下降，这个过程我们称之为播放。在播放过程中，尤其是网络速度不稳定时，你可能会遇到播放画面出现卡顿的情况，这种效果并不理想。因此，必须加入缓存机制，就像一个蓄水池，在适当的时候进行优化处理，然后再进行解码和渲染。

有了上行的存在，有了下行的加入，还有播放的功能，这才构成了整个架构。在微信中，从标签开始，到下面的SDK，再到网络连接，以及另一端，如此便将整个链路串联起来。一旦拥有了这条链路，我们便拥有了两个基本的原则，进而可以组合出丰富多彩的事件。

技术发展过程中，首先实现的是对上游内容的播放，随后借助云端技术，我们成功实现了直播功能。正如大家所熟知的映客、斗鱼、花椒等平台，用户可以亲身体验。这些平台基本上能够满足用户的需求，无论是消息传递还是延迟控制都表现出色。然而，在全屏效果方面，相较于之前的技术，仍有提升空间。

为何我提出要加入云端功能呢？我手中的麦克风，是会场音频系统的一部分，其主要功能是采集声音，正如我之前所述，这相当于进行推流处理。我推测此处可能存在一个数字处理电路，它会对声音进行清洗和整合，随后将处理后的声音传递给后续系统，进行逐级放大。那么，这个逐级放大的过程是通过何种程序实现的呢？或许腾讯云的设备遍布全国，数量已超万台，并计划进一步扩充至万台规模。您可以将云服务视作信号增强器，通过不断复制单个点的圆形范围，确保每个人都能在最近的机房获取到高品质的音视频流，进而有效解决卡顿和流畅度的问题。

拥有这款放大器后，通过结合上行链路和下行链路，便能够搭建起一个高并发处理方案。其优势在于成本较低，以腾讯云为例，价格相当实惠。此外，该设备品质优良，支持多种清晰度之间的切换。然而，由于数据量庞大，导致延迟至少在2秒以上。

现在我们着手进行能力+的升级工作。直播场景已经搭建完成，不过DS场景的制作还需跟进。DS场景的具体需求时间是什么时候？我目前需要实施远程控制，针对2017年的在线夹娃娃场景，其要求非常严格，延迟要求非常高，300毫秒是否可行？若你能达到100毫秒，那将非常出色。因此，我们需要增强技术支持。我们考虑了两种方案，一是采用UDP加速，二是实施延时控制。娃娃机操作依赖于远程遥控，通常耗时在2至5秒之间，而实际机器则需在500毫秒内完成信息传递。为了实现这一目标，我们需要积累哪些额外的科技知识呢？UDP协议的最初设计者基于共享资源的理念。因此，大家的共识是相互让步，这样一来，一旦网络出现拥堵，网速便会下降。在高延时的场景下进行操作可能会对设备造成损害，有时真希望自己能更坚定一些。那该怎么办呢？或许我们可以尝试使用UDP协议。即便网络状况不佳，我们也要坚持发送数据。至于颜色控制，这项功能在去年年底腾讯云举办的风险大会上，我们的解决方案堪称一枝独秀。我们无需关注时间戳进行延迟控制，因此能够确保直播信号传输到观众手中的延迟不超过3秒。

借助这条链路，我们能够实现远程操控以及远程交流，然而，目前这种操作仍然仅限于单方面的信息传递。

既然存在单向传输且速度较慢的设备，我和你之间的通信延迟都挺低，若你再次与我进行类似的单向通信，我们是否就能顺利解决问题？因此，专业的音视频功能应运而生？然而，事情并非如此简单，我们还需攻克众多技术难题。例如，噪声处理、回音消除以及回音抑制等技术。

我们先来谈谈，单程上行和下行是单方向的，而采用两路RTC模式时，一旦选择了该模式，双方的延迟均为500毫秒，这样双向通话的问题就能得到解决。在技术层面，我们需要实现一个这样的功能。例如，若我的延迟较高，能否将延迟控制得小一些？然而，如果数据丢失，通话效果必然非常糟糕。大学时期，老师常建议使用UDP来处理音视频解决方案，然而一旦压缩编码后的数据丢失，就难以恢复，因此绝不能随意丢弃。那应该怎么办呢？或许我们得在不引起注意的地方，将时间进行缩减。比如我现在正在进行的四五十分钟演讲，即便中间遗漏一两字，听众也能接受。我们致力于削减那些不必要的空白时间，实际上，人们在说话时存在着许多可以加以利用的空隙。例如，我们可以在这些地方稍作处理，将那些我们认为并非关键的数据进行删减，这样一来，声音听起来就不再有杂音，与之前相比略有不同，但整体内容依旧保持原貌。因此，在这种处理下，我们节省了大量的时间。

在进行双向音视频通信时，偶尔会遇到声音出现杂音或爆裂的情况。针对这类问题的解决，从功能学的角度来看相对直观。我需要调整声音的柔和度，并实施回声抑制措施。举例来说，当我说话时，你注意观察，他的声音并没有持续不断地回荡，实际上，其中已经内置了能够消除回音的电子部件。我们的目标在于提供软件解决方案，其核心功能是消除原本传出的声音，以此实现回声的抑制效果。若不采取此措施，当两人通话时，将不断听到持续的回声。

以上声学处理的环节并非短时间内可以完成，这需要组建一个研发团队，该团队由众多声学及音视频领域的专家组成。得益于小程序的便利性，RTC功能得以实现。我认为，我们实际上完成了一项具有普遍技术价值的工作。

有了这种双向音视频设备，我们便着手提升技术水平，并将即时通讯的房间功能也纳入其中。由于双人交流简单明了，但多人互动则变得复杂，因此不能继续采用这种方式。为此，我们亟需一个总控系统来统筹各端的状态和输出，同时还要协调谁发言、谁沉默等问题。这就要求我们建立一种房间概念，并对其进行有效管理。再加上IM，做的程序，就可以把多人的解决方案搞定了。

实际上，在多人解决方案中，服务端需要承担更多责任，并且引入一种类似于房间管理的机制，将A、B、C三人纳入其中，以实现状态的一致性同步。实际上，在我们的小程序中并未预先集成这些功能。事实上，微信的设计理念是以简洁为核心，尽量避免过于复杂。因此，我们提出了一种解决方案，即引入额外的逻辑元素；这部分内容在腾讯云的移动直播服务中有所涉及，同样，在小程序音视频相关资料中也能找到类似信息。

这部分内容讲完，我们的技术路径就已经清晰了，它涵盖了从基础的直播到DNS解析，再到双向传输等众多音视频应用场景。然而，就在这时，有人告诉我，我们的成果，苹果公司也在进行类似的研究。于是，我们想要阐述一下我们与苹果公司的区别，以及我们是如何进行优化的。

若要在微信中直接操作，仍面临诸多限制。首先，浏览器内核在各类手机上可能存在差异，导致碎片化现象严重。以苹果为例，其内核是内嵌式的，因此小程序的运用受到限制。目前，无论何种功能增强，都需要苹果与谷歌双方达成共识，而这通常是一个耗时漫长的过程。因此，在小程序领域，我们致力于开发贴近实际需求的功能，并不会过分关注苹果和谷歌这两大巨头的动向。

此外，还需指出的是，在设计思路方面亦存在差异，众多理念均建立在不可信的链式结构之上，而我们的应用程序则能够借助相对低成本的云计算服务得以实现，这一点与某些其他产品形成鲜明对比。

我们并非在竞争，实际上，我们完全有可能携手合作。腾讯云近期计划将两个系统实现整合，待微信4月份的新版本推出后，大家便能在小程序中实现互相连接。这个过程或许有些复杂，但对于感兴趣的朋友来说，提供的解决方案颇具技术深度。

谈及打通后的情况，这便引出了另一套应对策略，即采用小程序+模式，只需在原有基础上将协议更换为以rom开头的即可。

迅速掌握技能，先前得搭建后端和前端，过程颇为艰难，而现在，大家只需在黄老师的系统中直接搜寻所需模块，轻松上传至其中。此外，调试过程也变得异常便捷。今日分享到此结束，请大家提出疑问。

QA:

作为一个独立软件创作者，我时常关注到一些开放性的内幕信息，例如在音视频领域，这些信息并未完全公开。若我打算开发类似的产品，所需办理相关资质的费用相当高昂。因此，我很好奇，未来小程序在音视频领域是否会更加开放，从而降低开发成本。

似乎存在一些相对容易掌握的内容，但观察直播的幕后情况却颇具挑战。事实上，我强烈期望所有内容都能公开透明，为此，我还主动多次与微信的管理层就此事进行了沟通。微信的同事向我表达了一个非常实际且合理的顾虑，指出在以前开发APP时，若APP出现涉黄或涉政内容，这些问题与APP本身并无直接关联，因此他们对这一问题持极为谨慎的态度。实际上，资质提交的核心问题在于此，一旦出现状况，我们将利用这一资质实施管控措施，其目的仅是为了确保自身安全。对于个人开发者而言，凭借他们个人的调试技能以及某些内部信息，提交资质相对较为简单。

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

实际上，缓存量并不大；以优酷和土豆为例，它们采用的是点播模式，视频内容是上传至平台，观众可以随意从视频的任何部分开始观看，这种观看方式属于点播。而直播则不同，它需要实时通过摄像头上传，如果上传内容过多，可能会出现较大的延迟。腾讯内部网络是互通的，因此无需设置过多的缓存机制。实际上，关键的缓存环节在于我们观看视频的部分，那里设有专门的缓存区域。该区域内包含了一系列的优化算法，用于决定何时进行缓存。可以说，在整个系统中，这一部分是唯一的缓存所在。

我之前考虑增加缓存，但这会导致延迟增加。此外，常老师提到关于涉及和政治内容的问题，您在演讲中提到，通过声音处理技术，可以实现每秒的实时调整，而在制作视频时，还可以加入美颜效果。这样一来，你们对这些内容的控制能力实际上相当强。因此，在内容审查过程中，一旦检测到涉及或政治的内容，就可以直接将其屏蔽。

目前存在此类系统，它运作时需要人工介入。我目前的心态是，尚未达到完全放任不管的阶段。系统偶尔会出现误报，比如主持人肤色偏黄，导致被误判为涉黄内容，这便需要人工进行审核，从而产生一定的延迟。首先，需将人工举报信息输入检测系统，而观众数量较多的线路，误报所带来的损失也更为严重。

在进行直播过程中，尽管能够进行涉及内容的视频剪辑，以及借助AI和监控技术，我们或许能够实现录播功能。一旦发生意外情况，我们仍需提供相应的证据。您所提及的功能在我们的平台上确实存在明显的需求。

A：是录播吗？

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

这个绝对没有问题，因为对于所有需要记录过云信息的情况，您只需轻触一个开关，即可实现全面录制，亦或是设定特定时间段进行录制，这些操作都是可行的。然而，在实施云解决方案的过程中，您需要将其迁移至技术要求较高的环节，比如在金融开户或法院审理等场合，需要对音视频进行重新缓冲处理。唯一需要注意的是，这种录制服务并非免费，是需要支付相应费用的。在录制政用内容时，我们采用的是开放的态度，但商用内容则不开放。实际上，我们众多的大客户每年在带宽成本上就占据了一部分，而且他们存储的数据量也非常庞大，一个月的数据量就十分惊人。