WebRTC內置debug工具，詳細參數解讀 chrome://webrtc-internals/

爲了確保這篇文章所寫內容儘量的準確，我決定請來Philipp Hancke來做爲此篇文章的共同做者。

當你想要找到你WebRTC產品中的問題時，webrtc-internals是一個很是棒的工具，由於你須要用它測試WebRTC以及debug，或者你須要對你的配置進行微調。

 

如何得到webrtc-internals的數據轉儲（statsdump）？▼ 

若是你對這個工具不熟悉的話，那麼打開你Chrome瀏覽器裏的WebRTC段，在這段裏打開另外一個表單而且將其指向這個內部（internal）URL：chrome://webrtc-internals/

webrtc-internals容許將軌道做爲大型的JSON下載下來，這樣你就能夠一層一層地來看它了，可是當你這麼作的時候，你會看到相似這樣的東西：

 

 

查看webrtc-internals數據

人們一般問到的第一件事是—這些數字到底表明什麼？一位咱們本身的測試人員將這些值放入時序圖表裏而且將其輸出出來。這就給了咱們要比直接從webrtc-internals中取出的300×140的圖片要大的多的圖表。

 

這些圖表是使用HighCharts庫獲得的，而且有不少十分方便的特性，好比隱藏線條，放大所需區域，或者停靠在特定點處並顯示精確值。這比用JSON轉儲（像上面同樣）要方便的多。

回到基礎的webrtc-internals頁中。在此頁頂端，咱們能夠考到一系列的表單，一個是給getUserMedia調用的，剩下的兩個分別給每一個RTCPeerConnection。

 

在GetUserMedia請求表單中，咱們能夠看到每次的getUserMedia調用，以及相關約束。不幸的是，咱們不能看到結果或者MediaStreams中有的ids。

 

RTCPeerConnection數據

對於每一個peerconnection，咱們能夠在這裏看到這四點：

 

 

1. RTCPeerConnection是如何配置的，也就是STUN和TURN服務器是如何被使用的，以及如何配置
2. PeerConnection API的軌跡被調用顯示在左邊。這些API軌跡展示了全部的RTCPeerConnection調用和他們的參數（例如createOffer），以及回調和相似於onicecandidate的事件觸發器
3. 從getStats() API採集的數據在右側被顯示出來
4. 由getStats() API產生的圖表在底部顯示

 

RTCPeerConnection API軌跡是很是強大的工具，能夠幫助你完成不少的事情，好比分析形成ICE失敗的緣由，或者幫你找到適合部署TURN服務器的地方。咱們會在之後的博文中來談這些。

webrtc-internals所給出的統計數據是Chrome的內部格式。這意味着其與目前的規範略有不一樣步，一些名稱和結構體會有改變。在較高層，咱們在webrtc-internals頁上看到的與咱們調用這個函數所獲得的結果相近：

 

 

下面是RTCStatsReport對象的隊列，其中有不少祕鑰和數值，能夠這樣讀取：

 

要記住的是在這些統計數據和規範之間有一些區別。這裏面有一個經驗法則，任意一個名稱以「Id」結尾的祕鑰都包含一個指向不一樣的報告，其id屬性與祕鑰的值對應。因此所有這些報告都是彼此相連的。還要注意，這些值都是字符型的，儘管它們看起來像布爾值那樣的數字。

RTCStatsReport中最重要的屬性是報告的種類，下面是其中的幾種：

• googTrack
• googLibjingleSession
• googCertificate
• googComponent
• googCandidatePare
• localCandidate
• remoteCandidate
• ssrc
• VideoBWE

 

讓咱們來深刻探討一下這些報告型

googTrack與googLibjingleSession報告

googTrack和googLibjingleSession沒包含什麼信息，因此咱們跳過它不作分析。

googCertificate報告

googCertificate報告包括了一些有關近端和對等端所使用的DTLS證書的信息，以及指紋和哈希算法。這些都在RTCCertificateStats字典中有詳細說明。

