【入門】WebRTC知識點概覽 | 內有技術乾貨免費下載

時間  2019-12-07
標籤 入門 webrtc 知識 概覽 內有 技術 乾貨 免費 下載 简体版
原文   原文鏈接

WebRTC相關技術說明

什麼是WebRTC

     WebRTC 即Web Real-Time Communication（網頁實時通訊）的縮寫，是一個支持網頁瀏覽器之間進行實時數據傳輸（包括音頻、視頻、數據流）的技術。通過多年的發展與改進，日臻成熟，做爲瀏覽器網頁端的通訊技術，WebRTC與H5巧妙結合，使得網頁端的音視頻通訊變的簡單易行。html

WebRTC有哪些優勢

  • 免費：WebRTC自己是開源的，使用WebRTC自己是免費的。此外WebRTC是能夠不借助媒體服務器實現簡單的點對點音視頻通訊，減小額外花費
  • 無插件：不須要安裝任何軟件，你們只要打開瀏覽器，輸入一個url，便可實現多人音視頻通話。
  • 跨平臺：因爲是基於瀏覽器進行音視頻通話，各個平臺只要有瀏覽器便可。
  • 控制靈活：WebRTC沒有指定具體的信令協議，具體的信令協議留給應用程序實現，這就方便了開發者根據本身的需求方便靈活的實現各類音視頻業務場景。
  • 接合HTML5：HTML5自身的能力可以爲WebRTC提供靈活快捷的音視頻數據的二次處理，能夠實現豐富的業務功能。
  • 易入門：WebRTC是'JavaScript'引擎庫，容許web開發者只使用幾個簡單的api就可以基於瀏覽器輕易快捷開發出豐富的實時多媒體應用，無需關注多媒體的數字信號處理過程，只須要編寫簡單的JavaScript便可，大大的下降了音視頻開發的門檻。

WebRTC距離商用還有多少距離

  • 信令控制協議的開發：上面說明過WebRTC並無實現信令協議，這即帶來了靈活，也帶來了挑戰，想實現一套知足商業應用業務的信令並不容易。
  • 跨平臺的挑戰：即對瀏覽器使用不便，或者不支持瀏覽器（各類盒子或者嵌入式設備）的實際環境的兼容。
  • 音視頻設備的適配：音視頻設備支持的能力不一樣，須要本身的WebRTC產品作複雜的適配處理，才能知足本身的業務場景。
  • 瀏覽器限制：一、並不是全部的瀏覽器都支持WebRTC，具體請參考瀏覽器兼容性 ；二、各個瀏覽器廠商工業實現上的兼容。對於WebRTC，各大瀏覽器廠商實現的並不徹底一致，好比說Safari瀏覽器不支持VP8系列視頻編碼，一些安卓移動設備上Chrome沒法使用H264視頻編碼，還有其餘不少細節問題，想要實現各類平臺，各類瀏覽器之間無障礙的互通，還須要不少工做要作；三、瀏覽器版本更迭的兼容，瀏覽器自己也是在不停的更新對WebRTC的工業實現，也不斷更新對HTML5的使用，這些更新對於咱們的WebRTC產品也是一大挑戰。
  • 須要各類服務器的支持：現實狀況中，WebRTC應用須要信令服務器、媒體服務器、中繼服務器的支持，才能實現信令的有效穩定傳輸、NAT的穿越、媒體的合理路由和轉發，進而保障穩定、高質量的音視頻通話。並且針對大併發量的使用場景，須要合理的媒體處理框架設計，用於保證音視頻服務的可靠性、穩定性。

