How to recover from invalid FU-A packet?
SijmenHuizenga opened this issue · comments
Sometimes we're seeing an rtsp stream giving a lot of invalid FU-A packet (non-starting) errors. It only stops after we restart the rtsp-reader.
When this happens, and we visualize the stream, the majority of the image is pixelated. But the top part of the image is not. Like this:
The stream never recovers. But if we restart the gortsplib.Client, the stream recovers. I've observed this behavior in two different camera models and 4 different hardware cameras.
From my testing, it seems that when an invalid FU-A packet is received, gortsplib gets into a state where it keeps reading invalid FU-A packet.
I've tried to read the source code of the decoder, but I can't find the problem. Any help?
Hello, by looking at the source code, there are at least 3 different errors that start with "invalid FU-A packet":
- "invalid FU-A packet (invalid size)"
- "invalid FU-A packet (can't contain both a start and end bit)"
- "invalid FU-A packet (non-starting)"
what error are you referring to?
Furthermore, they all seem stateless to me, so the problem may lie in the queue the is placed before decoding. What is the full log of MediaMTX with those sources? is it showing "XX packets lost"?
Hi, thank you for looking into this. Your analysis is correct! After further investigation I see that all recent invalid FU-A packet (non-starting) are following a RTP packets lost error message.
Gortsplib getting stuck in this error is something we observed many times between november 2023 and january 2024. Since that time we did library upgrades and started using mediamtx instead of a homegrown tool using gortsplib. Now, reading the logs of the last 7 days, it seems every time the invalid FU-A packet (non-starting), mediamtx was able to self-recover without issues.
Conclusion, I think we have accidentally resolved the issue during unrelated engineering efforts.