You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Recently I've been experimenting with the demo_ffmpeg.py example and worked on modifying it for restreaming to an SRT server. However, early in the process I noticed a peculiar pattern: Every time I started streaming to the RTMP server, after just over 31 minutes the SRT server would drop the connection.
The final log messages on the SRT server would look like this:
2024-01-29 14:04:06: <warning> Primary video channel: Input gap of 1024 ms
2024-01-29 14:04:06: <warning> Video channel 0: Input reporting error code 1 - resetting parser
2024-01-29 14:04:06: <warning> Resetting write pacer due to bad input
At first, I assumed the problem was with the SRT server itself or the ffmpeg arguments I used to stream to it. I ended up working a lot on fine-tuning the settings on both ends, which luckily resulted in eliminating basically all errors and warnings in the SRT server log. However, the drop after the 31 minute mark continued to happen.
So after that I started eliminating variables by streaming to the SRT server directly through OBS and directly through ffmpeg, which both worked without issue for well over the 31 minute limit. So after isolating the issue to my modified script it occured to me to try with the out-of-the-box example script.
When I play back the resulting FLV file in VLC after streaming for well over 31 minutes, VLC closes exactly at the 31:17 mark. This matches up very closely to the amount of time my modified script was able to stream to the SRT server before the connection was dropped due to "bad input".
This is my environment:
Operating system: macOS Sonoma 14.3
System architecture: Apple silicon (M1 Max)
Python version: 3.12.1 pyrtmp version: 0.3.0
I'm very curious as to whether others are able to replicate this issue, and if there's possibly an underlying issue not just in the example script but perhaps in pyrtmp. When I have the opportunity I'm going to try to replicate this issue on other platforms and report back.
Any feedback or help is much appreciated.
The text was updated successfully, but these errors were encountered:
Recently I've been experimenting with the
demo_ffmpeg.py
example and worked on modifying it for restreaming to an SRT server. However, early in the process I noticed a peculiar pattern: Every time I started streaming to the RTMP server, after just over 31 minutes the SRT server would drop the connection.The final log messages on the SRT server would look like this:
At first, I assumed the problem was with the SRT server itself or the
ffmpeg
arguments I used to stream to it. I ended up working a lot on fine-tuning the settings on both ends, which luckily resulted in eliminating basically all errors and warnings in the SRT server log. However, the drop after the 31 minute mark continued to happen.So after that I started eliminating variables by streaming to the SRT server directly through OBS and directly through
ffmpeg
, which both worked without issue for well over the 31 minute limit. So after isolating the issue to my modified script it occured to me to try with the out-of-the-box example script.When I play back the resulting FLV file in VLC after streaming for well over 31 minutes, VLC closes exactly at the 31:17 mark. This matches up very closely to the amount of time my modified script was able to stream to the SRT server before the connection was dropped due to "bad input".
This is my environment:
Operating system: macOS Sonoma 14.3
System architecture: Apple silicon (M1 Max)
Python version: 3.12.1
pyrtmp
version: 0.3.0I'm very curious as to whether others are able to replicate this issue, and if there's possibly an underlying issue not just in the example script but perhaps in
pyrtmp
. When I have the opportunity I'm going to try to replicate this issue on other platforms and report back.Any feedback or help is much appreciated.
The text was updated successfully, but these errors were encountered: