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