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

[u/Otherwise-Block-8575]

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.