一：WebRTC學習了解
（一）WebRTC應用場景
WebRTC的願景就是各瀏覽器之間可以快速開發可以實時互動的音視頻的應用場景！！！
將WebRTC加入瀏覽器，使得瀏覽器的功能更加強大。WebRTC（Web Real-Time Communication）項目的最終目的主要是讓Web開發者能夠基於瀏覽器（Chrome\FireFox\...）輕易快捷開發出豐富的實時多媒體應用，而無需下載安裝任何插件，Web開發者也無需關注多媒體的數字信號處理過程，只需編寫簡單的Javascript程序即可實現，W3C等組織正在制定Javascript 標准API，目前是WebRTC 1.0版本，Draft狀態；另外WebRTC還希望能夠建立一個多互聯網瀏覽器間健壯的實時通信的平台，形成開發者與瀏覽器廠商良好的生態環境。同時，Google也希望和致力於讓WebRTC的技術成為HTML5標准之一，可見Google布局之深遠。
（二）WebRTC的難點
1.過多的協議，WebRTC太龐大、煩雜，門檻高 2.客戶端與服務端分離，WebRTC只有客戶端，沒有服務端，需要自己根據業務實現 3.相關資料少 4.網上代碼錯誤太多
（三）學習流程
（四）學習目標
二：WebRTC介紹
WebRTC與FFmpeg是音視頻領域的兩個佼佼者，兩個側重點不同，FFmpeg側重於多媒體文件的編輯，音視頻的編解碼....;WebRTC側重於處理網絡抖動、丟包、評估以及音頻處理，回音降噪等等。
（一）概述
（二）WebRTC可以實現的功能
（三）WebRTC學習內容
三：WebRTC原理與架構
WebRTC實現了基於網頁的視頻會議，標准是WHATWG 協議，目的是通過瀏覽器提供簡單的javascript就可以達到實時通訊（Real-Time Communications (RTC)）能力。
WebRTC整體架構主要分為兩部分：
第一部分為綠色區域，為webrtc庫所提供的核心功能
第二部分為紫色區域，是瀏覽器提供的javascript的API層---也就是說瀏覽器對webrtc的核心層的C++ API做了一層封裝，封裝成為了javascript接口
第三部分為箭頭區域，是很多的上層應用
調用順序就是從上到下！！！
（一）核心層解析
分為如下4層：
第一層為C++ API，是WebRTC庫提供給瀏覽器javascript層的核心功能API接口（不多，簡單，比如：連接、P2P進行連接、傳輸質量、設備管理....）
第二層為Session層，上下文管理層，音頻、視頻、非音視頻的數據傳輸，都通過session層處理，實現相關邏輯
第三層包括音頻引擎、視頻引擎、傳輸模塊
第四層與硬件相關，包括音視頻的采集、網絡IO （可重載的，可以使用自己的方案）
注意：在webrtc中沒有對視頻進行渲染處理，所以需要我們在應用中自己實現！！
（二）引擎層：音頻引擎、視頻引擎、傳輸模塊
將這3個模塊分隔開來，邏輯更加清晰。另外音視頻的同步不是在引擎層實現
1.音頻引擎：包含一系列音頻多媒體處理的框架，包括從視頻采集卡到網絡傳輸端等整個解決方案。VoiceEngine是WebRTC極具價值的技術之一，是Google收購GIPS公司后開源的。
（1）編解碼器
iSAC（Internet Speech Audio Codec）：針對VoIP和音頻流的寬帶和超寬帶音頻編解碼器，是WebRTC音頻引擎的默認的編解碼器
采樣頻率：16khz，24khz，32khz；（默認為16khz） 自適應速率為10kbit/s ~ 52kbit/s； 自適應包大小：30~60ms； 算法延時：frame + 3ms
iLBC（Internet Low Bitrate Codec）：VoIP音頻流的窄帶語音編解碼器
采樣頻率：8khz；
20ms幀比特率為15.2kbps
30ms幀比特率為13.33kbps
標准由IETF RFC3951和RFC3952定義
（2）防止抖動與丟失
NetEQ for Voice：針對音頻軟件實現的語音信號處理元件
NetEQ算法：自適應抖動控制算法以及語音包丟失隱藏算法。使其能夠快速且高解析度地適應不斷變化的網絡環境，確保音質優美且緩沖延遲最小。
是GIPS公司獨步天下的技術，能夠有效的處理由於網絡抖動和語音包丟失時候對語音質量產生的影響。
PS：NetEQ 也是WebRTC中一個極具價值的技術，對於提高VoIP質量有明顯效果，加以AEC\NR\AGC等模塊集成使用，效果更好。
（3）回音消除、降噪
Acoustic Echo Canceler (AEC) ：回聲消除器是一個基於軟件的信號處理元件，能實時的去除mic采集到的回聲。
Noise Reduction (NR)：噪聲抑制也是一個基於軟件的信號處理元件，用於消除與相關VoIP的某些類型的背景噪聲（嘶嘶聲，風扇噪音等等… …）
2.視頻引擎：包含一系列視頻處理的整體框架，從攝像頭采集視頻到視頻信息網絡傳輸再到視頻顯示整個完整過程的解決方案。
（1）編解碼器：視頻圖像編解碼器，是WebRTC視頻引擎的默認的編解碼器
VP8適合實時通信應用場景，因為它主要是針對低延時而設計的編解碼器。
PS:VPx編解碼器是Google收購ON2公司后開源的，VPx現在是WebM項目的一部分，而WebM項目是Google致力於推動的HTML5標准之一
（2）視頻抖動緩沖器：Video Jitter Buffer，可以降低由於視頻抖動和視頻信息包丟失帶來的不良影響。
（3）圖像質量增強模塊：Image enhancements，對網絡攝像頭采集到的圖像進行處理，包括明暗度檢測、顏色增強、降噪處理等功能，用來提升視頻質量。
3.傳輸：底層使用UDP，上層使用RTP。所有的音視頻的接收與發送，都是通過傳輸模塊實現的。此外在傳輸層實現了網絡鏈路的檢測，進行網絡帶寬的估計，從而對（音視頻、非音視頻）數據的傳輸進行控制。
由於瀏覽器需要安全傳輸，所以使用了SRTP協議，為了進行控制，使用了RTCP;
為了處理多個流復用同一個通道，實現了Multiplexing
最下面實現了P2P相關的協議，比如STUN + TRUN + ICE
補充：雖然UDP很適合實時通訊，但是也有需要使用TCP的場景
連通性TCP要優於UDP，假如國內外通信，可能某些區域不允許通過UDP進行實時傳輸。為了保證連通率，優先選擇UDP，如果UDP無法通信，則選擇TCP，以此來保證連通率。
當然，也存在部分情況，TCP依舊不通，比如通過企業內部網訪問，網關拒絕訪問外網，這時可以使用Https。這時不太保證實時性了
四：WebRTC目錄結構
（一）主目錄結構
api目錄 如果我們要增加接口或者調整接口，就需要到API目錄下去修改相關接口！
call目錄 當與對端進行連接之后，同一個端的流通過Call進行管理;如果與多個對端進行連接，就會存在多個Call
media目錄 內部實現了編解碼的邏輯處理（並沒有實現編解碼內部邏輯，是在Module中實現的），只是對編解碼算法進行了調用控制（決定在哪調用）
mudule目錄 有很多子模塊
pc目錄 代表與對端的連接，可以獲取流，獲取統計信息（上層的統一接口層）
（二）WebRTC Module目錄
audio_mixer目錄 實現混音操作，比如在多人通話時候，需要對多個音頻進行混合處理，這樣在傳輸時比較方便，減少了音頻流
audio_processing目錄 實現音頻的前后處理，比如降噪、回音消除...
video_processing目錄 實現視頻的前后處理，可以添加如人臉識別等操作....
五：WebRTC運行機制
（一）軌與流（流包含多個軌）
軌：比如一路音頻，就是一路軌;一路視頻，也是一路軌。兩條軌之間是不相交的，單獨存放！！兩路音頻也是兩路軌，也是不相交的
流：媒體流，內部包含了很多軌，兩者屬於層級關系
（二）WebRTC的重要類
MediaStream同前面的講解
RTCPeerConnection：是整個WebRTC中最重要的類（大而全），包含了很多的功能。對於應用層非常方便，在應用層只要創建了PeerConnection，然后將流放入PeerConnection中即可，其他的邏輯全部由peerConnection內部實現
RTCDataChannel：對於非音視頻的數據，都通過dataChannel進行傳輸。其中RTCDataChannel是通過RTCPeerConnection獲取的
（三）PeerConnection調用過程
PeerConnection中包含兩個線程，Worker線程和Signaling線程，可以創建PeerConnectionFactory，
之后PerrConnectionFactory可以創建PeerConnection和LocalMediaStream和LocalVideo/AudioTrack
通過AddTrack將我們創建的多個Track軌加入到MediaStream流中，通過AddStream可以將多個MediaStream流（與多方通信，每一方（每一個參與單位）都是對應一個Stream）加入同一個PeerConnection中（復用），
（四）調用時序圖
1.首先應用層Application【注意這里Application本身就是一個PeerConnectionObserver】，創建出一個PeerConnectionFactory【CreatePeerConnectionFactory】；
2.PeerConnectionFactory觸發CreatePeerConnection、CreateLocalMediaStream、CreateLocalVideoTrack、CreateLocalAudioTrack創建了PeerConnection、MediaStream等等實例；
3.然后通過AddTrack，把各種軌（track）加到流（LocalMediaStream）中去，然后通過AddStream，把流加到PeerConnection中；
4.流加到連接之后，會通過CommitStreamChanges提交流的變化；當流發生變化的時候，會觸發OnSignalingMessage事件，創造出一個offer【SDP描述信息】；
5.有了offer【SDP描述信息】之后，就會通過應用層【Application】，通過信令，發送到遠端【Send offer to the remote peer】；
【SDP描述信息】內容：有哪些音視頻數據，音視頻數據的格式分別是什么，傳輸地址是什么等；
6.遠端收到數據后，則根據offerSDP，回復一個answerSDP【Get answer from the remote peer】，交給本地信令；
7.信令收到遠端的answerSDP之后，會把信息傳給本地PeerConnection【ProcessSignalingMessage】，本地PeerConnection就會拿到對方的媒體流信息、傳輸端口、傳輸地址；
至此，遠端和本地就打通連接，可以相互傳媒體數據；
8.遠端數據來的時候，PeerConnection還會將遠端的流添加到Application中去；【OnAddStream（注意區分AddStream）】