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

[Alexander Strasser]

Hi Stephan!

On 2019-03-25 20:32 +0100, Stephan Hilb wrote:
> Alexander Strasser wrote on 21.03.2019 at 23:34:
>
> > 3. Return zero-sized packets => This works and is consistent with how
> >    we handle frames flagged to be corrupted (V4L2_BUF_FLAG_ERROR).
> >    See commit 28f20d2ff487aa589643d8f70eaf614b78839685 .
>
> I posted a patch for this on Sat, 25 Aug 2018. It seems to have been
> forgotten, attached again.

I didn't know you sent that patch.


> From 0af8515acca4d598570d03450656adc0ed7ac2d7 Mon Sep 17 00:00:00 2001
> From: Stephan Hilb <stephan at ecshi.net>
> Date: Sun, 10 Jun 2018 21:07:52 +0200
> Subject: [PATCH] lavd/v4l2: skip buffers not matching frame_size
>
> By adopting the same behaviour as if there was corrupted data in the
> buffer (see the check for V4L2_BUF_FLAG_ERROR) the resulting rawvideo
> now at least contains valid data (the previous frame being duplicated).
> Fixes video capturing for some stk1160 devices.
> ---
>  libavdevice/v4l2.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/libavdevice/v4l2.c b/libavdevice/v4l2.c
> index 10a0ff0dd6..ab903bbcee 100644
> --- a/libavdevice/v4l2.c
> +++ b/libavdevice/v4l2.c
> @@ -534,11 +534,10 @@ static int mmap_read_frame(AVFormatContext *ctx, AVPacket *pkt)
>              s->frame_size = buf.bytesused;
>
>          if (s->frame_size > 0 && buf.bytesused != s->frame_size) {
> -            av_log(ctx, AV_LOG_ERROR,
> +            av_log(ctx, AV_LOG_WARNING,
>                     "Dequeued v4l2 buffer contains %d bytes, but %d were expected. Flags: 0x%08X.\n",
>                     buf.bytesused, s->frame_size, buf.flags);
> -            enqueue_buffer(s, &buf);
> -            return AVERROR_INVALIDDATA;
> +            buf.bytesused = 0;
>          }
>      }

It is exactly the same as mine except for degrading the log message
from AV_LOG_ERROR to AV_LOG_WARNING which should be fine.

As I stated before I am in favor of this solution and I am fine with
applying your version. Let's wait a little while longer if there are
objections.


  Alexander