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

Marton Balint cus at passwd.hu
Thu Mar 21 01:14:29 EET 2019



On Wed, 20 Mar 2019, Carl Eugen Hoyos wrote:

> 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.

Maybe just set the packet corrupt flag and log an error, but return the 
partial buffer?

Regards,
Marton


More information about the ffmpeg-devel mailing list