[FFmpeg-devel] [PATCH] fftools/ffmpeg: Disable copy_ts on timestamp wraparound

[Gyan Doshi]

On 05-04-2020 01:51 am, Michael Niedermayer wrote:
> On Fri, May 03, 2019 at 05:36:07PM +0200, Michael Niedermayer wrote:
>> This allows handling more than 26.5h of mpeg* input
>>
>> Fixes: Ticket 7876
>>
>> Signed-off-by: Michael Niedermayer<michael at niedermayer.cc>
>> ---
>>   fftools/ffmpeg.c | 13 ++++++++++++-
>>   1 file changed, 12 insertions(+), 1 deletion(-)
> will apply

With this, I'm seeing a new offset of max pts being applied to live 
MPEG-TS inputs received over satellite at time of rollover when -copyts 
-start_st_zero is set.

Here is a small snippet as seen in select/aselect filters:

----
[Parsed_select_1 @ 0x55785c522180] n:2857374.000000 
pts:8584574799.000000 t:95384.164433 key:0 interlace_type:B pict_type:B 
scene:nan -> select:1.000000 select_out:0
[Parsed_select_1 @ 0x55785c522180] n:2857375.000000 
pts:8584577802.000000 t:95384.197800 key:0 interlace_type:B pict_type:B 
scene:nan -> select:1.000000 select_out:0
[Parsed_select_1 @ 0x55785c522180] n:2857376.000000 
pts:17174515397.000000 t:190827.948856 key:0 interlace_type:B 
pict_type:P scene:nan -> select:0.000000 select_out:-1
[Parsed_select_1 @ 0x55785c522180] n:2857377.000000 
pts:17174518400.000000 t:190827.982222 key:0 interlace_type:B 
pict_type:B scene:nan -> select:1.000000 select_out:0
----

and

----
[Parsed_aselect_0 @ 0x55785c492340] n:3973138.000000 
pts:4578410637.000000 t:95383.554937 key:1 samples_n:1152 
consumed_samples_n:nan -> select:1.000000 select_out:0
[Parsed_aselect_0 @ 0x55785c492340] n:3973139.000000 
pts:4578411789.000000 t:95383.578938 key:1 samples_n:1152 
consumed_samples_n:nan -> select:1.000000 select_out:0
[Parsed_aselect_0 @ 0x55785c492340] n:3973140.000000 
pts:9159711390.000000 t:190827.320625 key:1 samples_n:1152 
consumed_samples_n:nan -> select:0.000000 select_out:-1
[Parsed_aselect_0 @ 0x55785c492340] n:3973141.000000 
pts:9159712542.000000 t:190827.344625 key:1 samples_n:1152 
consumed_samples_n:nan -> select:1.000000 select_out:0
----

I suspect this is due to

         if (FFABS(wrap_dts - ist->next_dts) < FFABS(pkt_dts - 
ist->next_dts)/10)
             disable_discontinuity_correction = 0;

as right around the jump, I see

timestamp discontinuity for stream #0:7 (id=131, type=video): 
-95443717689, new offset= 13093624133

and

timestamp discontinuity for stream #0:10 (id=147, type=audio): 
-95443717689, new offset= 108537341822

but I'll need time to check this. Can you investigate?

Thanks,
Gyan