Debugging a WebRTC connection in Chrome can involve checking various aspects. Here's a breakdown of how you can approach it:

Chrome WebRTC internals:

  • Open Chrome and navigate to: chrome://webrtc-internals.
  • This page displays real-time information about active WebRTC connections in your browser.


  • Look for sections like:
    • ICE Servers: Shows the STUN/TURN servers used for connection attempts.
    • ICE Candidates/ICE candidate grid: Lists the candidate IP addresses and ports discovered for your connection.
    • Connection States: Displays the current state of the WebRTC connection (connecting, completed, failed)
  • Analyze the information to identify potential issues like missing candidates, failed connections, or errors in the connection process.
  • Transport: This section shows the transport protocol used for the connection (typically UDP).
  • Video Codec: This displays the video codec being used for the video stream and should be set to H.264.
  • Look for section inbound-rtp to validate:
    • Bitrate: This value indicates the current bitrate of the video stream, which reflects the amount of data being transmitted per second. Higher bitrates usually translate to better video quality, but also require more bandwidth.
    • Round Trip Time (RTT): This metric shows the time it takes for a data packet to travel from your device to the other peer and back. Lower RTT indicates better responsiveness and less lag.
    • Packets Lost: This displays the percentage of data packets that are lost during transmission. Higher packet loss can lead to choppy video or dropped frames.
    • Frames Dropped: This metric shows the number of video frames that are dropped due to network issues or processing limitations. Excessive frame drops can cause stuttering or jerky video.
    • FrameWidth/FrameHeight: Those values show actual resolution of video stream decoded in the browser, use it to validate if it corresponds to camera settings.
    • nackCount*: Negative Acknowledgement Count refers to the number of times a receiver has sent a NACK (Negative Acknowledgement) packet to the sender.
    • pliCount*: Picture Loss Indication Count refers to the number of times a receiver has sent a PLI (Picture Loss Indication) packet to the sender
    • firCount*: Full Intra Request Count refers to the number of times a receiver has sent a FIR (Full Intra Request) packet to the sender

Glossary

Negative Acknowledgement (NACK):

NACK is a specific type of packet used in WebRTC to inform the sender that one or more RTP (Real-time Transport Protocol) packets containing media data (like video or audio) were lost during transmission.

Impact of Nack Count:

  • Data Loss: A high nack count signifies that a significant number of data packets haven't reached the receiver. This can lead to:

    • Choppy Video/Audio: Missing data packets can result in gaps or glitches in the received video or audio stream.

    • Reduced Quality: With more data loss, the overall quality of the video or audio can deteriorate.

  • Network Issues: NACKs are a symptom of network problems that cause data loss. A high nack count might indicate:

    • Packet Loss: Packets can be lost due to network congestion, unreliable connections, or high latency.

    • Firewall Issues: Restrictive firewalls might block or interfere with data packets.

    • NAT Challenges: Complex Network Address Translation (NAT) configurations can sometimes hinder data transmission.

Picture Loss Indication (PLI):

  • A PLI is a control packet used in WebRTC to notify the sender that an undefined amount of encoded video data, potentially spanning multiple frames, has been lost during transmission.

  • Unlike NACKs (Negative Acknowledgements) that pinpoint specific missing packets, PLIs provide a more general notification about video data loss.

  • pliCount indicates how many times the receiver has needed to send a PLI to the sender. A higher pliCount suggests more significant video data loss has occurred.

Impact of pliCount:

  • Video Quality Degradation: A high pliCount suggests that the receiver is frequently missing video data. This can lead to:

    • Choppy Video: Missing video frames can result in jerky or incomplete video playback.

    • Reduced Detail: With significant data loss, the overall video quality can suffer, appearing blocky or pixelated.

  • Network Issues: Similar to NACKs, PLIs are a symptom of network problems that cause data loss. A high pliCount might indicate:

    • Packet Loss: Video data packets can be dropped due to network congestion, unreliable connections, or high latency.

    • Bandwidth Limitations: If the available bandwidth is insufficient for the video bitrate, data loss becomes more likely.

Full Intra Request (FIR):

  • A FIR is a control packet used in WebRTC by the receiver to request the sender to transmit a full Intra frame (I-frame) for a specific video stream.

  • I-frames: These frames contain complete, independent pictures, unlike P-frames (predictive frames) that rely on previously received frames for encoding.

  • Purpose of FIR: When the receiver encounters significant errors or lost data packets, it might fall behind in decoding the video stream. Sending a FIR forces the sender to transmit a full I-frame, allowing the receiver to resynchronize and start decoding from a known reference point.

  • firCount: indicates how many times the receiver has needed to request a full I-frame by sending a FIR packet. A higher firCount suggests the receiver has encountered difficulties keeping up with the video stream.

Impact of firCount:

  • Video Stuttering: Frequent FIR requests can indicate the receiver is struggling to decode the video due to missing data. This can lead to stuttering or choppy playback.

  • Increased Bandwidth Usage: Sending full I-frames requires more bandwidth compared to P-frames or B-frames. A high firCount might contribute to higher overall bandwidth consumption.

Importance of firCount:

  • Monitoring: firCount is a valuable metric for monitoring the health of a WebRTC video connection. An increasing firCount can be an early warning sign of potential video quality issues.

  • Troubleshooting: By observing firCount along with other metrics like bitrate, round-trip time, nack count, and pliCount, you can diagnose the root cause of video decoding problems and take corrective actions.

Limitations of firCount:

  • Indirect Indicator: A high firCount can be caused by various factors like data loss (reflected in nack count), decoder limitations, or even low processing power on the receiver's device. Analyzing other metrics alongside firCount is crucial for pinpointing the exact issue.

  • Receiver-Side Metric: Similar to NACKs and PLIs, firCount is only available on the receiver side. The sender doesn't directly see how many FIR requests were sent.

In conclusion, firCount is a useful metric for understanding video decoding challenges in a WebRTC video stream. By monitoring and interpreting firCount in conjunction with other factors, you can identify potential issues and optimize your WebRTC experience for smoother video playback.



© Honeywell International Inc. All Rights Reserved.