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?

[Jack Cushman]

This comment had substantial help from AI; I apologize that I don't have expertise to do it alone. As a human, I verify that I have checked the details as much as I can and they look correct, and that the patch succeeds in letting ffmpeg use a capture device that previously worked only with OBS and uStreamer.

I reproduced this issue on master (571dd04, 2026-05-02) against a MacroSilicon/MS2130-class USB HDMI capture device (USB ID 345f:2130, uvcvideo, Linux 6.18.25). The symptom matches this ticket: "Dequeued v4l2 buffer contains corrupted data (0 bytes)" repeated at startup, followed either by no encoded frames or by a uniform black startup frame.

I tested with and without oviano's discard-corrupted-buffers patch from this ticket, rebased onto current libavdevice/v4l2.c. The four-line patch I tested and logs demonstrating the issue are attached.

The AI made these substantive changes and comments while rebasing, which I am not able to evaluate: "use the current bytesused local variable, and propagate enqueue_buffer() failure if requeueing the corrupted buffer fails. No packet unref is needed in this path because no packet has been allocated yet."

Test result:

Unpatched master:

ffmpeg -f v4l2 -input_format yuyv422 -video_size 1024x768 -framerate 60 -i /dev/video0 -t 6 -f null -

exits immediately with zero encoded frames after the startup corrupted-buffer messages.

With the rebased patch applied, the same continuous capture runs normally:

frame=360 fps=60 ... time=00:00:06.00

A delayed frame grab from the patched build also captures the real HDMI source image:

ffmpeg -f v4l2 -input_format yuyv422 -video_size 1024x768 -framerate 60 \

-i /dev/video0 -vf 'select=gte(t\,5)' -frames:v 1 out.jpg

Isolation of the bug to libavdevice/v4l2.c, from the attached ioctl trace and some usbmon comparison:

• ustreamer and ffmpeg send the same UVC streaming probe/commit payload for YUYV 1024x768 @ 60. Same UVC mode; this does not appear to be a format-negotiation failure.
• On the same device and mode, ustreamer requests 5 MMAP buffers and captures valid video. FFmpeg hardcodes desired_video_buffers = 256; the driver returns 32.
• The ioctl trace shows FFmpeg dequeuing startup buffers with V4L2_BUF_FLAG_ERROR set and bytesused = 0. Current libavdevice/v4l2.c handles that path by setting bytesused = 0 and continuing, which can forward zero-size packets upstream. This is in mmap_read_frame(), directly below the existing comment: "FIXME: Some special treatment might be needed in case of loss of signal..." The rebased patch implements one such treatment by requeueing/discarding V4L2_BUF_FLAG_ERROR buffers internally and continuing to dequeue.

List of devices that the AI thinks are affected by the same underlying issue:

• Magewell xi100dusb-hdmi: this ticket
• Magewell USB Capture HDMI Plus: comments #8 and #10
• Elgato Game Capture HD60 S+: ​https://forums.raspberrypi.com/viewtopic.php?t=309098
• Elgato Cam Link 4K: ​https://forums.raspberrypi.com/viewtopic.php?t=295129
• MacroSilicon/MS2130-class device: ​https://www.mail-archive.com/cin%40lists.cinelerra-gg.org/msg05694.html

Attachments:

• 0001-v4l2-discard-corrupted-buffers-rebased.patch Rebased version of oviano's discard-corrupted-buffers patch for current FFmpeg master (571dd04).

• ffmpeg-master-v4l2-to-null.log Reproducer on unpatched FFmpeg master: capture-to-null exits with zero encoded frames after startup V4L2_BUF_FLAG_ERROR / bytesused=0 buffers.

• ffmpeg-patched-v4l2-to-null.log Same capture-to-null command with the rebased patch applied: captures 360 frames over 6 seconds at 60 fps.

• ffmpeg-master-v4l2-ioctl.log strace ioctl log from unpatched master showing V4L2 setup and startup dequeue behavior, including FFmpeg requesting 256 MMAP buffers, the driver returning 32, and repeated VIDIOC_DQBUF startup behavior.