(SRT ingest + SRT output) + SRT source = high latency ?

[dvision1979]

Hello once again,

I gave a try to the SRT ingest, activated the SRT output on the channel, then I selected the SRT source on one of the publication process. I got a (high) 14s delay on Youtube. The source was a ffmpeg desktop capture on linux ubuntu. I got slightly the same disappointing results using the OBS as a stream pusher.
As I read around on the internet, SRT is a low latency protocol, so, what happens in Restreamer 2?
Thank you for any suggestions.

[EDIT]
It worths mentioning that using a rtmp chain resulted in better results 6-7 secs to youtube.

[jstabenow]

1. Stream settings > Processing & Control > Enable SRT

2. Publication service > YouTube > General > Use rtmp mode

3. .. > Source & Encoding > Switch to SRT source

[dvision1979]

[dvision1979]

Ingesting RTMP:

[jstabenow]

Interesting. I'll check it out in the coming days.

[dvision1979]

Interesting. I'll check it out in the coming days.

Thank you, much appreciated.

[FilipStadler]

Before restreamer was able to do SRT I used another solution and latency was only 3-6 seconds delay from the mobile device with ffmpeg to OBS and then I added a SRT server it would give 3 seconds more delay but I did not try playout/writeout for a HLS stream but I must say srt its slower on the restreamer - in somecases making the output for HLS/player overheard may not be needed really when doing maybe srt to srt push/pull I dont know what makes the delay. Its nice to be able to see what it tries to stream but in my old setup I just push the stream to the SRT-server and pulled it to restream out. This added 3 secounds delay to the server and 3 seconds from the server - with restreamer its alot more delay. Is it possible to turn off the HLS playout feature ? maybe a stupid question.

[jstabenow]

Before restreamer was able to do SRT I used another solution and latency was only 3-6 seconds delay from the mobile device with ffmpeg to OBS and then I added a SRT server it would give 3 seconds more delay but I did not try playout/writeout for a HLS stream but I must say srt its slower on the restreamer - in somecases making the output for HLS/player overheard may not be needed really when doing maybe srt to srt push/pull I dont know what makes the delay. Its nice to be able to see what it tries to stream but in my old setup I just push the stream to the SRT-server and pulled it to restream out. This added 3 secounds delay to the server and 3 seconds from the server - with restreamer its alot more delay. Is it possible to turn off the HLS playout feature ? maybe a stupid question.

HLS playback should have nothing to do with SRT latency. As you can see in my picture, I have no latency (<1 sec.) when I encode a test picture on the Restreamer, provide it as HLS+SRT, and send it to YouTube-Live via RTMP.
So it must have something to do with the “external” access. On the other hand, maybe the Docker virtualization is to blame. I will check this out.

[geepot]

I'd like to add to this. It looks like it might actually be going through some extra processing before it goes to SRT out. Not sure of how else to verify this but I'll present what I'm seeing. All of this is done on a fresh install of restreamer in docker and all configuration has been done through the UI.

I have my setup configured like so:

I have grabbed the SRT feed link from here and connected to the stream in VLC:

In OBS I have a millisecond timer video going to show the latency. I have tried everything I can think of at this point configuration-wise and I can't get rid of this 4 second delay in the SRT stream. This also happens with RTMP: SRT (image1) or RTMP (image2). In my tests, both VLC and streaming to VRCDN with RTMP publication and RTMP selected as the source had the same 4 second delay. Selecting SRT as the source for the RTMP publication resulted in an 8 second delay (not shown here).

When checking the process details on the restreamer channel, it seems that mpegts (SRT) is being written to memfs rather than being passed through directly. Please correct me if this is the expected behavior.

This is everything together (player, OBS, and VLC).

Attached is my process report and an anonymized copy of the generated db.json.

report (1).txt
db.json (1).txt

[ioppermann]

If you send a stream with OBS using SRT to Restreamer and you use it as a source and want to publish it again to SRT, it will not be published again to the SRT server because it's already there. What you are pulling with VLC from Restreamer SRT is directly the stream you publish with OBS.

In VLC try to reduce the size of the buffer:

The player in Restreamer uses HLS which has a delay of a few seconds. If you pull the stream directly via SRT you should only see a delay of a few milliseconds.

If you use ffplay you can reduce the input buffer with ffplay -fflags nobuffer -flags low_delay srt://....

It might also be that OBS adds an encoding delay, but I didn't test that. What you see in OBS are the frames before they get encoded.

[geepot]

Thanks for the sanity check. I’ll check my settings and look into the OBS side more and report back.

[geepot]

Following up:
OBS encoding delay is definitely to blame here. Switching from x264 to the AMD hardware encoder resulted in shaving off 2.5 seconds of latency from both RTMP and SRT. There is a spot in OBS for x264 options and I'll have to play around with that to see if I can achieve the same latency drop with the CPU encoder. I would be curious to see if this applies to CPU vs hardware accelerated versions of Restreamer as well.

[ibrah3m]

any updates I have also an 11sec or more delay!