webrtc調試工具chrome://webrtc-internals的使用手冊-開篇
5 人贊了文章了解webrtc的開發者都應該知道存在chrome://webrtc-internals這樣一個調試工具,在Chome的地址欄中輸入chrome://webrtc-internals這個命令就會展示出有webrtc相關功能被啟用的網頁以及通話過程中產生的統計數據,當我們需要分析一通webrtc通話的音視頻質量的時候,這些統計數據就派上了大用場,由於chrome://webrtc-internals並無官方的說明文檔,有些數據的描述對於非音視頻開發者又不太友好,所以本文簡單地對其中的一些重要的統計數據作了說明。目前還未深入了解的數據我用了TBD作為標識,後續了解了演算法之後我會補充說明。下圖所展示的是音視頻發送端的統計數據:
自頂而下觀察這幅圖,我們將這個圖分為3個部分來說明:- 第一個部分,也就是綠線的上方(圖的頂部)有兩個方塊,第一個方塊展示的是PeerConnection的相關信息,如果有多個PeerConnection的話,那麼就會有多個類似的標籤頁,另外一個方塊展示的是GetUserMedia的相關信息,在本文中我們暫時不涉及。
- 第二個部分,在圖中標示的Time和Event區域(圖的上方偏左側),這個部分主要描述的是PeerConnection建立的流程,相關方法調用的次序以及調用的時間。
- 第三個部分,在圖中標示的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 |