[FFmpeg-user] Matroska (.mkv) time resolution [was: Re: How can I force a 360kHz time base? ]

[list+ffmpeg-user at jdlh.com]

On 2021-02-26 23:20, Mark Filipak (ffmpeg) wrote:
> On 2021-02-27 01:37, Jim DeLaHunt wrote:
>> On 2021-02-26 22:08, Mark Filipak (ffmpeg) wrote:
>>> On 2021-02-27 00:55, Jim DeLaHunt wrote:
>>>> On 2021-02-26 18:36, Mark Filipak (ffmpeg) wrote:
>>>>> That's exactly the point. It is not constant because ffmpeg 
>>>>> calculates frame times in integer milliseconds, and thereby 
>>>>> truncates or rounds.…
>>>>
>>>> Mark, what makes you so sure that it is FFmpeg which is truncating 
>>>> or rounding?
>>>
>>> The issue, Jim, is not with the MKV above. The issue is with the 
>>> next video in the work flow: An MKV that was made from the MKV above 
>>> but with '-vf settb=expr=1/360000,showinfo'. That 'showinfo' should 
>>> have shown a 360000Hz time base. It does, but the PTSs are wrong.
>>
>> Well, you are spinning up multiple issues, Mark.
>
> It's all aspects of one issue, Jim.
>
>> Issue 1. Your contention that "ffmpeg calculates frame times in 
>> integer milliseconds". This branch of the thread is about that claim 
>> of yours.
>
> Not quite. When I explicitly set TB to 1/360000 via 
> 'settb=expr=1/360000', the resulting PTSs are wrong.

What FFmpeg does with the file `input1.mkv` when you apply the filter 
'settb=expr=1/360000' is Issue 2. This is the part of the message for 
Issue 1. Issue 1 is your contention that "ffmpeg calculates frame times 
in integer milliseconds". Answer: No.


>> Answer: No, FFmpeg calculates frame times exactly. You authored the 
>> input file to millisecond time resolution because that's what the 
>> format you chose encourages.
>
> I did not author to millisecond resolution. The encoder did that. 

You used some tool to author `input1.mkv`. That tool authored to 
millisecond resolution (so the evidence indicates). I won't quibble 
about wheter it was you or the too that authored. The point is, that 
file existed, and had millisecond resolution, before the FFmpeg 
experiment you ran.


> But that doesn't really matter, does it? If I take *any* video and 
> 'settb=expr=1/360000', then the source's TB should be ignored, 
> shouldn't it?

What FFmpeg does with the file `input1.mkv` when you apply the filter 
'settb=expr=1/360000' is Issue 2.


>> Issue 2. Given an input file `input1.mkv`, which has varying frame 
>> times in millisecond resolution which add up to 1001 ms per 30 
>> frames, when you apply the FFmpeg `settb` filter, why are the output 
>> Presentation Timestamp (PTS) values 11880, 24120, 36000, … instead of 
>> 12012, 24024, 36036, …?
>> Answer: Because the input frame presentation times are 11,880/360,000 
>> = 0.03300, 24,120/360,000 = 0.06700, 36,000/360,000 = 0.10000, … 
>> which exactly matches the frame times of the input video, with a 
>> 360kHz time base.
>
> The PTSs should be 12012, 24024, 36036 because 
> 1001/30000*360000=12012, 12012+12012=24024, and 24024_12012=36036.

No, the PTSs and timebase which FFmpeg issues as a result of 
'settb=expr=1/360000' should be computed from the frame times and time 
base of the input video.  The input video had frame times at millisecond 
resolution (so the evidence indicates).

Perhaps you wish that the FFmpeg `settb` filter would adjust frame times 
from the input video's varying, millisecond-resolution times to a 
constant 1.001/30 second frame time. The `settb` filter doesn't do that. 
It changes time base, preserves frame times, and changes PTS values to 
reproduce the input frame times using the new time base. This is a 
useful behaviour, and it is proper that `settb`.

Perhaps what you actually want is a different filter, one which takes an 
input video with varying frame times in millisecond resolution, and 
changes the frame times to exactly 1.001/30 seconds between frames. That 
is different than forcing a 360kHz time base. That is adjusting frame 
times from varying to constant. Hint: the `fps` filter does something 
close to what you want, but you may find it repeats some frames and 
drops others in a way you don't like. Try it, and see.

> showinfo reports 11880, 24120, 36000 because that's what ffmpeg has 
> calculated based on rounded ms (milliseconds).

No, showinfo reports 11880, 24120, 36000 because that's what the input 
video's frame times are. The input video does not have constant frame 
time increments (so the evidence indicates).

> Of course, (33ms/tick)*(360000ticks/s)=11880. That doesn't make it 
> right. It's not 12012 because 33.3[6..]ms has been rounded down to 33ms.

No, the reason it's not 12012 because the authoring tool rounded the 
frame time of 33.3[6..]ms hdown to 33.00ms.

> Imagine frame 1 of 4 videos: [elided]

I don't think these imaginary videos explain anything. They are just 
entrenching your misunderstanding.


> FFmpeg is taking the fps, turning it into rounded ms, then turning the 
> rounded ms into PTSs. That's not right. It should take the fps, turn 
> that into exact PTSs, and then turn exact PTSs into approx ms -- 
> actually, ms is superfluous because codecs key into PTSs.

No, the encoding tool which generates the input1.mkv file is what is 
taking the fps, turning it into rounded ms, then turning the rounded ms 
into PTSs. Yes, that's not what you want. Your choice of the Matroska 
container, and your acceptance of the default TimestampScale value of 
1,000,000 for that encoding, appears to be the proximate cause of your 
dissatisfaction.


>> Issue 3. What integer size does FFmpeg use to store PTS values? You 
>> initiated this thread with that question, remember?
>
> I know that MPEG PTS is 33 bits. I don't know for sure what ffmpeg does…

Well, you did ask the question of integer size at the start of the 
thread. Sometimes, when you ask a question you don't really want the 
answer to, you get the answer anyway.

> …except that it doesn't set PTSs properly. 
How FFmpeg sets PTSs, and whether it is proper or improper, is Issue 2. 
See above. Answer: FFmpeg is computing correctly as you are asking it 
to. Your input video does not have the constant frame rate which you want.

Best regards,

       —Jim DeLaHunt