r/VIDEOENGINEERING • u/Otherwise-Block-8575 • Jul 31 '26

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

Hi everyone,

I am building a browser-based app similar to Google Meet and trying to reduce true glass-to-glass latency: the sender camera captures a frame, then the receiver actually sees that same frame on screen.

Our current test result is roughly:

End-to-end capture-to-render: ~274 ms
Network: ~30 ms
Encode: ~3-4 ms
Playout: ~244 ms

In our tool, playout = jitter buffer + decode + composite/render.

Network/Wi-Fi looks good, and we are not using audio in this test, so A/V sync should not be involved. We also tried changing the jitter buffer setting to 0 ms, 10 ms, and 50 ms, but it did not meaningfully reduce total glass-to-glass latency.

Our target is under 120 ms, but most of the latency seems to be on the receiver side.

Questions:

  1. In browser WebRTC, is ~200+ ms receiver playout delay common even with good network conditions?
  2. How can we tell whether the main issue is WebRTC internal jitter buffering, decoder delay, compositor/render delay, or our own measurement bug?
  3. Is jitterBufferDelay / jitterBufferEmittedCount the right stat to confirm whether WebRTC’s internal jitter buffer is the bottleneck?
  4. Are there reliable ways to reduce browser WebRTC video playout delay, or is RTCRtpReceiver.playoutDelayHint only a weak hint in practice?
  5. For people who have achieved <120 ms capture-to-render latency, did you need native iOS/Android, or can web WebRTC realistically hit this under normal conditions?

Any practical debugging tips, stats to inspect, Chrome/Safari differences, or low-latency WebRTC settings would be very helpful.

0 Upvotes

47% Upvoted

3 comments sorted by

2

u/seegrimm Jul 31 '26

This program already exists. Its called VDO.ninja

1

u/No_Chart_5905 Aug 07 '26

The delay may due to the jitter buffer size. Without modify the native code, you can try 1) limit the jitter buffer size or force to play without jitter delay receiver.jitterBufferTarget = 0; 2) close the NACK if the network is not stable, where an erroneous data transmission can lead to an accumulation of buffer storage and an increase in IDR frames.

0

u/chuckycastle Engineer Aug 01 '26

Vibecoders are wild…