WebRTC內(nèi)置debug工具怎么用

小編給大家分享一下WebRTC內(nèi)置debug工具怎么用，希望大家閱讀完這篇文章之后都有所收獲，下面讓我們一起去探討吧！

當(dāng)你想要找到你WebRTC產(chǎn)品中的問(wèn)題時(shí)，webrtc-internals是一個(gè)非常棒的工具，因?yàn)槟阈枰盟鼫y(cè)試WebRTC以及debug，或者你需要對(duì)你的配置進(jìn)行微調(diào)。

如何獲得webrtc-internals的數(shù)據(jù)轉(zhuǎn)儲(chǔ)（stats dump）？

如果你對(duì)這個(gè)工具不熟悉的話，那么打開(kāi)你Chrome瀏覽器里的WebRTC段，在這段里打開(kāi)另一個(gè)表單并且將其指向這個(gè)內(nèi)部（internal）URL：chrome://webrtc-internals/

webrtc-internals允許將軌道作為大型的JSON下載下來(lái)，這樣你就可以一層一層地來(lái)看它了，但是當(dāng)你這么做的時(shí)候，你會(huì)看到類(lèi)似這樣的東西：

查看webrtc-internals數(shù)據(jù) 

人們通常問(wèn)到的第一件事是—這些數(shù)字到底代表什么？一位我們自己的測(cè)試人員將這些值放入時(shí)序圖表里并且將其輸出出來(lái)。這就給了我們要比直接從webrtc-internals中取出的300×140的圖片要大的多的圖表。

在GetUserMedia請(qǐng)求表單中，我們可以看到每次的getUserMedia調(diào)用，以及相關(guān)約束。不幸的是，我們不能看到結(jié)果或者M(jìn)ediaStreams中有的ids。

RTCPeerConnection數(shù)據(jù) 

對(duì)于每個(gè)peerconnection，我們可以在這里看到這四點(diǎn)：

下面是RTCStatsReport對(duì)象的隊(duì)列，其中有很多秘鑰和數(shù)值，可以這樣讀?。?/p>

要記住的是在這些統(tǒng)計(jì)數(shù)據(jù)和規(guī)范之間有一些區(qū)別。這里面有一個(gè)經(jīng)驗(yàn)法則，任意一個(gè)名稱(chēng)以“Id”結(jié)尾的秘鑰都包含一個(gè)指向不同的報(bào)告，其id屬性與秘鑰的值對(duì)應(yīng)。所以全部這些報(bào)告都是彼此相連的。還要注意，這些值都是字符型的，盡管它們看起來(lái)像布爾值那樣的數(shù)字。

RTCStatsReport中最重要的屬性是報(bào)告的種類(lèi)，下面是其中的幾種：

• googTrack

• googLibjingleSession

• googCertificate

• googComponent

• googCandidatePare

• localCandidate

• remoteCandidate

• ssrc

• VideoBWE

讓我們來(lái)深入探討一下這些報(bào)告型

googTrack與googLibjingleSession報(bào)告

googTrack和googLibjingleSession沒(méi)包含什么信息，所以我們跳過(guò)它不做分析。

googCertificate報(bào)告

googCertificate報(bào)告包括了一些有關(guān)近端和對(duì)等端所使用的DTLS證書(shū)的信息，以及指紋和哈希算法。這些都在RTCCertificateStats字典中有詳細(xì)說(shuō)明。

googComponent報(bào)告

googComponent報(bào)告的作用就像是認(rèn)證數(shù)據(jù)與連接之間的膠水。它包含了一個(gè)紙箱當(dāng)前活躍的候選項(xiàng)對(duì)的指針，以及有關(guān)用語(yǔ)DTLS和SRTP加密的加密套接字。

googCandidatePair報(bào)告

googCandidatePair對(duì)一對(duì)ICE候選做了描述，也就是低層次的連接。從這個(gè)報(bào)告中，你可以得到這些信息：

• 發(fā)送和接收的數(shù)據(jù)包以及字節(jié)數(shù)總數(shù)（bytesSent，bytesReceived，packetsSent；因?yàn)椴幻髟騺G失的packetsReceived）。這是一個(gè)包含RTP報(bào)頭的UDP或者TCP字節(jié)。

• 如何判斷這是否是一個(gè)活躍的連接，googActiveConnection的值是真則為活躍，否則為假。大多數(shù)時(shí)間你都會(huì)只對(duì)活躍的候選對(duì)感興趣。對(duì)等的規(guī)范可以在這里找到。

• 被發(fā)送和接收的STUN請(qǐng)求和應(yīng)答數(shù)量是計(jì)算在ICE進(jìn)程中輸入和輸出的STUN請(qǐng)求數(shù)量。

