Shulou(Shulou.com)06/01 Report--

Editor to share with you how to use the built-in debug tool in WebRTC. I hope you will get something after reading this article. Let's discuss it together.

Webrtc-internals is a great tool when you want to find problems with your WebRTC products, because you need to use it to test WebRTC and debug, or you need to fine-tune your configuration.

How do I get the data dump (stats dump) of webrtc-internals?

If you are not familiar with the tool, open the WebRTC section in your Chrome browser, open another form in this section and point it to the internal URL:chrome://webrtc-internals/

Webrtc-internals allows you to download the track as a large JSON so you can look at it layer by layer, but when you do, you'll see something like this:

View webrtc-internals data

The first thing people usually ask is-what exactly do these numbers represent? One of our own testers put these values into a timing chart and output them. This gives us a chart that is much larger than the 300x140image taken directly from webrtc-internals.

In the GetUserMedia request form, we can see each getUserMedia call, as well as related constraints. Unfortunately, we can't see the result or the ids in MediaStreams.

RTCPeerConnection data

For each peerconnection, we can see these four points here:

The following is a queue of RTCStatsReport objects with many keys and values that can be read like this:

Keep in mind that there are some differences between these statistics and specifications. There is a rule of thumb that any key whose name ends with "Id" contains a different report whose id property corresponds to the value of the key. So all these reports are linked to each other. Also note that these values are character-based, although they look like numbers like Boolean values.

The most important attribute in RTCStatsReport is the type of report, here are a few of them:

GoogTrack

GoogLibjingleSession

GoogCertificate

GoogComponent

GoogCandidatePare

LocalCandidate

RemoteCandidate

Ssrc

VideoBWE

Let's take a closer look at these types of reports.

GoogTrack and googLibjingleSession reports

GoogTrack and googLibjingleSession don't contain much information, so we skip it and don't analyze it.

GoogCertificate report

The googCertificate report includes some information about the DTLS certificates used by the near-end and peer, as well as fingerprinting and hashing algorithms. All these are described in detail in the RTCCertificateStats dictionary.

GoogComponent report

GoogComponent reports act like glue between authentication data and connections. It contains a pointer to the currently active candidate pair in the carton, as well as encrypted sockets related to DTLS and SRTP encryption.

GoogCandidatePair report

GoogCandidatePair describes a pair of ICE candidates, that is, low-level connections. From this report, you can get this information:

Packets sent and received, as well as the total number of bytes (packetsReceived that bytesSent,bytesReceived,packetsSent; lost for an unknown reason). This is a UDP or TCP byte that contains a RTP header.

How to determine whether this is an active connection? if the value of googActiveConnection is true, it is active, otherwise it is false. Most of the time you will only be interested in active candidates. Equivalent specifications can be found here.

The number of STUN requests and replies sent and received is the number of STUN requests that are input and output in the ICE process.

GoogRtt is the round trip time for the latest STUN requests. This is different from the googRtt in the ssrc report, which we will talk about later.

LocalCandidateId and remoteCandidateId point to localCandidate and remoteCandidate. LocalCandidate and remoteCandidate describe local and remote ICE candidates. You can find most of the information on the googLocalAddresses type.

The values of googTr and googLocalCandidateType.

GoogTransportType specifies the type of transmission. Note that the value of this data is usually "udp", even if the TURN on TCP is used to connect to the TURN server. This value is "tcp" only if ICE-TCP is used.

Some data, such as the number of bytes sent and received, can be seen more intuitively from the following figure:

LocalCandidate and remoteCandidate reports

Thank God localCandidate and remoteCandidate are exactly the same as described in the specification, telling us the ip address, port number, and type of candidate. For the TURN candidate, it will tell us which port the candidate is assigned to.

Ssrc report

The ssrc report is one of the most important reports here. There is a ssrc report for each audio or video track to send or receive. In the old version of the specification, these were called MediaStreamTrackStats and RTPStreamStats. Its content depends on whether it is an audio or video track, and whether it is sent or received. Let's first describe some of the basic elements:

MediaType says we are looking at audio data or video data.

The ssrc property specifies whether the media sends ssrc or receives

GoogTrackId recognizes the tracks described by the data. This id can be found in SDP, as well as in local or remote media streaming tracks. In fact, this violates the naming convention with the suffix "Id". What usually ends with "Id" is a pointer to other reports. Google got goog stats wrong.

