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

[Gyan Doshi]

On 15-04-2020 10:39 pm, Michael Niedermayer wrote:
> On Wed, Apr 15, 2020 at 05:29:06PM +0530, Gyan Doshi wrote:
>>
>> 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.
> iam still not sure we talk about the same thing
> if there is corruption in the timestamp field then on average
> the timestamp delta will be large and a threshold will not work
> in seperating that reliably from discontinuities.
>
> to detect / filter such issues looking at more than just the next
> timestamp would be needed
> as in
> 5,6,7,79861 you dont know if this is
> 5,6,7,79861,79862,79863
> or
> 5,6,7,79861,9,10,
> without seeing the next values

Right. So I'm talking about scenarios where the user *knows* that the 
input is supposed to be

85006,85007,85008,85009,...95443,0,1,2,3,4,5...

but is received as

85006,85007,24104,85009...95443,0,1,2,14131,4,5...

Without this patch, user can set a threshold to ignore 2,14131 but not 85007,24104.

Gyan