Hi,
OK, this was sort of tied before to "lagging" video - but trying to make it a bit more concrete. Ya, some of this will be a bit fuzzy yet ๐. But we'll figure it out.
The issue that I am seeing is video degrading vs. time (lagging, blocky, etc.), and trying to quantify this using VLC statistics. I (think) I see a tie in to log level as well, but that's perhaps just due to overall load (of Python?). But that all said, some data to try to explain, and then some observations below that. Yell of course if I'm just off base. Overall things are working quite well now, just minor little items - except for the dropping video.
And the data. I tried to capture (from VLC), Lost Video packets, and Dropped Input/Read (as VLC calls them). I ran this with my Ceton PCIe card, and tried both direct and ffmpeg. Also a couple of log levels. And as a baseline, I always ran in parallel with fHDHR a test with direct stream (direct, from /dev to vlc), clear; cat /dev/ceton/ctn91xx_mpeg0_3 | vlc -
. So now, the data,
![image](https://user-images.githubusercontent.com/8756384/156472776-d419ae7f-fcd2-405b-b0f3-9fdcd9039d22.png)
And, some observations - qualitative, and I maybe just just crazy, but hoping this helps,
- The errors do seem to arrive in a bursty nature ... not dribbling in, but in "jumps"
- The errors seem to "accelerate" vs. time ... starting slow, then getting worse. A good example is the last row - it ran quite clean for a long time ... then in the last ~ 40k frames it lost 3000 of them ... and actually, fHDHR restarted! I noticed it because the VLC video stopped, when to look at the log, and saw it had restarted. I have attached the full debug log for this one (sorry, I know it's long, but wanted to share it all in case it helps).
- When the error count gets high, if I just stop the stream, start over ... it seems to be clean again.
I may be out to lunch here, but I'm wondering about memory leaks (typical for vs. time issues), but also ... perhaps run the generator in a separate thread? Or, use a Python queue? Then again, could it be because we aren't reading an integer number of packets each time? Again, just thinking out loud.
Unfortunately this tends to take a while to show up ... can be a few hours, so not quick to test. That said, let me know if there are things you want me to try.
Thanks!
crash-log.txt