[FFmpeg-devel] [PATCH] lavd/v4l2: Return FFERROR_REDO when receiving a frame of unexpected size

Carl Eugen Hoyos ceffmpeg at gmail.com
Thu Mar 21 00:46:27 EET 2019


2019-03-20 22:26 GMT+01:00, Alexander Strasser <eclipse7 at 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


More information about the ffmpeg-devel mailing list