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

[Jim DeLaHunt]

On 2021-02-26 18:36, Mark Filipak (ffmpeg) wrote:
> On 2021-02-26 20:42, Jim DeLaHunt wrote:
>> On 2021-02-26 17:24, Mark Filipak (ffmpeg) wrote:
>>
>>> 'ffmpeg -i input.mkv -vf "showinfo" -codec:a copy -codec:s copy -dn 
>>> output.mkv'
>>>
>>> [Parsed_showinfo_0 @ 0000013c877124c0] n:   1 pts:     33 
>>> pts_time:0.033   pos:    10052 fmt:yuv420p sar:32/27 s:240x236 i:P 
>>> iskey:0 type:B checksum:3CF10BFE plane_checksum:[64208370 00B13226 
>>> C5775659] mean:[25 126 131 ] stdev:[12.8 6.1 1.6 ]
>>> [Parsed_showinfo_0 @ 0000013c877124c0] n:   2 pts:     67 
>>> pts_time:0.067   pos:     9213 fmt:yuv420p sar:32/27 s:240x236 i:P 
>>> iskey:0 type:B checksum:23A8A65F plane_checksum:[90DC2AA6 37E908C8 
>>> 779972F1] mean:[27 125 132 ] stdev:[14.8 7.1 1.9 ]
>>> [Parsed_showinfo_0 @ 0000013c877124c0] n:   3 pts:    100 
>>> pts_time:0.1     pos:    11086 fmt:yuv420p sar:32/27 s:240x236 i:P 
>>> iskey:0 type:B checksum:1CDF7A80 plane_checksum:[089DE80E C537F4C0 
>>> 8C4E9D94] mean:[29 125 132 ] stdev:[15.2 6.6 2.3 ]
>>> …[elided for brevity]…
>>> [Parsed_showinfo_0 @ 0000013c877124c0] n:  28 pts:    934 
>>> pts_time:0.934   pos:    45167 fmt:yuv420p sar:32/27 s:240x236 i:P 
>>> iskey:0 type:B checksum:8D724A43 plane_checksum:[CD1CE198 DC377EA5 
>>> 3D51E9E8] mean:[70 113 148 ] stdev:[46.3 11.6 11.5 ]
>>> [Parsed_showinfo_0 @ 0000013c877124c0] n:  29 pts:    968 
>>> pts_time:0.968   pos:    40163 fmt:yuv420p sar:32/27 s:240x236 i:P 
>>> iskey:0 type:P checksum:8F6C0D42 plane_checksum:[385DA9F1 7EA37D5A 
>>> AD78E5D9] mean:[70 113 148 ] stdev:[46.6 11.6 11.5 ]
>>> [Parsed_showinfo_0 @ 0000013c877124c0] n:  30 pts:   1001 
>>> pts_time:1.001   pos:    50467 fmt:yuv420p sar:32/27 s:240x236 i:P 
>>> iskey:0 type:B checksum:B511B7BA plane_checksum:[9C9A49A0 B1D583BA 
>>> FA0EEA51] mean:[70 113 148 ] stdev:[46.5 11.4 11.6 ]
>>
>>
>> This output shows a stream which has a varying frame rate. The change 
>> in pts_time is not constant from frame to frame.
>
> 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?

Here's an alternate explanation: the tool which generated input1.mkv was 
what calculated frame times in integer milliseconds, and thereby 
truncated or rounded. That tool used millisecond time resolution, 
because that is what the Matroska format encourages. FFmpeg is 
faithfully reproducing the varying frame rates and millisecond 
resolution which input1.mkv contains.


On 2021-02-26 20:14, Gyan Doshi wrote:
> The Matroska timebase is insufficient to precisely store 29.97 fps 
> timestamps. Nothing to do with ffmpeg.

Gyan is helpful and informative, so let's dig into what Gyan said a 
little more. The extension `.mkv` indicates that file `input1.mkv` has a 
Matroska container. Take a look at the Matroska specification, section 
"TimestampScale" 
(https://www.matroska.org/technical/notes.html#timestampscale):

"The TimestampScale Element is used to calculate the Raw Timestamp of a 
Block. The timestamp is obtained by adding the Block’s timestamp to the 
Cluster’s Timestamp Element, and then multiplying that result by the 
TimestampScale. The result will be the Block’s Raw Timestamp in 
nanoseconds.… the default value of TimestampScale is 1000000."

The Matroska format stores timestamps as integers. Those integers are 
multiplied by the integer TimestampScale value to get times in 
nanoseconds. The default value of TimestampScale is 1000000. So the 
default resolution of timestamps in MKV containers is 1,000,000 
nanoseconds, or 1 millisecond.

So, Mark, unless your test file `input1.mkv` was specially crafted, it 
will have a time resolution of 1 ms. The truncation or rounding would 
happen as that file was authored.

And, if you want to prove your assertion that it is FFmpeg which is 
truncating or rounding, I suggest you follow Carl's good advice:

On 2021-02-26 19:53, Carl Zwanzig wrote:
> Instead of using unknown data*, I suggest making your own test video 
> so you're absolutely sure of all the parameters.… I'd also consider 
> different containers.
>
> There may also be some test files you can download that can be trusted.
>
> *Unless _known_ to be fully compliant and well-formed, it's not 
> precision test data; get as close to a primary standard as possible. I 
> would not trust an extract from a generic dvd until verified as correct. 


Best regards,

      —Jim DeLaHunt