WebRTC | 原理、架構(gòu)、框架目錄、運行機制、核心類、PeerConnection調(diào)用過程等詳解

架構(gòu)

  • 整理分為兩層：
    應(yīng)用層、核心層

  • 綠色部分是核心部分，
    是WebRTC提供的核心功能；

  • 紫色部分是瀏覽器提供的JS的API層；
    即
    瀏覽器對WebRTC核心層的C++ API 做了一層封裝，
    封裝成了JS接口；

  • 最上面的箭頭是上層應(yīng)用了，
    上層應(yīng)用 可以在 瀏覽器中 直接訪問 瀏覽器提供的API；

  • 最終調(diào)用到核心層【藍色虛線框、可重載?。　?/p>

WebRTC核心層

  • C++ API：API數(shù)量較少，主要是PeerConnection；
    （PeerConnection的API又包含傳輸質(zhì)量、傳輸質(zhì)量報告、各種統(tǒng)計數(shù)據(jù)、各種流等）
    【設(shè)計技巧：
    對于上層來說，提供的API簡單，方便應(yīng)用層開發(fā)；
    內(nèi)部比較復(fù)雜；】

  • Session層【上下文管理層】：
    如應(yīng)用創(chuàng)建了音頻、視頻、非音視頻的數(shù)據(jù)傳輸，
    都可以在Session層做處理，做管理相關(guān)的邏輯；

  • 【最重要】引擎層/傳輸層【核心】

    • 音頻、視頻、傳輸 解耦

    • 音頻引擎：【Voice Engine】
      ISAC/ILBC 編解碼；
      NetEQ 【Buffer】 網(wǎng)絡(luò)適配、防止網(wǎng)絡(luò)抖動；
      回音消除（echo canceler）：
      音視頻重點，決定產(chǎn)品質(zhì)量，
      WebRTC里提供了相關(guān)非常成熟的算法，開發(fā)時只需要調(diào)節(jié)參數(shù)即可；
      降噪（Noise Reduction）、自動增益；

    • 視頻引擎：【Video Engine】
      VP8、openH264 編解碼；
      Video jitter buffer：防止視頻抖動；
      Image enhancements：圖像增強；

    • 傳輸【Transport】
      底層用的UDP，上層用的SRTP【即安全的、加密后的RTP】；
      Multiplexing：多個流復(fù)用同一個通道；
      P2P層【包括 STUN+TURN+ICE】；
      所有的
      音頻視頻的接收與發(fā)送，
      都是通過傳輸層去做的，
      傳輸層包括了泄漏的檢測、網(wǎng)絡(luò)鏈路質(zhì)量檢測，
      根據(jù)情況估算網(wǎng)絡(luò)帶寬，根據(jù)網(wǎng)絡(luò)帶寬進行音視頻、文件等非音視頻的傳輸；

  • 硬件層
    視頻采集、渲染；
    音頻采集；
    網(wǎng)絡(luò)IO等；
    WebRTC的核心層中是沒有視頻的渲染的，
    所有的渲染都需要 應(yīng)用層 或者 瀏覽器層 自己做；



WebRTC目錄結(jié)構(gòu)

  • WebRTC代碼量大，目錄多

  • 實際開發(fā)中，可能需要我們修改WebRTC的代碼，
    所以，我們必須知道每個目錄的功能、作用是什么；


補充說明

  • call，一個端一個call，多個端多個call；

  • module目錄很大，也特別重要，
    里邊有很多子模塊，
    每個子模塊也都非常重要；


  • pc：【重要目錄，上層的一個統(tǒng)一接口層】
    Peer Connection，代表一個連接，
    連接下邊就要有很多相關(guān)API了，
    如，
    Stream 流；
    chain 軌【音頻軌、視頻軌、桌面軌】
    【軌 即 一系列永不相交的平行線（線程），
    即音頻與視頻與桌面處理，都是各自處理，互不交叉的】；

    所以在Peer Connection中我們可以拿到流，
    通過流我們可以拿到每一個多媒體，
    還可以拿到所有媒體的統(tǒng)一信息、傳輸?shù)?code>統(tǒng)一信息等

  • p2p：
    端對端的傳輸時，需要先檢查p2p是否能打通；
    相應(yīng)的協(xié)議、工具、API等，放在這里；

  • rtc_base：
    不同操作系統(tǒng)，如Window和Linux，之間的系統(tǒng)函數(shù)差別就特別大；
    但是rtc_base都封裝好了，
    上層按照規(guī)范編寫調(diào)用邏輯即可，
    框架會判斷是在哪個平臺運行，并執(zhí)行相應(yīng)的代碼；

  • rtc_tool是音視頻相關(guān)的測試；
    tool_webrtc是整個框架的測試；

  • system_wrappers，
    存放操作系統(tǒng)等操作代碼，
    不同系統(tǒng)不同文件存放；

以上是WebRTC最外層的目錄，
下面看WebRTC目錄下的Modules子目錄

