[FFmpeg-user] How can I force a 360kHz time base?

[Mark Filipak (ffmpeg)]

On 2021-02-26 20:32, Jim DeLaHunt wrote:
> On 2021-02-26 16:53, Mark Filipak (ffmpeg) wrote:
> 
>> …What I'm suggesting is that ffmpeg convert to a single, 360000Hz time base for all videos, for 
>> all time. Then, rounding errors would be *zero*. PTSs would be exact. …
> 
> 
> As I told you back on 23. February, ffmpeg uses a timebase that is a rational number, and is an 
> attribute of the video stream, and can take various values. The timebase could be 1/360000, or 1/24, 
> or 1001/24000. This already allows integer Presentation TImestamp (PTS) values to represent time 
> values with zero rounding errors. You dismissed that as "The Matrix", but this is in fact the data 
> structure which FFmpeg already uses.

Yes, an encoded video can have any time base, as you point out. The encoder will make that time base 
whatever is required by the stream (example: MPEG-2 expects 90000Hz). That is not the time base I'm 
addressing. I'm concerned with the internal time base in the filter pipeline that's used to resolve 
frame ordering, both video and audio.

> Of course, to achieve zero rounding errors, the input video, and the user writing the FFmpeg command 
> line, and FFmpeg itself, must all make wise choices so that the timebase is set to a rational number 
> which suits the data.

All time bases that are not whole multiples of the frame rate will result in PTS rounding. 
Currently, the ffmpeg internal time base appears to be 1kHz. So, every frame rate that, when divided 
into 1000, doesn't produce a whole number will result in rounded (or truncated) PTSs.

> I don't think it is wise for FFmpeg to switch from its present flexible data structure to a 
> constant, 1/360000 value for timebase. The examples you present do not make the case for such a change.

It doesn't have to be constant. It doesn't have to be 360000Hz. What I'm suggesting is that if it 
*is* 360000Hz, that would make a single time base that works for everything. I'm not suggesting that 
it be non-modifiable.

I hoped that setting 'settb=expr=1/360000' would produce what I want, but it didn't because ffmpeg's 
inherent 1 millisecond time base resolution superseded it. No matter what 'settb' is specified, the 
PTS resolution is going to be 1 millisecond.

> If you can establish that FFmpeg is imposing a 1/1000 timebase on a video with a 1001/24000 
> timebase, leading to rounding errors, that is evidence of a bug in FFmpeg's timebase calculation or 
> something. It is not evidence of the timebase data structure being inadequate.

Technically, it's not a bug. It's a design flaw. The current ffmpeg operates as designed. It's the 
design that's flawed.