0

I encode with ffmpeg and noticed that when I encode a y4m video in 29,97 FPS into a h265 video with libx265, the parameter of the two videos are the following :

original y4m :

29.97 fps, tbc : 29.97 tbr 29.97 **tbn : 29.97**

H265 converted file :

29.97 fps, tbc : 29.97 tbr 29.97 **tbn : 1k**

I noticed the problem when I tried to compare the two videos with metrics like VMAF or SSIM, it says that the timestamps are 30000/1001 in one case and another thing in the other case and the metric result is clearly false.

The exact message when I call with SSIM : "not matching timebases found between first input: 100/2997 and second input 1001/30000, results may be incorrect!"

Where first input is the H265 and second input the y4m.

As far as I understand, tbn mean the internal time interval used by the codec to place the images and it should be a number that can help to get the FPS easily, but I don't see how 1k will help in any way to place images at precise 29.97FPS (30000/1001). Or I miss something ? On the net it seems that classical number is more or less things like 90k, which seem more logical.

My main question : This is, here a simple conversion with default parameters, why this default parameter is used in this case ?

Subsidiary questions :

  • I guess it is possible to force the tbn to another factor during conversion, but is it costless or have this an impact on the quality or size of the compressed video ?

  • Why in the y4m, the tbn is simply the FPS (29,97) what does it mean ?

Giacomo1968
  • 53,069
  • 19
  • 162
  • 212
Nils Beaussé
  • 1

1 Answers1

0

Ok, I found one element of an answer after some digging. The main thing here is that i convert to MKV as containers !

And in some commentaries on the internet I learn that MKV seems to have a timebase fixed to 1k, and this is all ...

I don't understand why it is the case and I don't see it in the real specs. If someone have more info on it ...

In all cases, ffmpeg seem to respect this convention and in their code there is a commentary that say ("1k is the de facto convention for mkv")...

Nils Beaussé
  • 1
  • I had similar issues with movenc, as ffmpeg was hard coding a timescale of 1000. In the case of that codec, an option was added to allow setting the timescale manually. https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/c75dfa043585db7f5e20f5cab2ca8be1771ca7b6 – mwjb Jan 29 '23 at 11:43
  • Yes, i have see this one. But for MKV it's definitively a MKV specification issue. I have discussed of that with the matroska guys and they said it is a thing they need to change in the spec but it is technically not so simple. – Nils Beaussé Jan 30 '23 at 15:17