[FFmpeg-devel] [PATCH v2] ffmpeg: allow full range of dts_delta_threshold

[Gyan Doshi]

On 15-04-2020 05:03 pm, Michael Niedermayer wrote:
> On Wed, Apr 15, 2020 at 10:55:47AM +0530, Gyan Doshi wrote:
>>
>> On 15-04-2020 01:33 am, Michael Niedermayer wrote:
>>> On Tue, Apr 14, 2020 at 02:48:47PM +0530, Gyan Doshi wrote:
>>>> For inputs from demuxers with AVFMT_TS_DISCONT flag,
>>>> the existing condition,
>>>>
>>>>    delta < -1LL*dts_delta_threshold*AV_TIME_BASE
>>>>
>>>> is rendered superflous due to the fixed threshold in
>>>>
>>>> pkt_dts + AV_TIME_BASE/10 < FFMAX(ist->pts, ist->dts)
>>>>
>>>> This prevents users from setting a high threshold to
>>>> avoid discontinuity correction due to errant timestamps.
>>>>
>>>> Now, the maximum of the two thresholds is used.
>>>>
>>>> fate-mpeg4-resolution-change call changed to preserve existing
>>>> timestamp correction by ffmpeg.c
>>>> ---
>>>> Tested with multiple satellite MPEG-TS inputs.
>>>>
>>>>   fftools/ffmpeg.c     | 2 +-
>>>>   tests/fate/mpeg4.mak | 2 +-
>>>>   2 files changed, 2 insertions(+), 2 deletions(-)
>>> breaks:
>>> ./ffmpeg -i 'concat:angels.mpg|angels.mpg'  -vsync 0  file.avi
>>>
>>> ...
>>> frame=   24 fps=0.0 q=12.5 Lsize=     215kB time=00:00:07.50 bitrate= 234.7kbits/s speed=75.5x
>>> video:84kB audio:110kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 10.697786%
>>>
>>> vs.
>>>
>>> ...
>>> [avi @ 0x5601caccc180] Non-monotonous DTS in output stream 0:1; previous: 219, current: 86; changing to 220. This may result in incorrect timestamps in the output file.
>>> [avi @ 0x5601caccc180] Non-monotonous DTS in output stream 0:1; previous: 220, current: 87; changing to 221. This may result in incorrect timestamps in the output file.
>>> [avi @ 0x5601caccc180] Non-monotonous DTS in output stream 0:1; previous: 221, current: 88; changing to 222. This may result in incorrect timestamps in the output file.
>>> [avi @ 0x5601caccc180] Non-monotonous DTS in output stream 0:1; previous: 222, current: 89; changing to 223. This may result in incorrect timestamps in the output file.
>>> [avi @ 0x5601caccc180] Non-monotonous DTS in output stream 0:1; previous: 223, current: 90; changing to 224. This may result in incorrect timestamps in the output file.
>>> [avi @ 0x5601caccc180] Non-monotonous DTS in output stream 0:1; previous: 224, current: 91; changing to 225. This may result in incorrect timestamps in the output file.
>>> [mpeg4 @ 0x5601cac87540] Invalid pts (72) <= last (83)
>>> Video encoding failed
>> Yes, if the input includes a mid-stream dts reset of gap less than the
>> default value of dts_delta_threshold then timestamps won't be made
>> continuous. Default value is 10 seconds but till now it wasn't enforced for
>> negative jumps, so your command worked. With this change, user will have to
>> set it manually if they expect smaller jumps.
> Negative jumps should always be a discontinuity more or less.
> What are you trying to fix exactly ?
>
> is this about bitstream errors in the timestamps ?

Yes. This is when there's a backward jump in one of the streams due to 
corruption in the input and that leads to a new ts_offset. This new 
offset when applied to other streams with error-free timestamps leads to 
async as well as muxing errors due to (now) increased interval in the 
muxing queue. dts_delta_threshold (in combination with filtering) should 
allow to prevent these offset adjustments at the cost of filtering out 
or adjusting a few packets, but the existing check prevents that by 
making    'delta < -1LL*dts_delta_threshold*AV_TIME_BASE'    irrelevant  
. With this patch, the user can set a threshold and avoid unwanted 
offset adjustments due to negative jumps.

Gyan