Reduce stream latency below 1 second

[MajorNr01]

I don't know if this is the right place to ask this question but I could not find help anywhere else. If this question doesn't belong here, feel free to close it

PROBLEM

When I started evaluating OvenMediaEngine I ran the docker command from the GitHub Readme and got a stream latency well below 1 second out of the box. Latency was small enough that I could control my mouse while looking at the stream, so I would estimate that it was around 200ms.

After tinkering for a couple of days I noticed my streams now have a consistent latency of ~1 second and I have thus far been unable to reproduce this extremely low latency.

EXPECTATION

I would like to know if OvenMediaEngine can be configured such that the stream latency is consistently significantly less than 1 second.

If anyone knows about changes to my OBS or OvenPlayer setup that would achive this I would also greatly appreciate it.

ENVIRONMENTAL INFORMATION

I am running OvenMediaEngine on a VPS and stream to it using OBS and RTMP. I watch the stream using the demo player.

• OvenMediaEngine Information

I am using release 0.14.9

• Encoder information

I am using OBS version 28.0.3. My Output settings are:

Encoder: NVIDIA NVENC H.264 Rescale Output: No

Rate Control: CBR Bitrate: 8000 Kbps Keyframe Interval: 0 Preset: Low-Latency Performance Profile: main Look-ahead: No Psycho Visual Tuning: Yes GPU: 0 Max B-frames: 0

• Player information

I am using the demo player at http://demo.ovenplayer.com

• URL

I stream to "rtmp://VPS-IP/app" with stream key "stream" I watch at "ws://VPS-IP:3333/app/stream"

• Operating system and version

Ubuntu 20.04

[getroot]

It's a great issue that fills out the form.

WebRTC players (Chrome, Safari, etc.) have a dynamic jitter buffer that cannot be controlled externally. They control the buffers to ensure playback is sufficiently low-latency, but they also care a lot about A/V sync and smooth playback. What this means is that the jitter buffer can be smaller if the best network conditions (very little jitter and high speed) and A/V are consistently and accurately reached. But it also means that we don't have full control over the player's buffer. For testing, try using video only first. And I recommend setting the keyframe interval to 1 second.

The delay on the server (especially if you don't have encoding settings) adds almost 2-3 frames of delay.

[MajorNr01]

It's a great issue that fills out the form.

WebRTC players (Chrome, Safari, etc.) have a dynamic jitter buffer that cannot be controlled externally. They control the buffers to ensure playback is sufficiently low-latency, but they also care a lot about A/V sync and smooth playback. What this means is that the jitter buffer can be smaller if the best network conditions (very little jitter and high speed) and A/V are consistently and accurately reached. But it also means that we don't have full control over the player's buffer. For testing, try using video only first. And I recommend setting the keyframe interval to 1 second.

The delay on the server (especially if you don't have encoding settings) adds almost 2-3 frames of delay.

That is already very insightful, thank you!

I will try some of the options you suggested.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[radar155]

I am experiencing about 1 second delay with WebRTC too, while a couple of months ago delay was below 500ms.

I'm using OME 15.10 in docker, with default OME config file (so video encoding is disabled).

I'm pushing the stream to OME with OBS (29.0.2). Streaming settings: Encoder: x264 Rate Control: CBR Bitrate: 2500kbps Keyframe: 1s (I tested with 2s aswell) Cpu Usage preset: ultrafast Profile: Baseline Tune: zerolatency. Moreover, in obs "Video" tab, output resolution is 1920x1080, 30fps.

Everything is running on the same machine, win 10, 32gbRAM, 8core i7, Docker desktop 4.17. I'm using the Oven Player in chrome.

So, I'm using localhost to push the RTMP stream and to consume it with Chrome. Ping and jitter are below 0ms.

I tried to disable audio as suggested for testing purpose (even if I'm interested in audio too), without luck, latency is always about 1s, maybe a little more.

About disabling audio: I tried disabling all obs audio sources from the "Audio" tab in obs settings. Is this the right way to do it?

[getroot]

@radar155 OBS cannot disable audio tracks. You can test with video only by removing audio from the output stream in OME or removing audio from the playlist.

And if you think the latest version has higher latency, can you confirm which version in the past has lower latency for you?

[radar155]

In the past I used version 14.15 with a better latency.

I will test soon version 14.15 again, and I will also test removing audio directly from OME.

[radar155]

I did a couple of tests: I did another try with OME 15.10, started the obs streaming, consuming it with chrome and latest version of OvenPlayer: latency above 1 second.

Changed OME to 14.15, same conditions, latency below 0.5 seconds. Then I tried again with OME 15.10 and latency this time was surprisingly 0.5 seconds or below.

There is some factor I can not figure out, probably related to OBS or OvenPlayer. All tests were made with conditions described above, with audio enabled and with the latest version of OvenPlayer.

Do you have any idea? Do you want me to do some other tests?

[getroot]

@radar155 Latencies between 0 and 1 second are most likely an effect of the browser's (player's) dynamic jitterbuffer. This jitterbuffer cannot be controlled from OvenPlayer or any other level. However, this jitter buffer becomes larger when the network jitter is high or the A/V sync is out of sync, so the following configuration can help lower the latency.

1. If you transmit AVC/Opus using WHIP in OBS and bypass both A/V, the jitter buffer of the browser can be reduced because the A/V sync is very well matched. (If you encode in OME, there may be a gap due to the difference in performance of the A/V codec.)

2. Eliminating audio eliminates the need for A/V sync, making the jitter buffer smaller.

3. If the network speed is very fast, the jitter buffer will be small.