googComponent報告

googComponent報告的做用就像是認證數據與鏈接之間的膠水。它包含了一個紙箱當前活躍的候選項對的指針，以及有關用語DTLS和SRTP加密的加密套接字。

googCandidatePair報告

googCandidatePair對一對ICE候選作了描述，也就是低層次的鏈接。從這個報告中，你能夠獲得這些信息：

 

• 發送和接收的數據包以及字節數總數（bytesSent，bytesReceived，packetsSent；由於不明緣由丟失的packetsReceived）。這是一個包含RTP報頭的UDP或者TCP字節。
• 如何判斷這是不是一個活躍的鏈接，googActiveConnection的值是真則爲活躍，不然爲假。大多數時間你都會只對活躍的候選對感興趣。對等的規範能夠在這裏找到。
• 被髮送和接收的STUN請求和應答數量是計算在ICE進程中輸入和輸出的STUN請求數量。
• googRtt是最新的STUN請求的往返時間。這與ssrc報告上的googRtt是不同的，咱們稍後會說。
• localCandidateId和remoteCandidateId指向localCandidate型和remoteCandidate型。localCandidate和remoteCandidate描述了本地和遠端的ICE候選項。你能夠在googLocalAddress型上面找到絕大多數信息。
• googTr以及googLocalCandidateType的值。
• googTransportType規定了傳輸的類型。注意這些數據的值一般是「udp」的，即使是在TCP上的TURN被用於鏈接TURN服務器的狀況下。只有當ICE-TCP被使用時，此值纔會是「tcp」的。

 

從下面這張圖上能夠比較直觀地看到一些數據，如發送和接收的字節數等等：

 

 

localCandidate和remoteCandidate報告

感謝上天localCandidate和remoteCandidate與規範中所描述的是如出一轍的，告訴咱們ip地址，端口號，以及候選項的類型。對於TURN候選來講，其會告訴咱們候選被分配在哪一個端口上了。  

Ssrc報告

ssrc報告是這裏面最重要的報告之一。每個音頻或者視頻軌道發送或接收都有一個ssrc報告。在舊版本的規範中，這些叫作MediaStreamTrackStats和RTPStreamStats。其內容決定於這是音頻仍是視頻軌道，以及這是發送仍是接收。讓咱們先來描述下一些其中基本的元素：

• mediaType表示咱們在觀察的是音頻數據仍是視頻數據
• ssrc屬性指定了媒體是發送ssrc仍是接收
• googTrackId會識別這些數據描述的軌跡。這個id能夠在SDP中，以及本地或遠端媒體流軌道中被找到。事實上，這違背了以「Id」爲後綴的命名法則，一般以「Id」結束的都是一個指向其餘報告的指針。Google把goog stats給搞錯了。
• googRtt表示的是往返時間。與以前說過的往返時間不一樣，這個往返時間是從RTCP測量的時間。
• transportId，是指向被用於傳送RTP流的部分。一般用於音頻和視頻流的transportId是同樣的。
• googCodecName規定了編譯碼器的名稱。典型的音頻編解碼器是opus，對於視頻來講，使用的是VP8，VP9或者使用H264。你還能夠看到在codecImplementationName統計數據中使用的實施方案的有關信息。
• bytesSent，bytesReceived，packetsSent以及packetsReceived的值可讓你計算出總的字節數。這些數字是累加的，因此你須要在你最後一次詢問getStats以後要將其按時間分開。規定中的示例代碼寫的還不錯，單是要注意Chrome有事會將這些計數器重置，因此你有可能獲得一個負數的速率。
• packetsLost讓你知道有多少包在傳輸過程當中丟失了。對於發送端來講，丟包來自RTCP，對於接收端來講，丟包是在本地測量的。當你在檢查一個質量很差的通話時，這個參數多是你想要查看的最直接的數據。

 

音頻特性

 

