[FFmpeg-trac] #4988(undetermined:new): Dequeued v4l2 buffer contains corrupted data (0 bytes).

[FFmpeg]

#4988: Dequeued v4l2 buffer contains corrupted data (0 bytes).
-------------------------------------+-------------------------------------
             Reporter:  neik         |                    Owner:
                 Type:  defect       |                   Status:  new
             Priority:  normal       |                Component:
              Version:  git-master   |  undetermined
             Keywords:               |               Resolution:
             Blocking:               |               Blocked By:
Analyzed by developer:  0            |  Reproduced by developer:  0
-------------------------------------+-------------------------------------

Comment (by 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 is because
 despite the buffer being given a size of zero and therefore no longer
 bailing out completely, it contains a zero timestamp. 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 to far
 apart.

 So my second patch 0001-v4l2-added-discard-timestamps-option.patch is to
 add an option to simply 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.

--
Ticket URL: <https://trac.ffmpeg.org/ticket/4988#comment:1>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker