什么是RTC
RTC(Real time communication)實時通信,是實時音視頻的一個簡稱,我們常說的RTC技術一般指的是WebRTC技術,已經被 W3C 和 IETF 發布為正式標準。由于幾乎所有主流瀏覽器都支持 WebRTC 標準 API ,因此也讓瀏覽器之間無插件化的音視頻互通成為可能, 大大降低了音視頻開發的門檻,開發者只需要調用 WebRTC API 即可快速構建出音視頻應用。
更廣義的RTC技術,不單單局限于音視頻,包括IM、圖片、白板、文件共享等富媒體在內的實時交互也屬于RTC技術范疇。
解決什么問題
直播中我們關心的幾個點:延遲、質量、成本等。
傳統rtmp直播痛點:TCP,延遲高、擁塞導致卡頓問題較多(質量問題)。
互聯網網絡復雜、延時敏感、實時音視頻流暢度及清晰度較低以和運營成本較高等。
沒有一項技術能兼顧并解決直播中的所有問題,RTC是時延、流暢、質量、成本等的平衡,成為技術選型落地的模型。
我們在做RTC應用的時候,不應該一味地追求一些點,不應該在某些單點上用力過猛(比如單純的追求抗丟包能力),導致最終的效果會打很多折扣,不能只著眼于延遲低,畫質高,應該把視角放在用戶的整體體驗上。
RTC與傳統RTMP直播對比
參數對比 | RTC | RTMP(CDN) |
---|---|---|
底層推流端傳輸協議 | RTP(UDP) | RTMP(TCP) |
質量保證Qos | RTCP | - |
播放端協議 | RTP | rtmp、hls、http-flv |
延遲 | 400ms以內 | rtmp 3s+、hls 15s+、http-flv 3s+ |
同步性 | 推流端與播放端基本實時,同步性非常好 | 推流端與播放端同步性差 |
互動體驗性 | 優 | 差 |
關注點 | 關注實時性 | 關注質量 |
拓撲結構 | 雙向,既有推流又有拉流 | 單向,主播推流、觀眾拉流 |
技術限制 | 參與人數限制,以聲網為例支持17人互動,百萬觀看(低延遲直播產品) | 一個主播,觀眾數理論無上限 |
安全性 | 所有 WebRTC 媒體數據都必須經過加密 | 原生無加密技術,需定制開發視頻加密和防盜鏈 |
兼容性 | 為web端而生,提供Native sdk(移動端、PC端),無服務端通用方案需自行開發 | web已不支持發起rtmp直播(Adobe 2020 12棄用flash)rtmp標準協議接入,服務端由技術成熟的CDN分發 |
復雜性 | 非常復雜,涉及技術龐雜 | 比較簡單清晰 |
典型應用場景 | 推流端與播放端互動性強的場景:視頻會議、連麥互動、語音/視頻聊天 | 推流端與播放端同步性不是很高要求的場景:活動/賽事直播、秀場直播、游戲直播、直播帶貨 |
價格(成本) | 高 | 低 |
一套完善的RTC服務應用的技術
RTMP只是TCP上的一個標準協議,所以接入是一個標準體系,推流端可以是OBS這種直播軟件工具,也可自開發rtmp推流工具,播放端可以是Flash播放器(Adobe 2020 12月份已經棄用)、服務端有技術成熟的CDN技術和設施進行分發、Native的播放器或者flv.js/hls.js這種開源播放器組件,遵循rtmp、flv、hls標準即可,接入成本比較低。而一個完善的RTC服務應用,需要從推流端、服務端、到拉流端,一整套完整的全鏈路閉環技術。
RTC的應用場景
視頻會議、在線教育小班課、大班課、1v1視頻連麥、多人視頻連麥互動、語音聊天室、在線面試、在線醫療、云游戲、智能家居、在線簽約、在線K歌等,遍地開花。
比如Zoom、騰訊會議、釘釘會議、微信音視頻聊天
RTC+RTMP
互動連麥+服務端轉推rtmp至CDN,CDN分發給觀眾。
RTC行業狀況
**RTC服務提供商
**
聲網、騰訊云音視頻、即構、阿里云RTC、華為云RTC、微吼VRTC、網易云信RTC、保利威RTC、Ucloud RTC、融云RTC、拍樂云等。
RTC展望
-
API
+關注
關注
2文章
1499瀏覽量
61964 -
RTC
+關注
關注
2文章
538瀏覽量
66466 -
實時通信
+關注
關注
0文章
18瀏覽量
9717 -
WebRTC
+關注
關注
0文章
57瀏覽量
11240
發布評論請先 登錄
相關推薦
評論