小程序音视频能力技术负责人解读“小程序直播”

策划 / LiveVideoStack
责编 / 包研

一夜之间，“小程序+直播”成为多媒体开发者热议的话题。从底层技术实现到接口开放程度，是否绑定腾讯云？价格体系？低延迟性能如何？......一连串的问题背后是开发者乃至整个生态对“小程序+直播”的关注。LiveVideoStack 邀请到小程序音视频能力的技术负责人常青，就开发者关注的各种问题进行了解答。如果您还有新的问题，请在在文末留言或邮件至 [email protected] 。

另外，我们还发起了针对“小程序+直播”的问卷，近 9 成的开发者看好“小程序+直播”，最看好的应用场景是直播、在线教育和视频会议，最关心的性能是延迟。

LiveVideoStack：关于小程序中的 RTC 能力，是通过 WebRTC 实现的（或其他 RTC 技术），还是基于 RTMP 呢？

常青：小程序的 RTC 能力是基于 RTMP 技术实现的，没有使用 WebRTC 是出于两方面的考虑：一是微信安装包（尤其是 iOS 版本）的体积增量必须要控制在可接受的范围内，这是一个硬性的要求。另一个考虑就是 RTMP 协议的适用场景更多，除了实时视频通话场景之外，还可以做标准直播解决方案。比如培训、教育等场景。

LiveVideoStack：求证下，小程序里面用的是 UDP + RTMP 方式来实现 RTC 的，而且还对协议内容加密了？那是不是意味着小程序 RTC 必须走腾讯云？

常青：首先，对于直播场景下音视频通道的加密是很刚需的一个要求，所以小程序在 RTC 模式下如果走腾讯云，会默认开启加密能力以避免窃听攻击。

当然，小程序如果实现 RTC 不需要绑定腾讯云，关于这一点大家可以做个试验：简单用 nginx-rtmp 搭建一个后台服务器，然后创建两对 RTMP url，按照文档 https://cloud.tencent.com/document/product/454/12521 的指引放在小程序里测试，可以体验一下效果，只要网络不是特别差，延迟和效果应该是很不错的。

腾讯云真正做的出色的是，让全国不同地方的两路 RTMP，都能达到很好的效果，这是腾讯云多年来一直积累 CDN 节点，优化内部链路调度（ GBN 网络）的结果。

LiveVideoStack：如果是 RTMP + UDP，无法实现 ARQ、FEC 传输算法，是这样吧？

常青：RTMP 本身是可靠的传输层协议，所以不需要实现 ARQ 和 FEC 算法，ARQ 和 FEC 都是为了解决传输层协议不可靠（比如私有 UDP 协议）而不得不采用的办法。

这是一个漫长的故事：早期实时音视频通话面对的网络条件要比现在恶劣的多，也就是常说的窄带时代。在那个时代的网络条件下，由于带宽成本极高，所以实时音视频通话都需要采用 UDP 协议来打洞实现 peer to peer 直连，这就意味着我们只能选择 UDP 协议，因为 TCP 打洞做 NAT 穿越不是那么容易。而 UDP 协议如果做成可靠的协议（也就是不丢包），就丧失了它的灵活性，因为音视频通话本身对于部分数据的丢失是可以容忍的，所以适当的允许一些丢包是更加符合窄带传输的需求。当然，我们不希望频繁的丢数据，不然通话质量就上不来了，所以 ARQ 和 FEC 这种丢包恢复技术就应用而生了。

时代在进步，技术思路也在进步。目前已经到了宽带时代，高清大码率的场景越发普遍，直播的流行和大王卡的普及，都在告诉我们网络的带宽越来越理想，所以我们现在面对的主要问题可能不再是带宽不够用，而是 WiFi 和 4G 下突发的网络波动。而应对这种网络波动，可靠传输层协议并不比私有 UDP 协议劣势太多，而且 ARQ 和 FEC 本身会产生带宽的浪费，以 FEC 为例，30%的丢包需要用 30%的冗余来解决，但是 30%的冗余就意味着多传输 30%的数据，在码率小的时候不起眼，大码率场景下就越发鸡肋了。

所以，用惯了 ARQ 和 FEC 的技术专家们，也可以偶尔考虑一下可靠的传输协议，只要不是特别极端的场景，效果还是可以一试的，而且我们也在持续优化和改进，争取在每一个版本中都有效果上的提升。

