-
-
Notifications
You must be signed in to change notification settings - Fork 456
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Corrupt packages and visual artefacts in SRT Server #855
Comments
Thanks for this detailed bug report. Unfortunately, I couldn't reproduce yet the described bug (I tested on MacOS with ffmpeg and Restreamer on the same machine), I have a suspicion where the problem might be. You send the stream with ffmpeg and with a certain latency to the Restreamer SRT server. Restreamer is then pulling the stream via SRT from it's own SRT server with a certain latency in order to convert it into HLS. This internal SRT latency is by default 20ms and cannot be changed currently. This might cause the issues when there are some packet drops internally. The solution would be to make the internal latency configurable. To exclude that the SRT server itself is the problem, try to pull the stream from the SRT server (e.g. with ffplay) with a different latency. Use the same URL as for sending, but remove the
|
yes, I am also seeing these artifacts and corrupt packages if directly pulled by ffplay and even higher latencies. Most surprisingly I am seeing even more of these artifacts (and corrupt packages logs) in the stream received with ffplay - despite the latency settings - than in the restreamer preview when watched side by side! |
I tried to reproduce this. My setup is a MacBook Pro that is sending the stream to the Restreamer SRT server running on a Raspberry Pi 4. And also pulling from the SRT server back to the MacBook. All via wifi. Sending the stream:
Pulling the data
There were some errors, but only occasionally, not in the extreme extend you are describing. |
hmm. I compared it with other SRT implementations, and interestingly I run into similar issues if I try a self-compiled version of https://github.com/Edward-Wu/srt-live-server (with Ubuntu's libsrt) over a local network and even localhost (on my most powerful machine). But I can distribute a clear, uncorrupted stream even over long-distance networks with ovenmediaengine - so there must be some key difference in srt server implementations... |
SRT is based on UDP, which might not be treated with highest priority by network devices on the way from you to the server and back and packets will get dropped. SRT tries to recover from packet loss, but it depends on the configured latency how good it manages to. I updated the Restreamer's SRT server to the latest version. Please try out the |
Just gave it a quick run: running datarhei/restreamer:dev image with default settings does not solve that issue. |
Describe the bug
Corrupt packages in the SRT Servers output stream that correlate with visual artifacts in the video
Process log entries show up like:
or sometimes also as:
this is also a re-filing - or sum up - of existing issues that seem to be related or show the same problem such as #839 and #755
After a series of tests, I can confirm that this happens regardless of the input video, whether it is a still image or not, regardless of the encoder (OBS on Mac and ffmpeg on Linux), whether the upstream is delivered from a remote machine via network or with ffmpeg from localhost or with a latency setting of latency=1000000 or more. I have tried running Restreamer on 2 different machines (different versions of Ubuntu and Debian) and with network_mode=host.
Sometimes, it shows up more frequently than at other times or is more or less obvious (it might certainly be enhanced by network issues!), but it shows nonetheless, in best cases, only every 4 or 5 minutes.
Crucially this problem does not appear when using the RTMP server or when bypassing restreamer sending the upstream directly to a different SRT server. So far I can only conclude that this must be a bug in the SRT server implementation. If I can do anything reasonable to track this down let me know.
To Reproduce
Expected behavior
Clear, uncorrupted video stream
Screenshots
Desktop (please complete the following information):
Additional context
The text was updated successfully, but these errors were encountered: