We use RPI4 for automation. One of our use-cases is to capture image frames via webcam/HDMI grabber as fast as possible and do some analytics. We use python and opencv for capturing, but it's not really important, as out tests shows that capturing API doesn't really affect result we see. We tried V4L2 native API over uvcvideo and python bindings for this API as well.
So we are talking about communication with /dev/videoX video device and grabbing frames from it.
Pseudo algorithm we use for this test is the following:
seq_num = 0
while True:
open /dev/videoX
for i in range(10):
capture frame <seq_num>_<i>.png
seq_num += 1
close /dev/videoX
Note, that we intentionally re-open video device every seq_num iteration and do sequence of 10 captures for each iteration.
We observe that after device gets opened, we might receive green frames. We are not sure what is the reason of that, but it seems that it's somewhere on either uvcvideo or USB driver side. We tried different capturing resolutions, different FPS settings, different capturing APIs and different cameras, and nothing seems impacting the results. Although if we run the same code on Linux PC, we don't see green frames appearing.
In our test, most of the times, we see several green frames, and then normal frames starting getting captured, until we re-open video device. Sometimes, we don't see green frames at all, but most likely each sequence starts with some green frames.
This picture shows what's I'm talking about:
After digging over the Internet we found some reports of similar issues, but not exactly the one we see. I bet people ignore it, because they just keep device open in their use-cases and ignore the fact that some initial frames are corrupted. It's crucial in our use-cases thought.
Have anybody seen such issues on RPI4, or maybe have some ideas how to tackle this issue? Yes, we know that we can try to keep device open, but as I said use-case requires frequent device re-openings.