腾讯云也有专门的私有 UDP 解决方案，其 ARQ 和 FEC 技术也非常成熟，但这都是腾讯云自家的标准，在微信小程序里落地就会面临绑定腾讯云的问题，所以我们最终选择了普遍支持的标准 RTMP 协议，并将底层的 TCP 传输层换成了业内目前普遍更被看好的 HTTP/2 的一种内部传输技术，它也是基于 UDP 协议实现的，但它并不私有，也越来越流行。如果您感兴趣，Google 一下 HTTP/2 会了解到更多。

LiveVideoStack：native 的直播、短视频应用已经非常成熟了，功能强大。同时，基于 H5 的音视频应用，在线教育服务也比较流行。那么小程序具体如何定位自己？他真正的优势在哪里？

常青：小程序的定位就是服务号的能力扩展，它的优势就是能力的扩展上要比 H5 更快，H5 受限于浏览器内核的普及，新特性和新能力的上线需要一个较长的时间，而且苹果在这里的态度也有很大的不确定性。比如最近 WebRTC 持续升温，很大程度上要得益于苹果的态度转变，而我们并不能假设在后续所有的场景上苹果都会保持这种开放的心态。同时，小程序的定位更加专注于能力实现，在体验和二次加载速度上，相比于 H5 还是有一定的优势。当然，相比于定制性和迭代速度，体验上的优势仅仅是一个小细节了。

LiveVideoStack：iOS 11 可以支持 WebRTC，相信 iOS 上的微信支持 WebRTC 也可期。许多开发者看好 WebRTC 可以打通 iOS、Android 和 PC 浏览器。相比而言，小程序的优势是什么？

常青：目前 iOS 上的 WebRTC 能力还有一些不尽如人意的地方。另外，Android 系统下的 WebRTC 实现也因为系统版本和碎片化问题有很多兼容性问题。在目前这段 WebRTC 还在不断完善中的时间里，要做到比较统一的体验，前端工程师们依然要面对很多不可控因素。

从长期来看，小程序上的优势在于更好的可控性和可定制性：可控性上来讲，由于审核制度的存在，在小程序里出现涉黄涉政等不法现象的概率会接近于零；另一方面，类似美颜等更“接地气”的特性的支持，都是 WebRTC 需要很长时间才能反应过来的，我们也非常希望后续能够快速迭代地增加一些高性价比的特性进来（太过娱乐化的特性暂不考虑）。

LiveVideoStack：是否提供原生的连麦（包含回声消除）功能？是否开放接口，对接第三方的连麦服务？

常青：live-pusher 和 live-player 的 RTC 模式本身自带回音消除功能，只要设置好 mode 参数为 RTC，都是可以使用回声消除能力的。 而且 live-pusher 和 live-player 没有限制第三方云服务，只要有可用的 RTMP 地址就可以使用，至于如何基于 live-pusher 和 live-player 标签实现实时通话功能，可以参考： https://cloud.tencent.com/document/product/454/12521

LiveVideoStack：文档中表示，小程序音视频能力不需要指定腾讯云，但接口似乎还没有（完全）开放？

常青：小程序此次开放的音视频能力确实不需要指定腾讯云，支持 RTMP 协议的云商都可以对接，所有接口都已经放在了文档 https://cloud.tencent.com/document/product/454/12518 和 https://cloud.tencent.com/document/product/454/12519 中进行说明，没有尚未暴露的接口。

LiveVideoStack：CDN 有哪几种接入方式？

常青：如果使用 live-player 标签，可以使用 RTMP 协议和 http-flv 协议进行接入，也可以使用 HLS 协议接入，但 HLS 协议需要使用微信小程序早就开放的<video>标签。

LiveVideoStack：第三方服务提供商（如美颜、图像识别、连麦、CDN 等）是否可以接入小程序，成为用户可选的服务？

常青：这里第三方的相关服务要看是云服务还是终端服务了。如果是云服务，那是完全没有问题的，支持 RTMP 协议都可以（接入），比如连麦、CDN 等都无限制。但如果是终端服务，除非是 JavaScript 的组件，否则都是不行的，因为微信小程序只提供了 JavaScript 的编程能力。美颜是我们直接将图像处理算法打包进微信 APP 实现的，JavaScript 无法达到这个计算性能的要求。

LiveVideoStack：小程序接受直播、在线教育、金融、医疗、视频会议、电商、政务民生等几类应用的审核，在您看来，具有音视频能力的小程序最佳的应用场景是什么？

常青：小程序的定位就是服务号的能力扩展，最佳的应用场景就是装 APP 太麻烦，搜索一下就能用的场景，比如远程车险定损、在线视频客服等等，这些惠民便民的场景也是微信非常鼓励和推荐的。