標籤:

webrtc調試工具chrome://webrtc-internals的使用手冊-開篇

webrtc調試工具chrome://webrtc-internals的使用手冊-開篇

5 人贊了文章了解webrtc的開發者都應該知道存在chrome://webrtc-internals這樣一個調試工具,在Chome的地址欄中輸入chrome://webrtc-internals這個命令就會展示出有webrtc相關功能被啟用的網頁以及通話過程中產生的統計數據,當我們需要分析一通webrtc通話的音視頻質量的時候,這些統計數據就派上了大用場,由於chrome://webrtc-internals並無官方的說明文檔,有些數據的描述對於非音視頻開發者又不太友好,所以本文簡單地對其中的一些重要的統計數據作了說明。目前還未深入了解的數據我用了TBD作為標識,後續了解了演算法之後我會補充說明。下圖所展示的是音視頻發送端的統計數據:

自頂而下觀察這幅圖,我們將這個圖分為3個部分來說明:

  1. 第一個部分,也就是綠線的上方(圖的頂部)有兩個方塊,第一個方塊展示的是PeerConnection的相關信息,如果有多個PeerConnection的話,那麼就會有多個類似的標籤頁,另外一個方塊展示的是GetUserMedia的相關信息,在本文中我們暫時不涉及。

  2. 第二個部分,在圖中標示的Time和Event區域(圖的上方偏左側),這個部分主要描述的是PeerConnection建立的流程,相關方法調用的次序以及調用的時間。

  3. 第三個部分,在圖中標示的Stats Tables部分(圖的右側以及下半部分),這個部分主要展示的是PeerConnection相關的統計數據,而我們所要說明的就是就是音頻以及視頻流的統計信息。

所有這些統計數據都來源於Chrome M56版本,可能會與老版本的Chrome存在不一致的地方,如果有些欄位的描述不正確,還請指正,我會首先列出發送端的部分描述信息,後續會將接收端的補全。

音頻統計數據

aecDivergentFilterFraction:TBD(後續會補全)

audioInputLevel:發送端採集的音頻能量大小。

bitsSentPerSecond:每秒發送出去的比特數。

packetsSentPerSecond:每秒發送出去的音頻包數。

googEchoCancellationQualityMin:TBD(後續會補全)

googEchoCancellationReturnLoss:TBD(後續會補全)

googEchoCancellationReturnLossEnhancement:TBD(後續會補全)

googResidualEchoLikelihood:Chrome 56中新增的,主要用來標識是否存在回聲,範圍為0 (沒有回聲)- 1(有回聲),當值大於0.5時表明存在回聲。

視頻統計數據

bitsSentPerSecond:每秒發送出去的比特數,根據當前網路情況會進行動態調整。

framesEncoded:累計編碼出來的視頻幀數,沒有異常情況的話會一直增長。

packetsLost:發送端從接收端發送過來的RTCP Receiver Report中得到的累積丟包數量,可以和googNacksReceived數據進行對照。

googRtt:Rtt全稱為Round-trip time,是發送端從接受端發送過來的RTCP Receiver Report中得到的時間戳通過計算得到的往返時延。

packetsSentPerSecond:Chrome 56中新增的,每秒發送出去的視頻包數量。

qpSum:發送端編碼出的帶有QP值的幀的數量,QP全稱為Quantization Parameter。

googAdaptationChanges:發送端因為CPU的負載變化導致的分辨變高或者變低的次數,需要設置googCpuOveruseDetection。

googAvgEncodeMs:發送端平均編碼時間,越小越好。

googEncodeUsagePercent:發送端(平均每幀編碼時間)/(平均每幀採集時間),反應編碼效率。

googFirsReceived:發送端收到的關鍵幀請求數量,FIR全稱為Full Intra Request,一般來說在video conference模式下,有新的參與者進來會發出。

googPlisReceived:發送端收到的關鍵幀請求數量,PLI全稱為Picture Loss Indication,一般來說在解碼失敗時會發出。

googNacksReceived:發送端收到的重傳包請求數量,Nack全稱為Negative ACKnowledgement可以和packetsLost數據進行對照。

googFrameHeightSent:發送端發送的解析度高度,根據當前網路會進行動態調整。

googFrameWidthSent:發送端發送的解析度寬度,根據當前網路會進行動態調整。

googFrameRateInput:發送端設置的初始幀率。

googFrameRateSent:發送端實際發送的幀率,根據當前網路會進行動態調整。
推薦閱讀:

《Learning WebRTC中文版》試讀 + 簽名優惠版
為WebRTC服務選擇H.264的四個理由
互動式連接建立(ICE)
使用 WebRTC 構建簡單的前端視頻通信
展望WebRTC的2017,有希望,有失望

TAG:WebRTC |