Skip to content
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

demo_ffmpeg.py example corrupts output FLV after exactly 31m17s #15

Open
dtrasboIMG opened this issue Feb 1, 2024 · 1 comment
Open

Comments

@dtrasboIMG
Copy link

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.

@Eittipat
Copy link
Owner

Eittipat commented Apr 3, 2024

Sorry for late reply, This is valuable information

Can you provide me an input file example? Or
Can you just run all test to see if it all pass?

If it passed, try to modify the test to use your file instead and let see what happened

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants