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