Changes between Initial Version and Version 1 of Ticket #4988, comment 1


Ignore:
Timestamp:
Aug 31, 2016, 7:03:02 PM (4 years ago)
Author:
oviano
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #4988, comment 1

    initial v1  
    1313Firstly, 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.
    1414
    15 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.
     15The 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.
    1616
    1717I 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.
     
    2121After applying this patch, I can capture both video and audio, as per the log ffmpeg-discard-corrupt-buffer.log.
    2222
    23 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.
     23However, 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. 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.
    2424
    25 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.
     25However, this is not really desirable 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.
    2626
    2727As can be seen from the output of the log, the capture now behaves better with the only warnings now the original corrupted buffer ones.
    2828
     29Also, 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.