如何利用webrtc实现TSINGSEE青犀视频云-边-端架构视频智能分析平台低延迟直播？

目前TSINGSEE青犀视频云边端架构视频智能分析平台都实现了低延迟的视频直播，在我们测试期间最低的直播延迟协议应该属于ws-FLV、RTMP协议了，测试最优延迟可达1s左右。目前国内大部分厂家在用的 RTMP，它相对于 HLS 在服务端做了优化。RTMP 服务端不再进行切片，而是分别转发每一帧，CDN 分发延迟非常小。

上图是国标视频平台EasyGBS输出的视频流播放界面，可输出三种不同协议的视频流，其中FLV在低延迟直播当中的运用比较常见，同时RTMP也可达到低延迟，大家有兴趣可以研究一下。

而对于越来越高的视频直播要求，我们已经需要探寻更加低延迟的方案，webrtc恰巧就是这一技术发展的新兴之路，这也是TSINGSEE青犀视频研发团队目前不断测试webrtc的价值所在。

在测试过程中，我们发现标准 WebRTC 接入过程会有各种限制，比如它不支持直播中常用音频 AAC 编码和 44.1k 采样率，其它不支持视频 B 帧、H265等编码特性，多 slice 编码在弱网下也会花屏，并且WebRTC 建联过程耗时过长，会影响秒开体验。对此，我们也在寻找更为高效、兼容性更好的协议接入，从而将webrtc用于视频直播当中。

标准 WebRTC 接入的优点：

标准 WebRTC 接入除了 HTTP 建联请求外，全部符合 WebRTC 规范。
标准终端方便接入。
可快速实现原型。

标准 WebRTC 接入的缺点：

建联过程耗时长，使用HTTP情况下达到5RTT，选用HTTPS会更长。
媒体必须加密传输。
音视频有相关限制，使用时需要在服务端转码。

基于webrtc全模块的接入方案，使用webrtc的所有模块，通过对部分模块的修改，实现低延迟直播功能。这个方案的优点很诱人，经过多年发展，它非常成熟，很稳定，同时提供了完整的解决方案，包括 NACK、jitterbuffer、NetEQ 等可直接用于低延迟直播。

但是它的缺点也很很明显，如上图中是WebRTC整体架构，它是一个从采集、渲染、编解码到网络传输的完备的端对端方案，对现有推流端和播放端侵入性极大，复杂度极高。RTC技术栈和直播技术栈存在差异，他不支持B帧、265等特性。在QOS策略方面，WebRTC的原生应用场景是通话，它的基本策略是延迟优于画质，这个策略在直播中不一定成立。包大小：所有webrtc模块全部加入到APP中，包大小至少增加3M。

低延迟直播技术的发展需求越来越明显，它不仅能够提升用户的体验，也能为视频直播的运维带来更加便利的操作，同时，低延迟直播技术也可支持更多业务形态。对此，TSINGSEE青犀视频研发团队仍然在不断测试当中，5G 到来后，网络环境会越来越好，低延迟直播技术会成为直播行业未来的一个技术方向。

如果大家对TSINGSEE青犀视频研发团队对webrtc的开发比较感兴趣，可以翻阅我们以前的相关博文：Visual Studio 2017自建WebRTC中peerconnection_client程序编译报错不匹配问题、WebRTC中实现局域网视频连接的步骤说明介绍。同时也欢迎大家和我们探讨相关内容。