option to survive "Invalid data found when processing input"

[Ilya Basin]

Grabbing /dev/video1. The device driver is not so good: every 5-10 minuts I get:

[video4linux2,v4l2 @ 0x5555557c0960] Dequeued v4l2 buffer contains x bytes, but y were expected. Flags: 0x00000001.
/dev/video1: Invalid data found when processing input

ffplay continues after such error; ffmpeg dies.

Need an option to ignore the error. It can be a generic input option (before -i) to tolerate max n errors in a row.

[il@mar ffmpeg-git]$ while true; do for x in 0 1 2; do v4l2-ctl -d /dev/video0 -i $x; sleep 4; done; done >/dev/null &
[1] 1199
[il@mar ffmpeg-git]$ time ./ffmpeg -y -f video4linux2 -standard PAL -i /dev/video0 -codec h264 -pix_fmt yuv422p -preset veryfast test.mkv
ffmpeg version N-74579-g77c2bd4 Copyright (c) 2000-2015 the FFmpeg developers
  built with gcc 5.2.0 (GCC)
  configuration: --prefix=/usr --shlibdir=/usr/lib --pkg-config-flags=--static --disable-static --disable-stripping --enable-gpl --enable-gnutls --enable-libass --enable-libfdk-aac --enable-libfreetype --enable-libmp3lame --enable-libopus --enable-libtheora --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libx265 --enable-nonfree --enable-shared --enable-x11grab
  libavutil      54. 31.100 / 54. 31.100
  libavcodec     56. 58.100 / 56. 58.100
  libavformat    56. 40.101 / 56. 40.101
  libavdevice    56.  4.100 / 56.  4.100
  libavfilter     5. 36.100 /  5. 36.100
  libswscale      3.  1.101 /  3.  1.101
  libswresample   1.  2.101 /  1.  2.101
  libpostproc    53.  3.100 / 53.  3.100
Input #0, video4linux2,v4l2, from '/dev/video0':
  Duration: N/A, start: 8767.851933, bitrate: 165888 kb/s
    Stream #0:0: Video: rawvideo (UYVY / 0x59565955), uyvy422, 720x576, 165888 kb/s, 25 fps, 25 tbr, 1000k tbn, 1000k tbc
[libx264 @ 0x9284000] using cpu capabilities: MMX2 SSE Cache64
[libx264 @ 0x9284000] profile High 4:2:2, level 3.0, 4:2:2 8-bit
[libx264 @ 0x9284000] 264 - core 148 r2579 73ae2d1 - H.264/MPEG-4 AVC codec - Copyleft 2003-2015 - http://www.videolan.org/x264.html - options: cabac=1 ref=1 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=2 psy=1 psy_rd=1.00:0.00 mixed_ref=0 me_range=16 chroma_me=1 trellis=0 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=0 threads=1 lookahead_threads=1 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=1 b_bias=0 direct=1 weightb=1 open_gop=0 weightp=1 keyint=250 keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahead=10 rc=crf mbtree=1 crf=23.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00
Output #0, matroska, to 'test.mkv':
  Metadata:
    encoder         : Lavf56.40.101
    Stream #0:0: Video: h264 (libx264) (H264 / 0x34363248), yuv422p, 720x576, q=-1--1, 25 fps, 1k tbn, 25 tbc
    Metadata:
      encoder         : Lavc56.58.100 libx264
Stream mapping:
  Stream #0:0 -> #0:0 (rawvideo (native) -> h264 (libx264))
Press [q] to stop, [?] for help
Past duration 0.602974 too large   19926kB time=00:04:02.00 bitrate= 674.5kbits/s
[video4linux2,v4l2 @ 0x9281300] Dequeued v4l2 buffer contains 414720 bytes, but 829440 were expected. Flags: 0x00002005.
/dev/video0: Invalid data found when processing input
frame= 8125 fps= 14 q=26.0 Lsize=   49353kB time=00:09:50.56 bitrate= 684.6kbits/s
video:49294kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.121074%
[libx264 @ 0x9284000] frame I:57    Avg QP:18.88  size: 22477
[libx264 @ 0x9284000] frame P:6820  Avg QP:22.26  size:  6636
[libx264 @ 0x9284000] frame B:1248  Avg QP:22.55  size:  3158
[libx264 @ 0x9284000] consecutive B-frames: 77.0%  7.3%  0.5% 15.2%
[libx264 @ 0x9284000] mb I  I16..4: 26.0% 67.4%  6.6%
[libx264 @ 0x9284000] mb P  I16..4: 24.5% 16.5%  0.2%  P16..4: 49.3%  3.4%  0.6%  0.0%  0.0%    skip: 5.5%
[libx264 @ 0x9284000] mb B  I16..4:  1.2%  0.6%  0.0%  B16..8: 13.6%  1.0%  0.0%  direct:63.2%  skip:20.4%  L0:51.6% L1:47.3% BI: 1.1%
[libx264 @ 0x9284000] 8x8 transform intra:40.6% inter:71.4%
[libx264 @ 0x9284000] coded y,uvDC,uvAC intra: 19.3% 97.1% 55.7% inter: 1.7% 86.4% 3.8%
[libx264 @ 0x9284000] i16 v,h,dc,p: 58% 23% 15%  4%
[libx264 @ 0x9284000] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 12% 15% 60%  2%  3%  2%  2%  2%  2%
[libx264 @ 0x9284000] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 11% 77%  7%  1%  1%  1%  1%  1%  1%
[libx264 @ 0x9284000] i8c dc,h,v,p: 59% 15% 18%  7%
[libx264 @ 0x9284000] Weighted P-Frames: Y:2.6% UV:2.5%
[libx264 @ 0x9284000] kb/s:683.54

real    9m54.247s
user    9m31.607s
sys     0m15.387s

[Carl Eugen Hoyos]

How would FFmpeg continue to encode if no input data is available?

[Ilya Basin]

Replying to cehoyos:

How would FFmpeg continue to encode if no input data is available?

Because subsequent buffers are valid.

[Alexander Strasser]

Earlier this year I could reproduce and analyse the problem with a specific web cam.

The problem was also observed by Stephan Hilb. He sent a patch to treat frames of unexpected size the same way we treat frames which are flagged to be corrupted (V4L2_BUF_FLAG_ERROR) in input device v4l2.

Stephan's patch is now in FFmpeg master ( commit b761ae072a169eb183abe0785a258b9787e267d3 ).

Thus the ffmpeg CLI tool should not die anymore for this specific error condition with a v4l2 input device. A generic option to survive "Invalid data found when processing input" should not be needed for this particular issue.