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的應用場景以及現在存在的各種問題�？赐晡恼拢浑y得出目前QUIC還不適合用于音視頻實時通信的結論。
WebRTC實際應用中的痛
應用中最大的難點是根據業(yè)務需求作出恰當的折衷。之前袁榮喜和谷沉沉的兩篇文章在這個方面講得比較清楚（特別是第一篇文章），本文就不再重復了。
以微信的實時通信小程序來舉個例子，根據之前LiveVideoStack的訪談，我猜測它使用的是RTMP/QUIC的實現方案（如果不正確請糾正我）。這就是一個典型的實現方案上的折衷。它的優(yōu)點是便宜（可復用HTTP2的基礎架構），缺點是在丟包環(huán)境缺少強實時性保證（見《RTP over QUIC》）。對于它是否能夠滿足宣傳中的各種高實時性要求場景（比如視頻會議，在線教育）？在網絡環(huán)境好的時候，是可以的；但是在高RTT且存在一定丟包環(huán)境，很難保證。實際上在這類高交互場景，微信自己采用的正是類WebRTC技術（見谷沉沉的文章）。另一方面，從實現復雜度和壓縮效率的方面看，實時通信方案的代價是比較高昂的，不能將其視為一切音視頻傳輸問題的通用方案。
未來改進
網絡中間節(jié)點的Qos策略是比較多樣的，目前GCC算法主要是針對Shaping（帶有一定緩沖管理策略），對于簡單限制帶寬的Policing的表現不好。感覺基于丟包的擁塞控制這塊還有很大的改進空間。擁塞控制算法這塊，IETF RMCAT工作組一直有很活躍的討論，除了GCC算法，還有多種其他的擁塞控制算法。
WebRTC與安防行業(yè)難牽手？
安防方面高清和智能化是兩大趨勢，原生WebRTC在這一塊難有作為，原因有兩個：
- WebRTC對H.264僅支持到BP，H.265基本不會支持，主要安防芯片廠商沒有明確支持AV1編碼；
- 智能化需要音頻視頻以外的其他實時數據的自定義渲染，瀏覽器應該還沒有支持，不知道谷歌會不會關注到這個細分需求。
在安防的其他場景，可能會有直接應用。如果有了解的小伙伴，歡迎指正、交流。
WebRTCon 2018 7折火熱報名
WebRTCon希望與行業(yè)專家一同分享、探討當下技術熱點、行業(yè)最佳應用實踐。如果你擁有音視頻領域獨當一面的能力，歡迎申請成為講師，分享你的實踐和洞察，請聯系 speaker@livevideostack.com。
