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/