• googRtt是最新的STUN請(qǐng)求的往返時(shí)間。這與ssrc報(bào)告上的googRtt是不一樣的，我們稍后會(huì)說(shuō)。

• localCandidateId和remoteCandidateId指向localCandidate型和remoteCandidate型。localCandidate和remoteCandidate描述了本地和遠(yuǎn)端的ICE候選項(xiàng)。你可以在googLocalAddress型上面找到絕大多數(shù)信息。

• googTr以及googLocalCandidateType的值。

• googTransportType規(guī)定了傳輸?shù)念?lèi)型。注意這些數(shù)據(jù)的值通常是“udp”的，即便是在TCP上的TURN被用于連接TURN服務(wù)器的情況下。只有當(dāng)ICE-TCP被使用時(shí)，此值才會(huì)是“tcp”的。

從下面這張圖上可以比較直觀地看到一些數(shù)據(jù)，如發(fā)送和接收的字節(jié)數(shù)等等：

 

localCandidate和remoteCandidate報(bào)告

感謝上天localCandidate和remoteCandidate與規(guī)范中所描述的是一模一樣的，告訴我們ip地址，端口號(hào)，以及候選項(xiàng)的類(lèi)型。對(duì)于TURN候選來(lái)說(shuō)，其會(huì)告訴我們候選被分配在哪個(gè)端口上了。  

Ssrc報(bào)告

ssrc報(bào)告是這里面最重要的報(bào)告之一。每一個(gè)音頻或者視頻軌道發(fā)送或接收都有一個(gè)ssrc報(bào)告。在舊版本的規(guī)范中，這些叫做MediaStreamTrackStats和RTPStreamStats。其內(nèi)容決定于這是音頻還是視頻軌道，以及這是發(fā)送還是接收。讓我們先來(lái)描述下一些其中基本的元素：

• mediaType表示我們?cè)谟^察的是音頻數(shù)據(jù)還是視頻數(shù)據(jù)

• ssrc屬性指定了媒體是發(fā)送ssrc還是接收

• googTrackId會(huì)識(shí)別這些數(shù)據(jù)描述的軌跡。這個(gè)id可以在SDP中，以及本地或遠(yuǎn)端媒體流軌道中被找到。事實(shí)上，這違背了以“Id”為后綴的命名法則，通常以“Id”結(jié)束的都是一個(gè)指向其他報(bào)告的指針。Google把goog stats給搞錯(cuò)了。

• googRtt表示的是往返時(shí)間。與之前說(shuō)過(guò)的往返時(shí)間不同，這個(gè)往返時(shí)間是從RTCP測(cè)量的時(shí)間。

• transportId，是指向被用于傳送RTP流的部分。通常用于音頻和視頻流的transportId是一樣的。

• googCodecName規(guī)定了編譯碼器的名稱(chēng)。典型的音頻編解碼器是opus，對(duì)于視頻來(lái)說(shuō)，使用的是VP8，VP9或者使用H264。你還可以看到在codecImplementationName統(tǒng)計(jì)數(shù)據(jù)中使用的實(shí)施方案的有關(guān)信息。

• bytesSent，bytesReceived，packetsSent以及packetsReceived的值可以讓你計(jì)算出總的字節(jié)數(shù)。這些數(shù)字是累加的，所以你需要在你最后一次詢(xún)問(wèn)getStats之后要將其根據(jù)時(shí)間分開(kāi)。規(guī)定中的示例代碼寫(xiě)的還不錯(cuò)，單是要注意Chrome有事會(huì)將這些計(jì)數(shù)器重置，所以你有可能得到一個(gè)負(fù)數(shù)的速率。

• packetsLost讓你知道有多少包在傳輸過(guò)程中丟失了。對(duì)于發(fā)送端來(lái)說(shuō)，丟包來(lái)自RTCP，對(duì)于接收端來(lái)說(shuō)，丟包是在本地測(cè)量的。當(dāng)你在檢查一個(gè)質(zhì)量不好的通話時(shí)，這個(gè)參數(shù)可能是你想要查看的最直接的數(shù)據(jù)。

音頻特性

對(duì)于音軌來(lái)說(shuō)，我們有audioInputLevel和audioOutputLevel（在規(guī)范中叫做audioLevel）可以告訴我們音頻信號(hào)是來(lái)與麥克風(fēng)，還是通過(guò)揚(yáng)聲器播出的。這個(gè)特性可以用來(lái)探測(cè)Chrome里不受歡迎的音頻bug。我們還可以通過(guò)googJitterReceived和googJitterBufferReceived得知有多少抖動(dòng)被接收，以及jitter buffer的狀態(tài)。

視頻特性