爲何選擇雲信

  • 專業：一、研發資歷成熟，19年通訊領域研發深耕，億級產品線上驗證，移動端方案優化7年以上；二、全球節點覆蓋異地多機房服務集羣，覆蓋全球範圍，架構靈活高併發自動水平擴容；三、消息必達策略採用動態智能DNS掉線快速重連機制，消息排重持續重連直至到達，保障通訊的接通率；四、海量資源支持全球超500個CDN節點，超10000個分佈式轉碼集羣，千萬播放併發，存儲、寬帶無上限。
  • 接入和使用靈活：網易雲信提供即時通信雲和視頻雲技術的PaaS層服務，以快速集成SDK的模式爲開發者提供穩定易用的技術支撐，客戶能夠方便快捷地接入，全面知足本身的業務需求。
  • 全平臺支持：支持iOS、Android、Windows、Web、Linux、MacOS、微信小程序等主流平臺觀看、互動及互通，支持點對點、多人實時音視頻通話和旁路直播等功能。
  • IM信令：網易雲通訊IM服務基於網易19年的IM技術積累，致力於打造最穩定的即時通信平臺。 IM服務提供了一整套即時通信基礎能力，經過該平臺服務就能夠將即時通信、實時網絡能力快速集成至企業自身應用中。使用IM信令做爲WebRTC產品的信令協議一定能知足用戶的各類需求。
  • WebRTC SDK的能力：雲信SDK兼容各大瀏覽器，各類版本，對於用戶而言全部的瀏覽器類型，全部的版本都是一致的，全部的差別由SDK統一解決，對用戶不可見。

WebRTC相關知識點

關於WebRTC首先明確一些內容:git

WebRTC利用瀏覽器中的JavaScript API和HTML5
WebRTC客戶端之間能夠進行點對點的媒體和數據傳輸
webrtc使用sdp協議做爲媒體協商協議
webrtc使用ice做爲nat穿越的手段
複製代碼

