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。
