WebRTC publisher JitterBuffer has been redesigned for smoother playback

[getroot]

The WebRTC publisher's JitterBuffer has been redesigned. The new implementation reshapes bursty frame delivery into evenly spaced output, so any timing variance from upstream is absorbed before it reaches the player.

You can test it on the latest master branch.

When you'll see a difference

If your encoder produces frames at a perfectly even cadence and the network has minimal jitter, the difference is small or invisible. The redesign matters in real-world conditions where any of these applies:

• Source delivery is bursty (encoder warmup, GOP boundaries with large IDRs, ingest pacing variations).
• Network introduces variable delay or occasional spikes.
• The viewer is on a player with a small playout buffer (browsers, OvenPlayer in low-latency mode, custom WebRTC clients) where upstream jitter would otherwise cause stutter.

In those environments, playback runs at a more consistent speed.

How to enable

Add <JitterBuffer>true</JitterBuffer> under your WebRTC publisher configuration:

<!-- /Server/VirtualHosts/VirtualHost/Applications/Application -->
<Publishers>
    <WebRTC>
        <Timeout>30000</Timeout>
        <BandwidthEstimation>TransportCC</BandwidthEstimation>
        <Rtx>false</Rtx>
        <Ulpfec>false</Ulpfec>
        <JitterBuffer>true</JitterBuffer>
    </WebRTC>
</Publishers>

It is off by default. The setting is per application, so you can turn it on only for the apps where you want the smoothing behavior.

If you already have <JitterBuffer>true</JitterBuffer> from a previous OME version, no config change is needed. Your stream automatically gets the new behavior on master.

What about latency?

The JitterBuffer holds each frame briefly to align its output time, so a small amount of latency is added. In a healthy environment where upstream jitter is already low, the added latency is small enough to be unnoticeable. The buffer only grows when the source is genuinely bursty, and shrinks back as soon as conditions calm down. There are no per-environment knobs to set; the buffer adapts automatically.

Manual

https://docs.ovenmediaengine.com/dev/streaming/webrtc-publishing#publisher

[naanlizard]

What is the performance difference, for the server? Will it use much more CPU with the jitterbuffer enabled?

[getroot]

An additional thread runs per stream, but I do not expect high resource usage. I would appreciate it if you could test this in your environment and let me know.

[naanlizard]

More questions, as I consider deploying this -

1. What is the interaction between this redesign and cluster mode? We run separate origin + edge instances on all hosts, and have 3 production hosts. Can we update only one host, and compare it to the others? Or does every edge (and origin?) need to be updated? Or only the origin the user with the poor encoding/network sends their stream to?

2. Memory usage, small increase expected I assume? Can we estimate whether it is kilo, mega, or gigabytes of additional memory usage?

3. This feature is currently not in a release yet, correct? What else has changed on master, and how well has it been tested? I can read the commits, but sometimes they're a bit opaque to me