WebRTC Modules 目錄

  • audio_coding：
    上面的WebRTC架構(gòu)圖中
    提到的 ISAC/ILBC、VP8等編解碼器邏輯，
    都是放在這個目錄下的；

  • audio_device：
    現(xiàn)在的WebRTC文件中關(guān)于Android、IOS的部分都放在sdk目錄下了，
    而之前的話，
    所有的設(shè)備類型包括Android、IOS、Window、Mac、Linux的邏輯都是在audio_device目錄下的；
    現(xiàn)在的話Android、IOS被提取出去，
    這里放的是關(guān)于Window、Mac、Linux的文件；

  • audio_mixer：
    混音的概念：
    比如現(xiàn)在有幾個用戶同時在說話，
    這樣子會產(chǎn)生多個音頻流，
    WebRTC則會把這幾個音頻流混合在一起，
    這樣子在傳輸?shù)臅r候就比較方便，
    減少了音頻流總數(shù)；
    那這個混音相關(guān)的邏輯文件，就放在audio_mixer這里；

  • audio_processing：
    音頻前后處理：指回音消除、降噪、增益等處理操作；

  • bitrate_controller：碼率、碼流控制；

  • congestion_controller：
    當我們檢測到網(wǎng)絡(luò)流量比較高的時候，
    我們要做一些流量控制，
    防止網(wǎng)絡(luò)包把帶寬打死；
    相關(guān)處理邏輯 則 放在本文件夾下；

  • 探測碼率之后，對碼率做一個均衡的平滑的處理，再發(fā)送交互；

  • video_processing：
    視頻前后處理：指回音消除、降噪、增益等處理操作；
    如增加人臉識別功能也可以放在這個目錄下；


WebRTC的運行機制

軌

  • Track
  • 視頻與音頻是不相交的，單獨存放；
  • 兩路音頻也是兩路軌，不相交；

流

  • MediaStream
  • 借鑒了傳統(tǒng)媒體流的概念；
    傳統(tǒng)媒體流中也包括了音頻軌、視屏軌等；

WebRTC重要的類

  • MediaStream
    傳輸媒體數(shù)據(jù)；

  • RTCPeerConnection【核心】
    這個WebRTC中最為重要的類，
    是一個大而全的類，包含了很多重要的功能；

    設(shè)計優(yōu)勢：
    在應(yīng)用層應(yīng)用時方便，
    只需要創(chuàng)建一個RTCPeerConnection連接，
    然后把一個MediaStream媒體流搭載上去，
    隨后的細節(jié)就不用管了，
    其中所有的傳輸、尋路等細節(jié)，
    都由RTCPeerConnection內(nèi)部封裝實現(xiàn)了，底層封裝做了很多相關(guān)的工作；

  • RTCDataChannel
    非音視頻的數(shù)據(jù)（如文本文件、二進制數(shù)據(jù)等），都通過RTCDataChannel來傳輸；
    RTCDataChannel是通過RTCPeerConnection獲取的；
    傳輸非音視頻的數(shù)據(jù)時，
    應(yīng)用層要做的，
    就是拿到一個RTCDataChannel對象，把數(shù)據(jù)搭載上去即可；


PeerConnection調(diào)用過程

  • Worker 線程、Signaling線程，
    創(chuàng)建PeerConnectionFactory，
    PeerConnectionFactory可以
    創(chuàng)建PeerConnection、LocalMediaStream、LocalVide/AudioTrack等；

  • 多方進行通訊時，
    每一方（每一個參與單位）都是對應(yīng)一個Stream；

調(diào)用時序圖

  • 首先應(yīng)用層Application【注意這里Application本身就是一個PeerConnectionObserver】，
    創(chuàng)建出一個PeerConnectionFactory【CreatePeerConnectionFactory】；

  • PeerConnectionFactory觸發(fā)CreatePeerConnection、
    CreateLocalMediaStream、CreateLocalVideoTrack、CreateLocalAudioTrack
    創(chuàng)建了PeerConnection、MediaStream等等實例；

  • 然后通過AddTrack，
    把各種軌（track）加到流（LocalMediaStream）中去，
    然后通過AddStream，
    把流加到PeerConnection中；

  • 流加到連接之后，
    會通過CommitStreamChanges提交流的變化；
    當流發(fā)生變化的時候，
    會觸發(fā)OnSignalingMessage事件，創(chuàng)造出一個offer【SDP描述信息】；

  • 有了offer【SDP描述信息】之后，
    就會通過應(yīng)用層【Application】，通過信令，
    發(fā)送到遠端【Send offer to the remote peer】；

【SDP描述信息】內(nèi)容：
有哪些音視頻數(shù)據(jù)，音視頻數(shù)據(jù)的格式分別是什么，傳輸?shù)刂肥鞘裁吹龋?/p>

  • 遠端收到數(shù)據(jù)后，則根據(jù)offerSDP，
    回復(fù)一個answerSDP【Get answer from the remote peer】，
    交給本地信令；

  • 信令收到遠端的answerSDP之后，
    會把信息傳給本地PeerConnection【ProcessSignalingMessage】，
    本地PeerConnection就會拿到對方的媒體流信息、傳輸端口、傳輸?shù)刂罚?/p>

至此，遠端和本地就打通連接，
可以相互傳媒體數(shù)據(jù)；

  • 遠端數(shù)據(jù)來的時候，
    PeerConnection還會將遠端的流添加到Application中去；
    【OnAddStream（注意區(qū)分AddStream）】










參考自：

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點，簡書系信息發(fā)布平臺，僅提供信息存儲服務(wù)。

友情鏈接更多精彩內(nèi)容