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

​

 

策划 / LiveVideoStack

责编 / 包研

 

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

 

另外，咱们还发起了针对“小程序+直播”的问卷，近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太麻烦，搜索一下就能用的场景，好比远程车险定损、在线视频客服等等，这些惠民便民的场景也是微信很是鼓励和推荐的。