On Wed, 20 Mar 2019, Carl Eugen Hoyos wrote:
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.
Maybe just set the packet corrupt flag and log an error, but return the
partial buffer?
Regards,
Marton
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