對(duì)于視頻軌道來(lái)說(shuō)，我們有兩大信息需要關(guān)注。第一個(gè)是被送入googNacksSent，googPLIsSent和googFirsSent中，NACK，PLI和FIR數(shù)據(jù)包的數(shù)量差別。這可以讓我們知道丟包會(huì)如何影響視頻質(zhì)量。

更重要的是，我們得知了框架大小和速率是作為輸入（googFrameWidthInput，googFrameHeightInput，googFrameRateInput）并且實(shí)時(shí)上是發(fā)送到網(wǎng)絡(luò)之上（googFrameWidthSent，googFrameHeightSent，googFrameRateSent）。

相似的數(shù)據(jù)可以在接收端被收集到存在googFrameWidthReceived，googFrameHeightReceived中。對(duì)于框架速率來(lái)說(shuō)我們甚至可以將其從googFrameRateReceived，googFrameRateDecoded和GOOGFrameRateOutput中分開(kāi)來(lái)。

在編碼端我們可以看到這些值之間的差別，還能知道為什么圖片會(huì)被縮小。通常這些事情發(fā)生不是因?yàn)闆](méi)有足夠大的CPU，就是沒(méi)有足夠大的帶寬來(lái)傳送完整的圖片。另外，想要降低框架速率（其可以從對(duì)比googFrameRateInput和googFrameRateSent之間的差距得到），我們需要得到額外的信息：分辨率是否因?yàn)镃PU的問(wèn)題而得到適應(yīng)，以及是否是因?yàn)閹挷粔蚴沟胓oogBandwidthLimitedResolution的值是真。無(wú)論是上述哪個(gè)情況發(fā)生了改變，googAdaptionChanges計(jì)數(shù)器都會(huì)增加。

我們可以從這張圖表上看到這些變化：

這里的丟包是人為產(chǎn)生的。作為反應(yīng)，Chrome在t=184時(shí)第一次嘗試降低分辨率，這是綠線代表的googFrameWidthSent開(kāi)始偏離黑線代表的googFrameWidthInput。接下來(lái)在t=186時(shí)，框架開(kāi)始下降，輸入框架速率（淺藍(lán)色線條所示）大約是30fps，與發(fā)出的框架速率（藍(lán)色線條所示）產(chǎn)生區(qū)別，后者幾乎是0.

另外，Chrome在ssrc報(bào)告中公開(kāi)了大量關(guān)于音頻和視頻堆棧的表現(xiàn)的數(shù)據(jù)。我們會(huì)在未來(lái)的博文中進(jìn)行討論。

VideoBWE報(bào)告

最后，但并不是不重要，我們來(lái)分析一下VideoBWE報(bào)告。就像它名字所表達(dá)的，它包括有關(guān)帶寬估計(jì)的信息。但是還有一些其他的有用信息包含在這個(gè)報(bào)告里：

• googAvailableReceiveBandwidth—對(duì)于接收視頻數(shù)據(jù)可用的帶寬。

• googAvailableSendBandwidth—對(duì)于發(fā)送視頻數(shù)據(jù)可用的帶寬。

• googTargetEncBitrate—視頻編碼器的目標(biāo)比特率。這項(xiàng)指標(biāo)會(huì)嘗試填滿(mǎn)可用的帶寬。

• googActualEncBitrate—視頻編碼器輸出的比特率。通常這與目標(biāo)比特率是匹配的。

• googTansmitBitrate—這個(gè)比特率是實(shí)際傳輸?shù)谋忍芈?。如果此?shù)值與實(shí)際編碼比特率有較大的差別，那么可能是因?yàn)榍跋蝈e(cuò)誤糾正造成的。

• googRetransmitBitrate—如果RTX被使用的話，這項(xiàng)允許測(cè)量重傳的比特率。此數(shù)據(jù)通常代表丟包率。

• googBucketDelay—是Google為了處理大框架速率的策略表示。通常是很小的數(shù)值。

正如你看到的，這個(gè)報(bào)告會(huì)給你視頻質(zhì)量最重要的信息—可用帶寬。查看發(fā)送和接收的可用帶寬通常都是在深入分析ssrc報(bào)告之前做的最重要的事。因?yàn)橛袝r(shí)你可能會(huì)發(fā)現(xiàn)這樣的情況，這解釋了用戶(hù)所抱怨的“質(zhì)量差”：
 

在這種情況下，“在所有時(shí)間里，帶寬估計(jì)都在下降”是對(duì)質(zhì)量問(wèn)題的一個(gè)比較好的解釋。

看完了這篇文章，相信你對(duì)“WebRTC內(nèi)置debug工具怎么用”有了一定的了解，如果想了解更多相關(guān)知識(shí)，歡迎關(guān)注億速云行業(yè)資訊頻道，感謝各位的閱讀！