[FFmpeg-user] Why are PTS values different from what's expected?

[Mark Filipak (ffmpeg)]

On 2021-04-01 07:13, Mark Filipak (ffmpeg) wrote:
> The source is MKV. MKV has a 1/1000 TB, so any PTS variance should be less than 0.1%.
> 
> The filter complex is thinned down to just this: settb=1/720000,showinfo
> 
> Here is selected lines from the showinfo report (with   ...comments):
> 
> [Parsed_showinfo_1 @ 00000247d719ef00] config in time_base: 1/720000, frame_rate: 24000/1001
>     ...So, deltaPTS (calculated: 1/TB/FR) should be 30030.
> [Parsed_showinfo_1 @ 00000247d719ef00] n:   1 pts:  30240   ...should be 30030
> [Parsed_showinfo_1 @ 00000247d719ef00] n:   2 pts:  59760   ...should be 60060
> [Parsed_showinfo_1 @ 00000247d719ef00] n:   3 pts:  90000   ...should be 90090
> [Parsed_showinfo_1 @ 00000247d719ef00] n:   4 pts: 120240   ...should be 120120
> 
> The PTS variance is 0.7%.
> 
> Why are PTS values different from what's expected?
> 
> Note: If I force deltaPTS via setpts=N*30030, then of course I get what's expected.
> 
> Thanks. This is critical and your explanation is greatly appreciated!
> Mark.

UPDATE

If I change the filter complex to this:

settb=1/720000,setpts=N*30030,fps=fps=48000/1001,showinfo

all my follow-on processing goes straight into the toilet.

Explanation of the factors in the filter complex:
settb=1/720000   ...mandate 1.3[8..] ms time resolution
setpts=N*30030   ...force the input to exactly 24000/1001fps cfr
fps=fps=48000/1001   ...frame double

However, fps=fps=48000/1001 does more than just frame double. It resets TB to 20.8541[6..] ms time 
resolution. Look:

[Parsed_showinfo_3 @ 000001413bf0ef00] config in time_base: 1001/48000, frame_rate: 48000/1001
[Parsed_showinfo_3 @ 000001413bf0ef00] n:   0 pts:      0
[Parsed_showinfo_3 @ 000001413bf0ef00] n:   1 pts:      1
[Parsed_showinfo_3 @ 000001413bf0ef00] n:   2 pts:      2
[Parsed_showinfo_3 @ 000001413bf0ef00] n:   3 pts:      3

Gee, I wish the fps filter documention said that it changes TB and sets deltaPTS to '1'.

My follow-on frame processing can't tolerate 20.8541[6..] ms time resolution -- that explains why my 
mechanical frame gynmastics have been failing!

Explanation: My follow-on processing does fractional frame adjustment that requires at least 
8.341[6..] ms resolution.

Workaround: I can frame double by another method that's somewhat ugly but that I know works and 
doesn't trash time resolution.