GoogRtt represents the round trip time. Unlike the round-trip time mentioned earlier, this round-trip time is measured from RTCP.

TransportId, which points to the part that is used to transmit the RTP stream. The transportId usually used for audio and video streams is the same.

GoogCodecName specifies the name of the codec. A typical audio codec is opus, and for video, use VP8,VP9 or H264. You can also see information about the implementations used in codecImplementationName statistics.

The values of bytesSent,bytesReceived,packetsSent and packetsReceived allow you to calculate the total number of bytes. These numbers are cumulative, so you need to separate them by time after you ask getStats for the last time. The sample code in the rule is well written, but just note that Chrome will reset these counters, so you may get a negative rate.

PacketsLost lets you know how many packets are lost in transit. For the sender, the packet loss comes from RTCP, and for the receiver, the packet loss is measured locally. When you are checking a call of poor quality, this parameter is probably the most direct data you want to view.

Audio characteristics

For audio tracks, we have audioInputLevel and audioOutputLevel (called audioLevel in the specification) that tell us whether the audio signal is broadcast with the microphone or through the loudspeaker. This feature can be used to detect unpopular audio bug in Chrome. We can also know from googJitterReceived and googJitterBufferReceived how much jitter has been received, as well as the status of the jitter buffer.

Video characteristic

For video tracks, we have two big messages to pay attention to. The first is the difference in the number of packets sent into googNacksSent,googPLIsSent and googFirsSent, NACK,PLI and FIR. This will let us know how packet loss will affect video quality.

More importantly, we learned that the frame size and speed are used as input (googFrameWidthInput,googFrameHeightInput,googFrameRateInput) and sent to the network in real time (googFrameWidthSent,googFrameHeightSent,googFrameRateSent).

Similar data can be collected and stored in the googFrameWidthReceived,googFrameHeightReceived at the receiving end. For frame speed, we can even separate it from googFrameRateReceived,googFrameRateDecoded and GOOGFrameRateOutput.

We can see the difference between these values on the coding side, and we can also know why the picture has been shrunk. Usually these things happen either because there is not enough CPU or there is not enough bandwidth to transmit the complete picture. In addition, to reduce the frame rate (which can be obtained by comparing the gap between googFrameRateInput and googFrameRateSent), we need additional information: whether the resolution is adapted because of the problem of CPU, and whether the value of googBandwidthLimitedResolution is true because of insufficient bandwidth. No matter which of the above changes, the googAdaptionChanges counter will increase.

We can see these changes from this chart:

The packet loss here is man-made. In response, Chrome first tried to reduce the resolution at tweak 184, when the googFrameWidthSent represented by the green line began to deviate from the googFrameWidthInput represented by the black line. Then at tweak 186, the frame begins to decline, and the input frame rate (shown in the light blue line) is about 30fps, which is different from the emitted frame rate (shown in the blue line), which is almost 0. 5%.

In addition, Chrome exposes a lot of data on the performance of audio and video stacks in the ssrc report. We will discuss it in future blog posts.

VideoBWE report

Last but not least, let's analyze the VideoBWE report. As its name suggests, it includes information about bandwidth estimates. But there are other useful information included in this report:

The bandwidth available to googAvailableReceiveBandwidth- for receiving video data.

The bandwidth available to googAvailableSendBandwidth- for sending video data.

The target bit rate of the googTargetEncBitrate- video encoder. This metric attempts to fill up the available bandwidth.

The bit rate output by the googActualEncBitrate- video encoder. Usually this matches the target bit rate.

GoogTansmitBitrate- this bit rate is the actual transmission bit rate. If this value is quite different from the actual coding bit rate, it may be caused by forward error correction.

GoogRetransmitBitrate- this allows you to measure the bit rate of retransmission if RTX is used. This data usually represents the packet loss rate.

GoogBucketDelay- is the policy representation of Google to deal with large frame rates. It's usually a very small number.

As you can see, this report will give you the most important information about video quality-available bandwidth. Looking at the available bandwidth sent and received is usually the most important thing to do before delving into the ssrc report. Because sometimes you may find this, which explains the "poor quality" that users complain about:

In this case, "bandwidth estimates are declining all the time" is a good explanation for the quality problem.

After reading this article, I believe you have a certain understanding of "how to use WebRTC built-in debug tools". If you want to know more about it, you are welcome to follow the industry information channel. Thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.