[FFmpeg-user] PTS resolution[s]

[Mark Filipak (ffmpeg)]

On 2021-02-23 13:17, Rob Hallam wrote:
> On Tue, 23 Feb 2021 at 17:55, Mark Filipak (ffmpeg) <markfilipak at bog.us>
> wrote:
>> [ information on PTS ]
> 
> Interesting information, thank you for sharing those insights.
> 
> Without wanting to cast aspersions, does this mean that ffmpeg does
> something different with regards to timestamps than the MPEG spec?

Hey Rob,

Without knowing the decoder and pipeline delta-PTS resolution [1], I can't say for sure. What I can 
say is that ffmpeg reports "1k tbn". I'm unsure what 'tbn' means but others have said that it means 
"time base number" [2]. If 'tbn' is used in calculations as a surrogate for MPEG's 90KHz time base, 
then I'd say that 1ms resolution is too small to prevent errors -- it would need to be no larger 
than 0.01[1..]ms but could/should be even finer (in order to prevent accumulated error in chained 
calculations).

[1] MPEG keeps PTS as a 33-bit value. Because the MPEG time base clock runs at 90KHz (i.e. the 27MHz 
system time clock divided by 300), then the smallest possible frame-to-frame delta-PTS represents 
0.011[1..]ms in time. Real examples: Changing delta-PTS from '3003' to '3000' is a frame-to-frame 
change of 33.36[6..]ms to 33.33[3..]ms (which, as frame rates, is 30fps to 29.970fps). (Note that 
33.36[6..]ms = 33.33[3..]ms + 0.011[1..]ms + 0.011[1..]ms + 0.011[1..]ms.)

[2] The meanings of 'tbr', 'tbn', and 'tbc' were the subjects of my very first posting to 
ffmpeg-users back on 2019-09-29, subject: "Two initial questions". I got no answer then, and I've 
not gotten a precise answer since. Oh, I've since gotten vague musings, but it appears that this 
whole subject is quite murky to everyone. I accepted the situation because "those ffmpeg folks must 
be awfully experienced, so I'll just hang out until I learn more". Based on (bogus, abusive) 
reactions here and (courteous, more informed but still murky) discussions at doom9.org, well, I 
guess I've lost my patience. Sorry.

> If this is the case, is it possible to quantify the difference, at least to
> an order of magnitude?
> 
> Asking out of idle curiosity as the description of the hardware and spec
> piqued my interest.

You have just pulled the tubes out of your arms, my friend, and you are now ready to face the 
implications of "THE MATRIX".

Let me expound a little further, eh?
If 30fps produces a delta-PTS of '3000' and 29.970 produces a delta-PTS of '3003', then what does a 
delta-PTS of '3001' produce? (And is it possible? And is it valid?).
Yes, it is programmatically possible.
A delta-PTS of '3001' produces time stamps as though from a 29.99000333222259246917694101966fps video.
Will such a video play properly? Probably, but maybe not if burned to a DVD and popped into a DVD 
player. MPEG's 'frame_rate_code' metadata allows for: '24/1.001', '24', '25', '30/1.001', '30', 
'50', '60/1.001', and '60'. It doesn't allow for '30/1.0003[3..]', but a player will probably play 
30fps and ignore the PTSs (or will ignore 'frame_rate_code' and 'play' the PTSs).
Is it valid? No.
And the biggest question: If those PTSs are further manipulated in chained calculations, what will 
happen? I think errors happen. I think jitter happens. I think busted transcodes happen. I think 
out-of-sync audio happens. I think scripts that have worked for a year but that break on particular 
use cases happen.