WebRTC 標準API

  • getUserMida：經過getUserMida的API可以經過設備的攝像頭和話筒得到視頻、音頻的同步流；
    • 容許約束媒體能力
    • 獲取的媒體流能夠輸出到video標籤在web頁面上展現；
    • 獲取的媒體流能夠輸出到一個RTCPeerConnection中，用於編碼、發送到對端；
    • 可使用HTML5自己的能力對音頻、視頻作二次處理，好比混頻、混頻、變聲、調色能，將處理後的媒體在推送給對端；
    • 能夠本地錄製獲取到媒體流，也能夠把獲取到媒體流用於他出；
  • RTCPeerConnection：RTCPeerConnection(免費下載《WebRTC 1.0: 瀏覽器間實時通信》中文版）是WebRTC用於構建點對點之間穩定、高效的流傳輸的媒體終端；
    • 進行sdp交換協商媒體
    • 使用ice進行nat穿透
    • dtls協商加密祕鑰
    • srtp加密媒體
    • 媒體編解碼，媒體收發
    • 丟包補償、回聲抵消、帶寬自動調整、動態抖動緩衝、噪聲抑制與抑制等
  • RTCDataChannel：RTCDataChannel(免費下載《WebRTC 1.0: 瀏覽器間實時通信》中文版）使得瀏覽器之間（點對點）創建一個高吞吐量、低延時的信道，用於傳輸任意數據；
    • 利用RTCPeerConnection會話
    • 自定義可靠和不可靠通道
    • dtls
    • 阻塞控制

WebRTC點對點音視頻通訊過程

  • 使用getUserMida接口獲取本地mic、camera上音頻流和視頻流
  • 本地初始化一個RTCPeerConnection實例
  • 將經過getUserMida接口獲取的本地音頻流和視頻流，展現到html頁面上，而且添加到RTCPeerConnection實例中
  • 經過RTCPeerConnection實例獲取本端的sdp信息（本地媒體描述信息）
  • 經過信令協議把本地的sdp發送到對端
  • 經過RTCPeerConnection實例，獲取本地媒體通道地址，而後經過信令協議發送到對端
  • 接收對端的sdp信息、媒體通道地址，而後設置到RTCPeerConnection實例中，這樣就完成了媒體協商
  • 從RTCPeerConnection實例中獲取對端的媒體流，能夠展現到html頁面上

通過上面的步驟，雙方就能進行點對點視頻通話了，後續的nat穿透、dtls協商加密祕鑰、srtp加密媒體、媒體編解碼，媒體收發都由瀏覽器自動完成。github

Chrome屏幕共享功能的實現

    上面說明獲取攝像頭的媒體流是經過getUserMida接口，而獲取屏幕共享則是經過其餘的方式；web

  • 使用getDisplayMedia接口（chrome 72版本開始支持）

使用方式同getUserMedia接口一致，代碼以下：算法

if (navigator.getDisplayMedia) {
      return navigator.getDisplayMedia({video: true});
    } else if (navigator.mediaDevices.getDisplayMedia) {
      return navigator.mediaDevices.getDisplayMedia({video: true});
    }
複製代碼
  • 經過插件的方式
    • 本身編寫extension插件擴展，使用chrome.desktopCapture.chooseDesktopMedia接口（插件是通過了認證的，瀏覽器不會阻止其運行），調用這個接口時，瀏覽器彈出包含各類共享內容（包括屏幕、應用列表、chrome標籤頁）的彈窗。用戶能夠選擇本身想要共享的內容，選定以後，該接口會返回相應的chromeMediaSourceId，而後使用getUserMeida接口把chromeMediaSourceId做爲約束條件，就可以獲取到共享的媒體流。

插件代碼以下：chrome

chrome.runtime.onMessageExternal.addListener((message, sender, sendResponse) => {
    const sources = message.sources;
    const tab = sender.tab;  
    chrome.desktopCapture.chooseDesktopMedia(sources, tab, streamId => {
      if (!streamId) {
        sendResponse({
          type: 'error',
          message: 'Failed to get stream ID'
        });
      } else {
        sendResponse({
          type: 'success',
          streamId: streamId
        });
      }
    });
    return true;
  }
);

chrome.runtime.onInstalled.addListener(function(){
  chrome.declarativeContent.onPageChanged.removeRules(undefined, function(){
    chrome.declarativeContent.onPageChanged.addRules([
        {
            conditions: [
              new chrome.declarativeContent.PageStateMatcher({ pageUrl: { urlContains: 'app.netease.im'}})
            ],
            actions: [new chrome.declarativeContent.ShowPageAction()]
        }
    ]);
  });
});
複製代碼

getUserMedia接口的使用以下：小程序

chrome.runtime.sendMessage(EXTENSION_ID, { sources: ['window', 'screen', 'tab'] }, {}, response => {
    if (response && response.type === 'success') {
      const constraint = {
        video: {
          mandatory: {
            chromeMediaSource: 'desktop',
            chromeMediaSourceId: response.streamId
          }
        }
      }
      return navigator.mediaDevices.getUserMedia(constraint)(constraint)
        .then(stream => {
          console.log('獲取到演示流:', stream.id)
        })
    }
})
複製代碼

Chrome 72版本unified plan適配

    對WebRTC而言，Unified Plan、Plan B、Plan A是SDP中多路媒體流的協商方式，在72版本中Chrome替換了Plan B，默認使用Unified Plan。微信小程序

https://webrtc.github.io/samples/src/content/peerconnection/pc1/, { iceServers: [], iceTransportPolicy: all, bundlePolicy: balanced, rtcpMuxPolicy: require, iceCandidatePoolSize: 0, sdpSemantics: "unified-plan" },
複製代碼
  • Plan B：sdp中，一個m行描述多路media stream，以msid 做爲區分；
...
a=group:BUNDLE audio
a=msid-semantic: WMS stream-id-2 stream-id-1
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126
...
a=mid:audio
...
a=rtpmap:103 ISAC/16000
...
a=ssrc:10 cname:cname
a=ssrc:10 msid:stream-id-1 track-id-1
a=ssrc:10 mslabel:stream-id-1
a=ssrc:10 label:track-id-1
a=ssrc:11 cname:cname
a=ssrc:11 msid:stream-id-2 track-id-2
a=ssrc:11 mslabel:stream-id-2
a=ssrc:11 label:track-id-2
複製代碼
  • Unified Plan：sdp中，一個m行對應一個meida stream；
...
a=group:BUNDLE 0 1
a=msid-semantic: WMS
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126
...
a=mid:0
...
a=sendrecv
a=msid:- <track-id-1>
...
a=rtpmap:103 ISAC/16000
...
a=ssrc:10 cname:cname
a=ssrc:10 msid: track-id-1
a=ssrc:10 mslabel:
a=ssrc:10 label:track-id-1
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126
...
a=mid:1
...
a=sendrecv
a=msid:- track-id-2
...
a=rtpmap:103 ISAC/16000
...
a=ssrc:11 cname:cname
a=ssrc:11 msid: track-id-2
a=ssrc:11 mslabel:
a=ssrc:11 label:track-id-2

複製代碼

1、點對點視頻通話業務api

  一、WebRTC產品中沒有處理過sdp中的msid屬性瀏覽器

      不用適配，這次的更新對你的產品沒有影響

  二、WebRTC產品中有處理sdp中的msid屬性

      須要適配，凡是針對msid的判斷和修改都須要廢棄，從新處理

2、多流業務，使用了simulcast

  一、WebRTC產品中沒有處理過sdp中的msid屬性

      須要適配，調整接口使用，調整sdp的解析處理，增長多m行的處理

  二、WebRTC產品中有處理sdp中的msid屬性

      須要適配，凡是針對msid的判斷和修改都須要廢棄，從新處理，調整接口使用，調整sdp的解析處理，增長多m行的處理


WebRTC調試

Chrome瀏覽器查看WebRTC狀態方法：

chrome：chrome://webrtc-internals

瀏覽器中輸入chrome://webrtc-internals，界面顯示以下：

WebRTC狀態圖說明： 最上面一排依次是：getUserMedia API、二個peerconnection API

  • 點擊查看getUserMedia API，簡單說明以下：
Caller origin: https://webrtc.github.io
Caller process id: 15364
Audio Constraints
Video Constraints
{width: {min: 300, max: 640}, height: {min: 200, max: 480}}
複製代碼
  • Audio Constraints：表示從麥克風獲取視屏流的參數；
  • Video Constraints：表示從攝像頭獲取視屏流的參數；

PeerConnection狀態圖說明：

  • 最上面的一行：表示peerconnection，大括號中的內容是peerconnection的配置參數，能夠看到chrome已經用unified-plan替代了plan B；
  • 左上角的Event：peerconnection的內部接口，對應的是內部接口
  • 右上角的EventStats Tables：是媒體通道的具體信息，數據實時更新
    • bweforvideo (VideoBwe)：視頻帶寬相關信息
      • googActualEncBitrate：視頻編碼器實際編碼的碼率，一般這與目標碼率是匹配的。
      • googAvailableReceiveBandwidth：視頻數據接收可用的帶寬。
      • googAvailableSendBandwidth：視頻數據發送可用的帶寬。
      • googBucketDelay：Google爲了處理大數據速率的策略表示，一般是很小的數值。
      • googRetransmitBitrate：若是RTX被使用的話，表示重傳的碼率。
      • googTargetEncBitrate：視頻編碼器的目標比特率。
      • googTansmitBitrate：實際發送的碼率，若是此數值與googActualEncBitrate有較大的出入，多是fec的影響。
    • googCertificate：兩端使用的DTLS證書、指紋和哈希算法等
    • googComponent：表示認證數據與鏈接之間的關係，展現當前活躍的候選項對，以及有關用語DTLS和SRTP加密的相關信息。
    • Conn-video-1-0 (googCandidatePair)：RTP通道相關信息
      • googActiveConnection：當前的鏈接是否活躍
      • bytesReceived：接收的字節數（rtp數據）
      • bytesSent：發送的的字節數（rtp數據）
      • packetsSent：發送的數據包數（rtp數據）
      • requestsSent、responsesSent、requestsReceived、responsesReceived：STUN請求和應答數量
      • googRtt：最近的STUN請求的往返時間
      • googLocalAddress：本地的候選地址juejin
      • googRemoteAddress：遠端的候選地址
      • googTransportType：傳輸通道的類型，一般是udp，即便當前正在使用tcp的鏈接方式經過turn中繼服務器轉發媒體，只有當ICE-TCP被選用時，這裏纔會是tcp
    • Conn-video-1-1 (googCandidatePair)：RTCP通道相關
    • ssrc_2052494919_send (ssrc)：音頻發送通道相關信息
      • audioInputLevel：mic採集的音頻能量值
      • audioOutputLevel：揚聲器播出的音頻能力值
      • bytesSent：發送的音頻數據字節數
      • mediaType：媒體類型
      • packetsSent：發送的音頻包數
      • ssrc：音頻rtp包的ssrc
      • googCodecName：音頻編碼名稱
      • googJitterReceived：收到了多少的抖動
      • googRtt：是發送端從接受端發送過來的RTCP Receiver Report中獲得的時間戳經過計算獲得的往返時延
    • ssrc_4160516329_send (ssrc)：視頻發送通道相關信息
      • bytesSent：發送視頻包的本身數
      • codecImplementationName：視頻編碼器的名稱
      • framesEncoded：累計編碼出來的視頻幀數
      • mediaType：媒體類型
      • packetsLost：丟包數
      • packetsSent：發送的視頻包數
      • qpSum：QP數目
      • ssrc：視頻rtp包的ssrc
      • googTrackId：描述視頻數據軌跡，這個id能夠在SDP中，以及本地或遠端媒體流軌道中被找到
      • googAdaptationChanges：發送端由於CPU的負載變化致使的分辨變高或者變低的次數，須要設置googCpuOveruseDetection
      • googAvgEncodeMs：發送端平均編碼時間，越小越好。
      • googBandwidthLimitedResolution：是否由於帶寬受限而下降發送的視頻分辨率
      • googCodecName：視頻編碼名稱
      • googCpuLimitedResolution：是否由於cpu不足而下降發送的視頻分辨率
      • googEncodeUsagePercent：發送端（平均每幀編碼時間）／（平均每幀採集時間），反應編碼效率
      • googFirsReceived：收到的fir請求
      • googFrameHeightSent、googFrameWidthSent：發送的視頻分辨率
      • googFrameRateInput、googFrameRateSent：視頻幀率
      • googHasEnteredLowResolution：是否已經下降了視頻分辨率
      • googNacksReceived：收到的nack請求
      • googPlisReceived：收到的pli請求
      • googRtt：是發送端從接受端發送過來的RTCP Receiver Report中獲得的時間戳經過計算獲得的往返時延
      • transportId，是指向被用於傳送RTP流的部分，能夠從sdp總找到
  • 左下角的部分：也是媒體通道的具體信息，以圖表的形式展現，與右上角的EventStats Tables一一對應
    • bweforvideo (VideoBwe)：視頻帶寬相關信息
      • googActualEncBitrate：視頻編碼器實際編碼的碼率，一般這與目標碼率是匹配的。
      • googAvailableReceiveBandwidth：視頻數據接收可用的帶寬。
      • googAvailableSendBandwidth：視頻數據發送可用的帶寬。
      • googBucketDelay：Google爲了處理大數據速率的策略表示，一般是很小的數值。
      • googRetransmitBitrate：若是RTX被使用的話，表示重傳的碼率。
      • googTargetEncBitrate：視頻編碼器的目標比特率。
      • googTansmitBitrate：實際發送的碼率，若是此數值與googActualEncBitrate有較大的出入，多是fec的影響。
    • googCertificate：兩端使用的DTLS證書、指紋和哈希算法等
    • googComponent：表示認證數據與鏈接之間的關係，展現當前活躍的候選項對，以及有關用語DTLS和SRTP加密的相關信息。
    • Conn-video-1-0 (googCandidatePair)：RTP通道相關信息
      • googActiveConnection：當前的鏈接是否活躍
      • bytesReceived：接收的字節數（rtp數據）
      • bytesSent：發送的的字節數（rtp數據）
      • packetsSent：發送的數據包數（rtp數據）
      • requestsSent、responsesSent、requestsReceived、responsesReceived：STUN請求和應答數量
      • googRtt：最近的STUN請求的往返時間
      • googLocalAddress：本地的候選地址
      • googRemoteAddress：遠端的候選地址
      • googTransportType：傳輸通道的類型，一般是udp，即便當前正在使用tcp的鏈接方式經過turn中繼服務器轉發媒體，只有當ICE-TCP被選用時，這裏纔會是tcp
    • Conn-video-1-1 (googCandidatePair)：RTCP通道相關
    • ssrc_2052494919_send (ssrc)：音頻發送通道相關信息
      • audioInputLevel：mic採集的音頻能量值
      • audioOutputLevel：揚聲器播出的音頻能力值
      • bytesSent：發送的音頻數據字節數
      • mediaType：媒體類型
      • packetsSent：發送的音頻包數
      • ssrc：音頻rtp包的ssrc
      • googCodecName：音頻編碼名稱
      • googJitterReceived：收到了多少的抖動
      • googRtt：是發送端從接受端發送過來的RTCP Receiver Report中獲得的時間戳經過計算獲得的往返時延
    • ssrc_4160516329_send (ssrc)：視頻發送通道相關信息
      • bytesSent：發送視頻包的本身數
      • codecImplementationName：視頻編碼器的名稱
      • framesEncoded：累計編碼出來的視頻幀數
      • mediaType：媒體類型
      • packetsLost：丟包數
      • packetsSent：發送的視頻包數
      • qpSum：QP數目
      • ssrc：視頻rtp包的ssrc
      • googTrackId：描述視頻數據軌跡，這個id能夠在SDP中，以及本地或遠端媒體流軌道中被找到
      • googAdaptationChanges：發送端由於CPU的負載變化致使的分辨變高或者變低的次數，須要設置googCpuOveruseDetection
      • googAvgEncodeMs：發送端平均編碼時間，越小越好。
      • googBandwidthLimitedResolution：是否由於帶寬受限而下降發送的視頻分辨率
      • googCodecName：視頻編碼名稱
      • googCpuLimitedResolution：是否由於cpu不足而下降發送的視頻分辨率
      • googEncodeUsagePercent：發送端（平均每幀編碼時間）／（平均每幀採集時間），反應編碼效率
      • googFirsReceived：收到的fir請求
      • googFrameHeightSent、googFrameWidthSent：發送的視頻分辨率
      • googFrameRateInput、googFrameRateSent：視頻幀率
      • googHasEnteredLowResolution：是否已經下降了視頻分辨率
      • googNacksReceived：收到的nack請求
      • googPlisReceived：收到的pli請求
      • googRtt：是發送端從接受端發送過來的RTCP Receiver Report中獲得的時間戳經過計算獲得的往返時延
      • transportId，是指向被用於傳送RTP流的部分，能夠從sdp總找到
        網易雲信翻譯了W3C推薦標準WebRTC 1.0: Real-time Communication Between Browsers，並提供《WebRTC1.0: 瀏覽器間實時通信》中文版免費下載。

本文是WebRTC工做組最新一次會議後的候選推薦標準，基於WebIDL定義了一組ECMAScript API，容許在實現了相關實時協議的瀏覽器或設備之間發送和接收媒體內容。同時也是對WebRTC的一個全面介紹，包括WebRTC中的各個術語，獨有的概念，API的使用規範，詳細的算法流程和一些注意點，而且對涉及的數據結構及其屬性進行了剖析。在特定的使用場景下，草案的做者們還附上了示例代碼。

• 對於WebRTC初學者，本文檔能夠做爲學習教程，幫助你快速對WebRTC有全面且詳細的瞭解，學習相關API的使用，其附帶的示例代碼也是很好的學習資料；
• 對於WebRTC資深開發者，本文檔能夠做爲開發中的使用手冊，根據所提供的函數調用鏈或是算法流程進行開發或bug定位；
• 對於高階玩家，也可經過閱讀本文檔對WebRTC工做組反饋改進意見。

限時免費下載，WebRTC開發者必備，機不可失哦~
相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程