我使用 ffmpeg 进行编码，并注意到当我使用 libx265 将 29,97 FPS 的 y4m 视频编码为 h265 视频时，这两个视频的参数如下：
原始 y4m：
29.97 fps, tbc : 29.97 tbr 29.97 **tbn : 29.97**
H265转换后的文件：
29.97 fps, tbc : 29.97 tbr 29.97 **tbn : 1k**
当我尝试将这两个视频与 VMAF 或 SSIM 等指标进行比较时，我注意到了这个问题，它说在一种情况下时间戳是 30000/1001，在另一种情况下则是另一种情况，并且度量结果显然是错误的。
当我使用 SSIM 拨打电话时收到的确切消息是： “第一个输入 100/2997 和第二个输入 1001/30000 之间发现时间基准不匹配，结果可能不正确！”
其中第一个输入是 H265，第二个输入是 y4m。
据我所知，tbn 表示编解码器放置图像所使用的内部时间间隔，它应该是一个有助于轻松获得 FPS 的数字，但我看不出 1k 如何有助于以精确的 29.97FPS（30000/1001）放置图像。或者我错过了什么？在网上，似乎经典数字或多或少是 90k 之类的东西，这似乎更合乎逻辑。
我的主要问题是：这是，这是一个带有默认参数的简单转换，为什么在这种情况下使用这个默认参数？
附属问题：
我猜想在转换过程中可以强制将 tbn 转换为另一个因素，但是这是否无成本，或者是否会对压缩视频的质量或大小产生影响？
为什么在 y4m 中，tbn 只是 FPS (29,97)，这是什么意思？
答案1
好的，经过一番挖掘，我找到了答案的一个要素。这里最重要的是我将文件转换为 MKV 作为容器！
并且在网上的一些评论中我了解到 MKV 似乎有一个固定为 1k 的时间基数，这就是全部......
我不明白为什么会这样，而且在实际规格中也没有看到。如果有人有更多信息...
在所有情况下，ffmpeg 似乎都尊重这一惯例，并且在他们的代码中有一条评论说（“1k 是 mkv 的事实上的惯例”...