WebRTC：应用中最大难点在于根据业务需求的适当折中

WebRTC对主流PC浏览器、移动端的全覆盖，对于开发者而言无疑是一剂强心针，而在去年W3C大会上又提出通过QUIC来实现WebRTC。但在实际应用、行业契合以及对H.265的支持依然存在着不可忽视的痛，海康威视嵌入式软件开发工程师郑鹏针对以上问题与我们分享了它的观点和见解。本文是『WebRTC-互联网音视频新标准？』系列的第二篇，如果您对WebRTC技术的未来有分析和洞见，欢迎联系 contribute@livevideostack.com。

文 / 郑鹏

策划 / LiveVideoStack

H.265向WebRTC低头？

H.265的专利问题比H.264要复杂得多，再加上谷歌会力推AV1，我认为H.265不太可能得到WebRTC的官方支持。

通过QUIC实现WebRTC

WebRTC使用QUIC应该是实现数据通道，不太可能用于实现音视频传输。举个例子，在会议中，音视频数据走的是媒体通道，媒体通道的实时性要求非常高；但如果在会议中演示PPT，那么PPT文件走的一定是数据通道，数据通道对可靠性的非常高，对实时性的要求要低不少。目前QUIC还是一个完全可靠的协议，所以不适合用在实时性要求特别高的场合。关于QUIC，我想推荐两篇文章：

• Applicability of the QUIC Transport Protocol
• RTP over QUIC（https://tools.ietf.org/html/draft-rtpfolks-quic-rtp-over-quic-01）

特别是第二篇文章，讨论了RTP在QUIC的应用场景以及现在存在的各种问题。看完文章，不难得出目前QUIC还不适合用于音视频实时通信的结论。

WebRTC实际应用中的痛

应用中最大的难点是根据业务需求作出恰当的折衷。之前袁荣喜和谷沉沉的两篇文章在这个方面讲得比较清楚（特别是第一篇文章），本文就不再重复了。

以微信的实时通信小程序来举个例子，根据之前LiveVideoStack的访谈，我猜测它使用的是RTMP/QUIC的实现方案（如果不正确请纠正我）。这就是一个典型的实现方案上的折衷。它的优点是便宜（可复用HTTP2的基础架构），缺点是在丢包环境缺少强实时性保证（见《RTP over QUIC》）。对于它是否能够满足宣传中的各种高实时性要求场景（比如视频会议，在线教育）？在网络环境好的时候，是可以的；但是在高RTT且存在一定丢包环境，很难保证。实际上在这类高交互场景，微信自己采用的正是类WebRTC技术（见谷沉沉的文章）。另一方面，从实现复杂度和压缩效率的方面看，实时通信方案的代价是比较高昂的，不能将其视为一切音视频传输问题的通用方案。

未来改进

网络中间节点的Qos策略是比较多样的，目前GCC算法主要是针对Shaping（带有一定缓冲管理策略），对于简单限制带宽的Policing的表现不好。感觉基于丢包的拥塞控制这块还有很大的改进空间。拥塞控制算法这块，IETF RMCAT工作组一直有很活跃的讨论，除了GCC算法，还有多种其他的拥塞控制算法。

WebRTC与安防行业难牵手？

安防方面高清和智能化是两大趋势，原生WebRTC在这一块难有作为，原因有两个：

• WebRTC对H.264仅支持到BP，H.265基本不会支持，主要安防芯片厂商没有明确支持AV1编码；
• 智能化需要音频视频以外的其他实时数据的自定义渲染，浏览器应该还没有支持，不知道谷歌会不会关注到这个细分需求。

在安防的其他场景，可能会有直接应用。如果有了解的小伙伴，欢迎指正、交流。

WebRTCon 2018 7折火热报名

WebRTCon希望与行业专家一同分享、探讨当下技术热点、行业最佳应用实践。如果你拥有音视频领域独当一面的能力，欢迎申请成为讲师，分享你的实践和洞察，请联系 speaker@livevideostack.com。