2019-03-20 22:26 GMT+01:00, Alexander Strasser <eclip...@gmx.net>: > Hi all! > > On 2019-03-20 19:56 +0100, Alexander Strasser wrote: >> I had found that when capturing video for some hours from >> USB Camera-B4.09.24.1 (Manufacturer: OmniVision Technologies, Inc.), >> sometimes when invoking the ioctl DQBUF, the returned buffer is not >> filled with the size we expect for the raw video frame. >> >> Here are two examples for such occurrences: >> >> [video4linux2,v4l2 @ 0x258b440] Dequeued v4l2 buffer contains 609596 >> bytes, but 614400 were expected. Flags: 0x00000001. >> /dev/video1: Invalid data found when processing input >> >> [video4linux2,v4l2 @ 0x225f440] Dequeued v4l2 buffer contains 609508 >> bytes, but 614400 were expected. Flags: 0x00000001. >> /dev/video1: Invalid data found when processing input >> >> The ffmpeg CLI tool will then stop capturing and exit. >> >> To avoid this, return FFERROR_REDO instead. I have not seen the >> issue appearing twice or more often in a row. It was more like >> one single error every two hours. > > > After thinking about the FFERROR_REDO approach some more, I think it > is not ideal in the case where a driver permanently delivers frames > of unexpected size. The FFmpeg lib call would not return to the client, > potentially freezing the running program. > > So maybe the zero-sized package approach, like we do with the corrupted > frames, is more robust here? Any opinions?
You could check if a sane frame was already received before the wrong size. Carl Eugen _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel