Dequeued v4l2 buffer contains corrupted data (0 bytes).

[neik]

Summary of the bug:
How to reproduce:

Capture from Magewell xi100dusb-hdmi

$ ffmpeg -y -report -ts mono2abs -thread_queue_size 512 -video_size 1280x720 -framerate 60 -i /dev/video0 -pix_fmt yuv420p out.mkv
ffmpeg started on 2015-11-04 at 11:36:36
Report written to "ffmpeg-20151104-113636.log"
ffmpeg version N-76448-g9ae73d0 Copyright (c) 2000-2015 the FFmpeg developers
  built with gcc 5.1.1 (GCC) 20150618 (Red Hat 5.1.1-4)
  configuration:
  libavutil      55.  5.100 / 55.  5.100
  libavcodec     57. 13.102 / 57. 13.102
  libavformat    57. 13.100 / 57. 13.100
  libavdevice    57.  0.100 / 57.  0.100
  libavfilter     6. 14.101 /  6. 14.101
  libswscale      4.  0.100 /  4.  0.100
  libswresample   2.  0.100 /  2.  0.100
[video4linux2,v4l2 @ 0x3113140] Dequeued v4l2 buffer contains corrupted data (0 bytes).
[video4linux2,v4l2 @ 0x3113140] Detected monotonic timestamps, converting
Input #0, video4linux2,v4l2, from '/dev/video0':
  Duration: N/A, start: 1446636130.558504, bitrate: 884736 kb/s
    Stream #0:0: Video: rawvideo (YUY2 / 0x32595559), yuyv422, 1280x720, 884736 kb/s, 60 fps, 60 tbr, 1000k tbn, 1000k tbc
Output #0, matroska, to 'out.mkv':
  Metadata:
    encoder         : Lavf57.13.100
    Stream #0:0: Video: mpeg4 (FMP4 / 0x34504D46), yuv420p, 1280x720, q=2-31, 200 kb/s, 60 fps, 1k tbn, 60 tbc
    Metadata:
      encoder         : Lavc57.13.102 mpeg4
Stream mapping:
  Stream #0:0 -> #0:0 (rawvideo (native) -> mpeg4 (native))
Press [q] to stop, [?] for help
[video4linux2,v4l2 @ 0x3113140] Dequeued v4l2 buffer contains corrupted data (0 bytes).
    Last message repeated 30 times
frame=  975 fps= 60 q=2.0 Lsize=    1223kB time=00:14:42.63 bitrate=  11.4kbits/s
video:1213kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.850584%

Adding audio causes the framerate to drop to <1fps

$ ffmpeg -y -report -ts mono2abs -thread_queue_size 512 -video_size 1280x720 -framerate 60 -i /dev/video0 -thread_queue_size 512 -ac 2 -channel_layout stereo -f alsa -i hw:1 -pix_fmt yuv420p out.mkv
ffmpeg started on 2015-11-04 at 11:40:34
Report written to "ffmpeg-20151104-114034.log"
ffmpeg version N-76448-g9ae73d0 Copyright (c) 2000-2015 the FFmpeg developers
  built with gcc 5.1.1 (GCC) 20150618 (Red Hat 5.1.1-4)
  configuration:
  libavutil      55.  5.100 / 55.  5.100
  libavcodec     57. 13.102 / 57. 13.102
  libavformat    57. 13.100 / 57. 13.100
  libavdevice    57.  0.100 / 57.  0.100
  libavfilter     6. 14.101 /  6. 14.101
  libswscale      4.  0.100 /  4.  0.100
  libswresample   2.  0.100 /  2.  0.100
[video4linux2,v4l2 @ 0x2337320] Dequeued v4l2 buffer contains corrupted data (0 bytes).
[video4linux2,v4l2 @ 0x2337320] Detected monotonic timestamps, converting
Input #0, video4linux2,v4l2, from '/dev/video0':
  Duration: N/A, start: 1446636130.558504, bitrate: 884736 kb/s
    Stream #0:0: Video: rawvideo (YUY2 / 0x32595559), yuyv422, 1280x720, 884736 kb/s, 60 fps, 60 tbr, 1000k tbn, 1000k tbc
Input #1, alsa, from 'hw:1':
  Duration: N/A, start: 1446637235.116087, bitrate: 1536 kb/s
    Stream #1:0: Audio: pcm_s16le, 48000 Hz, stereo, s16, 1536 kb/s
Output #0, matroska, to 'out.mkv':
  Metadata:
    encoder         : Lavf57.13.100
    Stream #0:0: Video: mpeg4 (FMP4 / 0x34504D46), yuv420p, 1280x720, q=2-31, 200 kb/s, 60 fps, 1k tbn, 60 tbc
    Metadata:
      encoder         : Lavc57.13.102 mpeg4
    Stream #0:1: Audio: ac3 ([0] [0][0] / 0x2000), 48000 Hz, stereo, fltp, 192 kb/s
    Metadata:
      encoder         : Lavc57.13.102 ac3
Stream mapping:
  Stream #0:0 -> #0:0 (rawvideo (native) -> mpeg4 (native))
  Stream #1:0 -> #0:1 (pcm_s16le (native) -> ac3 (native))
