Video glitches at the bottom of the frame on still images using SRT

[rrebuffo]

Describe the bug The image is broken mostly at the bottom third of the frame, repeating lines or showing green/purple/gray glitches. It is specially worst when the stream is showing still images.

To Reproduce Steps to reproduce the behavior:

1. Add a new channel with an SRT listener
2. Stream from OBS using NVENC H.264
3. Play a still image periodically or a live feed with static lower thirds
4. Preview the stream on HLS/SRT/RTMP

Expected behavior Stable and clean image

Screenshots

Desktop (please complete the following information):

• OS: Windows 10
• Browser Chromium
• Version 121

Additional context Streaming PC is: Windows 10 Pro Core i7-7700 8GB RAM Nvidia 1660 super

It is worth noting that even though I listed those specs, I tested it with many other PCs. All of them using OBS and NVENC over SRT. The problem disappears the moment I switch the source to the RTMP protocol.

[ioppermann]

What is the bitrate you are using? This looks like that many UDP packets get unrecoverably lost. SRT uses UDP for the data transfer. What are the specs of the box where Restreamer is running on? Does it run on the same Windows box?

[Happyllama25]

I noted this too, exact same issue, same segment of frame too. For now, I just used RTMP instead.

• Windows 11
• Nvidia GTX 1650 S

OBS with NVENC over SRT too

It would occur during the web preview but also if I enabled the SRT server and used VLC, I would get the same visual artefacts.

Bitrate 3500, my Restreamer is running on a small 1core 1gb linux container, not doing any transcoding, just forwarding.

[rrebuffo]

Bitrate is anything between 4000Kbps and 10000Kbps, either variable or constant, with no change in the result. It's the same isuue on any bitrate.

Some remarks:

• Complex sources with a lot of movement at 60fps don't show this problem, only still images over a long period of time.
• The issue is still present streaming and playing through localhost.
• The host machine shows no high CPU usage so system resources are not a bottleneck.

It seems to me a problem with an FFMPEG setting or something. I don't fully understand what I'm saying but could it be related to bad handling of null packets from the encoder?

[ioppermann]

Unfortunately, I don't have Windows machine to test this on. There might be a UDP sending throughput issue.

It is interesting that the problem occurs only when you're streaming a still image. Probably the key frame interval is too high and a few packets got lost. Then these glitches stay until the next key frame.

In the output encoder settings, I suggest that you set a fixed key frame interval of 2 seconds and to disable B-Frames. This is the recommended setting for streaming.

I tested it with these settings. Sending the SRT from my Mac to a Pi 3 runnning Restreamer and I wasn't seeing any glitches.

[Nono-04]

Hi there, We are experiencing the same issue with artifacts showing up when using SRT.

In the output encoder settings, I suggest that you set a fixed key frame interval of 2 seconds and to disable B-Frames. This is the recommended setting for streaming. We have tried this, but unfortunately, it doesn't seem to improve the situation.

This might be unrelated, but I found the following in the Process Details whenever the artifacts appeared:

@1717856659 [mpegts    ] Packet corrupt (stream = 0, dts = 753300000).
@1717856659 [in#0/mpegts @ 0x7f916d711a80] corrupt input packet in stream 0.

[backface]

I have the same issue: Corrupt packages in the input stream (or the output stream of the SRT server as picked up by FFmpeg and mentioned visual artifacts (though not necessarily on still images only).

I can also confirm this is not a network or encoder issue. These problems appear whether the upstream is sent from OBS on Mac or from the FFmpeg on localhost (Linux) - maybe to a lesser or varying extent, I cannot see a pattern of what could be causing it.

These problems do not occur with RTMP or when using the same encoder with a different (SRT)streaming server.

here is an example of the FFmpeg upstream I used:

ffmpeg -re \
  -stream_loop -1 \
  -i BigBuckBunny.mp4 \
  -vcodec libx264 \
  -r 30 \
  -g 60 \
  -b:v 5M \
  -ar 44100 -acodec aac \
  -b:a 128K \
  -f mpegts \
  "srt://localhost:6000?mode=caller&transtype=live&streamid=...."

running with docker and image datarhei/restreamer:latest (2.12.0) Release: restreamer-v2.12.0 datarhei-core v16.16.0 (linux/amd64) - bitter-fire-7026

[UnluckyForSome]

I have the same issue, I think it’s something to do with Restreamer because I was testing all sorts of settings and restarting the stream to see if it would fix it. On one restart, the issue was gone. Then after the next restart (after changing no settings) it returned. Something wrong with packets and handshakes!

Another nugget I can give you - the SRT to my local Restreamer instance doesn’t have this issue, but an SRT to a public Restreamer instance develops these artefacts. Stumped!