#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
_______________________________________________
FFmpeg-trac mailing list
FFmpeg-trac@avcodec.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-trac