Press [q] to stop, [?] for help
[video4linux2,v4l2 @ 0x2337320] Dequeued v4l2 buffer contains corrupted data (0 bytes).
    Last message repeated 30 times
[matroska @ 0x234d0a0] Starting new cluster due to timestampitrate=   1.2kbits/s
frame=    1 fps=0.1 q=1.6 Lsize=     179kB time=00:18:24.60 bitrate=   1.3kbits/s
video:10kB audio:166kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 1.412143%

[neik]

Without audio

[neik]

Wwith audio

[oviano]

I believe I have encountered something very similar to this.

I am attaching some logs which illustrate the issue:

ffmpeg-original_code-audio-and-video.log - this is the output of a capture of both video and audio. FPS was zero for me, it didn't capture anything.

ffmpeg-original-code-no-audio - this is what happens when you don't capture the audio. This time it does capture video, but produces a bunch of warnings about Past Duration being too large.

I've worked through the code and I believe the issue is related to the fix for issue 4030

​https://trac.ffmpeg.org/ticket/4030

Firstly, there is something not working at either the driver or hardware level for this capture device because at the start of every capture it produces around 30 or so (in my case) corrupted buffers. So these fixes/issues are all about how ffmpeg deals with this situation.

The fix for 4030 involved zeroing out the buffer size and then proceeding as normal, but I believe there is still a knock-on leading to further unpredictable behaviour as illustrated in this bug report. This may be because despite the buffer being given a size of zero and therefore no longer bailing out from the capture, it contains a zero timestamp. Perhaps this confuses ffmpeg when it finally receives a valid timestamp which is much different.

I believe a more logical solution to 4030 would involve ditching the buffer altogether if it is corrupt, so that its timestamp no longer impacts ffmpeg later on.

I have written a patch that does this, 0001-v4l2-discard-corrupted-buffers.patch.

After applying this patch, I can capture both video and audio, as per the log ffmpeg-discard-corrupt-buffer.log.

However, as you can see in this log, there are still a bunch of warnings about Past Duration being too large. Note that these warnings don't always occur, but usually do in my case. My theory is that there is still a knock-on effect from the initial corrupted buffers and maybe the time it takes these to be resolved leaving the input and output timestamps too far apart. The capture seems ok though, and the warning can be hidden either by disabling warnings or changing the hardcoded "0.6" threshold value to something higher.

However, this is not really desirable so my second patch 0001-v4l2-added-discard-timestamps-option.patch iinstead adds a general option to v4l2 to discard the timestamps from the capture, and allow the encoder or whatever to calculate these from the framerate.

As can be seen from the output of the log, the capture now behaves better with the only warnings now the original corrupted buffer ones.

Also, the capture seems fine using this method - presumably in my test case the libx265 encoder or some other part of ffmpeg applies sensible timestamps based on the framerate.

[Carl Eugen Hoyos]

+    if (s->ts_mode == V4L_TS_DISCARD)
+        pkt->pts = AV_NOPTS_VALUE;
+    else {

Please add braces when sending this to the development mailing list: No patches should be discussed here.

[oviano]

Ok, sorry!

I had seen that bug 4030 mentioned above had patches attached so I thought it was ok.

I will fix the braces, but I have already sent the patches to the dev mailing list.

[oviano]

Just adding that I've reproduced the V4L2 buffer error outside of FFmpeg, using the capture example included with the linuxtv V4L2 API:

​https://linuxtv.org/downloads/v4l-dvb-apis/capture-example.html

This is useful in ruling out FFmpeg as having somehow caused the issue, although FFmpeg still needs to workaround it better as proposed here.

In the meantime will report the issue to linuxtv and then possible the manufacturer of the device if necessary, referencing this bug report.

[oviano]

A workaround is to reload the uvcvideo kernel module:

$ sudo modprobe -v -r uvcvideo
$ sudo modprobe -v uvcvideo

This has to be done each time before running FFmpeg though as the underlying problem seems to be that V4L2/the driver isn't clearing up properly after the capture.

I've raised this issue with the linux-media developer mailing list to try and get the underlying issue fixed.

[oviano]

This didn't prove to be of much interest to the people on the linux-media dev list, or indeed the manufacturers so I'm not sure if a fix will be forthcoming.

Also, none of my FFmpeg patches elicited any kind of response on the ffmpeg dev list either, so it's over and out from me.

[Nick]

I also have this issue. We use magewell "USB capture HDMI PLUS" device for capture video from medical video source. But if change connection type from usb 2.0 to USB 3.0 application is crashed. If run command "ffplay /dev/video0" in ubuntu console, I see error in console log

[video4linux2,v4l2 @ 0x7f806c000b80] Dequeued v4l2 buffer contains corrupted data (0 bytes).

and playing video is stopped.

[Nick]

This is no issue ffmpeg
Now I create play video tests with
-ffplay
-vlc
-gstreammeg

All test fail with magewell, but work with other device (epiphan).

[jaysonlarose]

Hello, six year old ticket!

Carl Eugen Hoyos said "no patches should be discussed here", but I for one sure am glad that they were!

I, too have a Magewell USB Capture HDMI Plus capture device, and applying 0001-v4l2-discard-corrupted-buffers.patch fixed my issue.

What do I have to do to request that this patch make its way into the main codebase?