139
edits
Media/WebRTC/WebRTC Debugging: Difference between revisions
Added debugging delay
(Adding some mochitest info an try fuzzy query info) |
(Added debugging delay) |
||
| Line 11: | Line 11: | ||
# Add this file as an attachment to your bug.<br /> | # Add this file as an attachment to your bug.<br /> | ||
This file contains statistics about your call, the signalling that was used to setup your call, and information about the network transports. | This file contains statistics about your call, the signalling that was used to setup your call, and information about the network transports. | ||
===Common Call Quality Issues=== | |||
====Audio/Video Delay==== | |||
Delayed media is commonly caused by long physical paths between endpoints, though anything that slows down inter-hop delivery of packets can be at fault. Note that this is different than the bandwidth of the network path, and a high latency can not be remedied by stream decimation. Round trip time, or RTT, is the time it takes for a packet to get from the sender to the receiver and then for a packet to get from the receiver back to the sender. If the path is symmetric between the two endpoints one can assume that the one way delay is half the delay of the round trip. | |||
The second common cause of A/V delay is jitter, the magnitude of variability in packet inter-arrival times. In order to smoothly play out of the incoming stream a receiver experiencing jitter will have to buffer (delay) incoming packets. | |||
'''Using [about:webrtc] to Diagnose Delay''' | |||
The key metrics in [about:webrtc] are RTT (round-trip-time) and jitter. They can be found in the RTP stats section of the PeerConnection. | |||
[[File:About webrtc Jitter and RTT.png|800px|border|Location in about:webrtc of jitter and RTT stats]] | |||
In this image we can see that there are 0 milliseconds of jitter, and 32 milliseconds of round trip delay. This call should not be experiencing any noticeable delay. | |||
==Logging== | ==Logging== | ||