對於音軌來講，咱們有audioInputLevel和audioOutputLevel（在規範中叫作audioLevel）能夠告訴咱們音頻信號是來與麥克風，仍是經過揚聲器播出的。這個特性能夠用來探測Chrome裏不受歡迎的音頻bug。咱們還能夠經過googJitterReceived和googJitterBufferReceived得知有多少抖動被接收，以及jitter buffer的狀態。

 

視頻特性

 

對於視頻軌道來講，咱們有兩大信息須要關注。第一個是被送入googNacksSent，googPLIsSent和googFirsSent中，NACK，PLI和FIR數據包的數量差異。這可讓咱們知道丟包會如何影響視頻質量。

 

更重要的是，咱們得知了框架大小和速率是做爲輸入（googFrameWidthInput，googFrameHeightInput，googFrameRateInput）而且實時上是發送到網絡之上（googFrameWidthSent，googFrameHeightSent，googFrameRateSent）。

類似的數據能夠在接收端被收集到存在googFrameWidthReceived，googFrameHeightReceived中。對於框架速率來講咱們甚至能夠將其從googFrameRateReceived，googFrameRateDecoded和GOOGFrameRateOutput中分開來。

在編碼端咱們能夠看到這些值之間的差異，還能知道爲何圖片會被縮小。一般這些事情發生不是由於沒有足夠大的CPU，就是沒有足夠大的帶寬來傳送完整的圖片。另外，想要下降框架速率（其能夠從對比googFrameRateInput和googFrameRateSent之間的差距獲得），咱們須要獲得額外的信息：分辨率是否由於CPU的問題而獲得適應，以及是不是由於帶寬不夠使得googBandwidthLimitedResolution的值是真。不管是上述哪一個狀況發生了改變，googAdaptionChanges計數器都會增長。

咱們能夠從這張圖表上看到這些變化：

 

這裏的丟包是人爲產生的。做爲反應，Chrome在t=184時第一次嘗試下降分辨率，這是綠線表明的googFrameWidthSent開始偏離黑線表明的googFrameWidthInput。接下來在t=186時，框架開始降低，輸入框架速率（淺藍色線條所示）大約是30fps，與發出的框架速率（藍色線條所示）產生區別，後者幾乎是0.

 

另外，Chrome在ssrc報告中公開了大量關於音頻和視頻堆棧的表現的數據。咱們會在將來的博文中進行討論。

 

• VideoBWE報告

 

最後，但並非不重要，咱們來分析一下VideoBWE報告。就像它名字所表達的，它包括有關帶寬估計的信息。可是還有一些其餘的有用信息包含在這個報告裏：

• googAvailableReceiveBandwidth—對於接收視頻數據可用的帶寬。
• googAvailableSendBandwidth—對於發送視頻數據可用的帶寬。
• googTargetEncBitrate—視頻編碼器的目標比特率。這項指標會嘗試填滿可用的帶寬。
• googActualEncBitrate—視頻編碼器輸出的比特率。一般這與目標比特率是匹配的。
• googTansmitBitrate—這個比特率是實際傳輸的比特率。若是此數值與實際編碼比特率有較大的差異，那麼多是由於前向錯誤糾正形成的。
• googRetransmitBitrate—若是RTX被使用的話，這項容許測量重傳的比特率。此數據一般表明丟包率。
• googBucketDelay—是Google爲了處理大框架速率的策略表示。一般是很小的數值。

 

正如你看到的，這個報告會給你視頻質量最重要的信息—可用帶寬。查看發送和接收的可用帶寬一般都是在深刻分析ssrc報告以前作的最重要的事。由於有時你可能會發現這樣的狀況，這解釋了用戶所抱怨的「質量差」：

在這種狀況下，「在全部時間裏，帶寬估計都在降低」是對質量問題的一個比較好的解釋。

 

原做者：Levent-Levi

翻譯：劉通

原文連接：http://testrtc.com/webrtc-internals-parameters/