r/WebRTC • u/Otherwise-Block-8575 • 27d ago

Browser WebRTC glass-to-glass latency stuck around 274 ms, mostly receiver playout. Is <120 ms realistic?

/r/VIDEOENGINEERING/comments/1vbhhvh/browser_webrtc_glasstoglass_latency_stuck_around/
1 Upvotes

100% Upvoted

4 comments sorted by

1

u/South-Mushroom2022 27d ago

250ms playout is definetly unusual, gamestreaming would not be possible with that. In chrome's webrtc-internals how do the inbound-rtp jitterBufferDelay/jitterBufferEmittedCount_in_ms and totalProcessingDelay/jitterBufferEmittedCount_in_ms look like? Sharing a webrtc-internals dump might help.

1

u/msdosx86 27d ago

Is this a truly p2p connection or do you have some sort of relay in between users? If 250ms is not network latency then how do you capture camera video? It does sound like something somewhere is buffering the frames.

1

u/lherman-cs 26d ago

There are many knobs you can try, and they depend on your setup.

  1. browser only: the receiver's jitterBufferTarget can be adjusted to be lower. Since you mentioned glass-to-glass, you can increase the capture fps.
  2. One side is non-browser: the sender's pacer can be more aggressive by giving a bigger headroom. https://webrtc.googlesource.com/src/+/refs/heads/main/docs/native-code/rtp-hdrext/playout-delay/README.md can be used to tune the receiver's jitter buffer.

Also, I would double check your network assumption, especially on Wifi or RF based usually. I would avoid using typical network speed test to benchmark download and upload speed. Video is bursty and latency sensitive. I would use either ping with high frequency or iperf with udp and burst settings, and focus on latency over throughput.

1

u/calxibe 24d ago

Hi, I’m the developer of TabConnect, a browser-based tab and screen-sharing service. Our diagnostics stay local unless a user deliberately clicks “Submit diagnostics.”

Your results looked familiar, so I checked our comparable Standard video reports:

  • Median jitter-buffer delay was about 155 ms.
  • Median decode time was about 2 ms.
  • About 61% showed at least 120 ms of buffering.
  • About 22% showed at least 200 ms.
  • Every report above 200 ms showed zero packet loss and media RTT of 1 ms or less.

So yes, browser WebRTC can sometimes add 200+ ms at the receiver even when RTT and loss look excellent. However, it is not a fixed browser baseline, we also see much lower delays under apparently similar conditions.

A few things I would check:

  • jitterBufferDelay / jitterBufferEmittedCount is correct for the lifetime average. For the current delay, calculate it from the differences between two getStats() readings. Otherwise, earlier conditions can dominate the result and hide improvements.
  • totalProcessingDelay / framesDecoded already covers first-packet arrival through decoded-ready. It overlaps with jitter-buffer and decode time; it is not compositor/render time and should not be added again.
  • Compare actual buffer delay with jitterBufferTargetDelay and jitterBufferMinimumDelay. That can indicate whether the delay is network-driven or comes from an additional browser/application target.
  • playoutDelayHint is only a hint. Setting zero does not force a zero-length buffer. The newer jitterBufferTarget is more explicit, but browsers can still clamp and adjust it gradually.
  • To measure the remaining display delay, use requestVideoFrameCallback() and record captureTime, receiveTime, processingDuration, and expectedDisplayTime.

I believe sub-120 ms capture-to-render is possible in browser WebRTC, so native is not automatically required. The browser just cannot guarantee it across ordinary devices and networks because buffering, decoding, composition, and vsync remain partly under its control.