隨著在線教育、電商直播、泛娛樂社交等 App 的普及,實時音視頻技術(shù)的應(yīng)用需求也越來越多元化。目前,市場中能夠支持音視頻通信的主流技術(shù)有“RTMP+CDN”和“RTC”兩大陣營。選型時,開發(fā)者如何根據(jù)場景選擇更適合自己的通信技術(shù)?這就要從兩者的技術(shù)特點、價格、廠商服務(wù)綜合考慮。
RTMP+CDN 技術(shù)特點與適用場景
RTMP (Real Time Messaging Protocol)基于 TCP 的流媒體傳輸協(xié)議,最大的特點是與 CDN 的強綁定,需要借助 CDN 的負載均衡系統(tǒng)將內(nèi)容推送到接近用戶的邊緣節(jié)點,使用戶就近取得所需內(nèi)容,提高用戶訪問的響應(yīng)速度和成功率,解決因分布、帶寬、服務(wù)器性能帶來的訪問延遲問題。更多適用于站點加速、點播、短視頻等場景。
對于初次通過 CDN 服務(wù)來實現(xiàn)音視頻通信的開發(fā)者來說,技術(shù)指標應(yīng)主要關(guān)注延時、卡頓率、下載速度、打開速度、回源率、寬帶冗余提升率等幾個維度。
有研究表明,在 0.1s 以下的延遲,用戶幾乎是無感知的;1s 左右的延遲,用戶會明顯注意到延時的發(fā)生,但在該時間內(nèi)思維依然是連貫的;超過 10s 的延時,用戶會失去等待的耐心。在所有關(guān)鍵技術(shù)指標中,控制延時是 CDN 最需要提升的。
以直播場景為例,延時主要看 2 個核心指標:首播時間和再緩存時間。首播時間即從打開到看到視頻畫面的時間,會受域名解析、連接、第一包時間的影響,首播時間控制在 1 秒內(nèi)算是不錯的效果。其次是再緩沖時間,是用戶觀看視頻時的卡頓時間。由于實際服務(wù)中視頻長度不一,一般會做播放的體驗統(tǒng)計,主要監(jiān)測的是卡頓率。行業(yè)內(nèi)而言,直播首播時間 300ms,卡頓率在 15% 以下算是優(yōu)質(zhì)的通信服務(wù)。
目前的 CDN,通常有 3-5 秒的延遲,在瀏覽圖片、短視頻等內(nèi)容時用戶感知不明顯,對于不需要實時強互動的直播,比如體育賽事網(wǎng)絡(luò)直播、演唱會網(wǎng)絡(luò)直播、新聞現(xiàn)場直播,延遲是可以接受的,并不會影響用戶體驗。
而在線視頻會議、在線教育、電商直播、遠程醫(yī)療會診這些對互動有非常高要求的場景,RTMP+CDN 的模式與這些場景對于低延時、無卡頓的要求有一定差距。這時,選擇 RTC 技術(shù)才能更好地滿足開發(fā)者的需求。
RTC 技術(shù)特點與適用場景
說到 RTC(Real Time Communication)實時音視頻通信,它最大的特點就是低延時和無卡頓。從功能流程上說,它包含了采集、編碼、前后處理、傳輸、解碼、緩沖、渲染等諸多環(huán)節(jié),RTC 不是靠“優(yōu)化”各環(huán)節(jié)去實現(xiàn)的實時互動,而是依靠推流端實時的傳輸機制。
很多實時音視頻服務(wù)專業(yè)廠商使用的就是 WebRTC 標準,這是一種基于瀏覽器的實時通信的開源解決方案,使用 UDP 私有協(xié)議來進行媒體推流,而不需要創(chuàng)建離散的媒體段;并且它是面向無連接的,沒有 TCP 連接斷開時的揮手確認連接關(guān)閉的機制,基于這兩點,WebRTC 能夠做到毫秒級的低延遲,遠遠低于基于 RTMP 協(xié)議的 CDN 分發(fā)的延遲。而且,它直接通過瀏覽器就可以完成推流和播放,對于開發(fā)者接入來說實在太方便。
因此,WebRTC 標準針對有高互動性要求的直播場景尤為適宜。以直播連麥為例,主播端把通信直播流發(fā)到觀眾端,同時也可以把觀眾端拉上麥,實現(xiàn)主播和觀眾的互動。使用 WebRTC,內(nèi)容實時傳輸,主播和觀眾可以進行音視頻連麥互動,實時溝通,延時一般低至 400ms 以內(nèi)。
基于 WebRTC 標準的融云實時音視頻服務(wù),擁有超低延遲的優(yōu)勢,同時也支持將 RTC 音視頻流合流(MCU)轉(zhuǎn)碼為 RTMP,并推流到第三方 CDN 上,保留了標準協(xié)議普遍被 CDN 網(wǎng)絡(luò)支持的好處。目前,融云音視頻通話,可做到全球端到端延時小于 400ms,最低延時 66ms;低延時互動直播的直播推流可以做到主播觀眾間延遲在 300ms 左右,保障端到端之間延遲無感知的實時互動。
CDN vs RTC 選型還需看價格服務(wù)綜合比
一套實時音視頻通信能力的搭建,除了要根據(jù)場景選擇適合的技術(shù)外,還要看價格、服務(wù)的綜合性價比。通常來說,使用 RTC 技術(shù)的成本比 RTMP+CDN 高。因為,從實踐來看,UDP 傳輸比 TCP 傳輸對資源消耗要多,而且重傳、封包、FEC 冗余計算等都會額外增加計算量,在多進程模式下可能還會遇到內(nèi)存資源的過多消耗,這些都導(dǎo)致開發(fā)及使用成本的增加。
開發(fā)者選型中,性價比需綜合技術(shù)特點、適用場景、價格和服務(wù)四個方面的全面考量。服務(wù)在產(chǎn)品上線前后的開發(fā)階段和運營階段,都要發(fā)揮重要作用。目前,開發(fā)者服務(wù)做得比較好的廠商比如融云,會與開發(fā)者共建開發(fā)文檔,技術(shù)手冊短視頻化,提供場景化的 Demo,以及在官網(wǎng)搭建開發(fā)者專區(qū),幫助開發(fā)者更便捷、更快速的理解 SDK。
融云全新升級的實時音視頻服務(wù),提出“以一套 SDK 解決所有通信場景”,使用融云 RTC 的開發(fā)者,同時可以用融云 IM 作為信令通道,而不用自己重新搭建或選擇第三方信令通道,這樣可以大大提升開發(fā)效率,減少 SDK 文檔學習時間。
總體而言,RTC 低延遲直播是未來發(fā)展的趨勢,而 RTMP 在當前依然擁有價格上的優(yōu)勢,而兩者作為音視頻領(lǐng)域的實用技術(shù),無論是適用場景、還是貼近開發(fā)的服務(wù)都越來越多樣化,開發(fā)者未來選型之路也將更順暢。