Message ID | 68fadf1cb959c4653e7d4b180f0edde67affd1f2.1559764198.git.eclipse7@gmx.net |
---|---|
State | New |
Headers | show |
On 2019-06-05 22:04 +0200, Alexander Strasser wrote: > From: Stephan Hilb <stephan@ecshi.net> > > Behave like we do for V4L2_BUF_FLAG_ERROR, implemented in commit 28f20d2ff4 . > > For some devices (probably also related to the V4L driver implementation) > it happens that when invoking the ioctl DQBUF, the returned buffer is not > of the expected size. 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 > > For the ffmpeg CLI tool this means it will stop capturing and exit. > > The described behaviour was observed at least with one OmniVision USB > web cam and with some stk1160 devices. > > If you search the web for the error message, you will find quite a few > instances of this problem. Some of them experienced on other devices. > > Probably fixes ticket #4795 > > Signed-off-by: Alexander Strasser <eclipse7@gmx.net> > --- > > This is exactly Stephan's patch except for the commit message. > > @Stephan: I hope you are OK with my wording in the new message. > > I contacted Giorgio off-list and also put him in Bcc for this email. > > He previously reacted, but he probably doesn't have enough time. So if > there are no objections I intent to commit in roughly a week if no > more issues are found and no objections are raised. Will push soon. The current behavior surely causes problems for some users. So it's better drop the short frame's data, log a warning and have applications continue capturing instead of aborting. It's also analog to how v4l2 indev behaves when it receives corrupted data (V4L2_BUF_FLAG_ERROR). Alexander > libavdevice/v4l2.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/libavdevice/v4l2.c b/libavdevice/v4l2.c > index a9a0ed324d..446a243cf8 100644 > --- a/libavdevice/v4l2.c > +++ b/libavdevice/v4l2.c > @@ -538,11 +538,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; > } > } > > --
On 2019-06-25 00:08 +0200, Alexander Strasser wrote: > On 2019-06-05 22:04 +0200, Alexander Strasser wrote: > > From: Stephan Hilb <stephan@ecshi.net> > > > > Behave like we do for V4L2_BUF_FLAG_ERROR, implemented in commit 28f20d2ff4 . > > > > For some devices (probably also related to the V4L driver implementation) > > it happens that when invoking the ioctl DQBUF, the returned buffer is not > > of the expected size. 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 > > > > For the ffmpeg CLI tool this means it will stop capturing and exit. > > > > The described behaviour was observed at least with one OmniVision USB > > web cam and with some stk1160 devices. > > > > If you search the web for the error message, you will find quite a few > > instances of this problem. Some of them experienced on other devices. > > > > Probably fixes ticket #4795 > > > > Signed-off-by: Alexander Strasser <eclipse7@gmx.net> > > --- > > > > This is exactly Stephan's patch except for the commit message. > > > > @Stephan: I hope you are OK with my wording in the new message. > > > > I contacted Giorgio off-list and also put him in Bcc for this email. > > > > He previously reacted, but he probably doesn't have enough time. So if > > there are no objections I intent to commit in roughly a week if no > > more issues are found and no objections are raised. > > Will push soon. Pushed. Not quite as soon as planned, but hopefully better late than never. [...] Alexander
diff --git a/libavdevice/v4l2.c b/libavdevice/v4l2.c index a9a0ed324d..446a243cf8 100644 --- a/libavdevice/v4l2.c +++ b/libavdevice/v4l2.c @@ -538,11 +538,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; } }