Body: <p>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 :</p>
  <p><strong>original y4m :</strong></p>
  <p>29.97 fps, tbc : 29.97 tbr 29.97 <strong>tbn : 29.97</strong></p>
  <p><strong>H265 converted file :</strong></p>
  <p>29.97 fps, tbc : 29.97 tbr 29.97 <strong>tbn : 1k</strong></p>
  <p>I noticed the problem when I tried to compare the two videos with metrics like VMAF or SSIM, it says that the timestamp are 30000/1001 in one case and an other thing in the other case and the metric result is clearly false.</p>
  <p>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 ...</p>
  <p>My main question :
  <strong>This is, here a simple conversion with default parameter, why this default parameter is used in this case ?</strong></p>
  <p>Subsidiary questions :</p>
  <ul>
  <li><p>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 ?</p>
  </li>
  <li><p>Why in the y4m, the tbn is simply the FPS (29,97) what does it means ?</p>
  </li>
  </ul>
  <p>Thanks you ;)</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2023-01-23T15:59:16.283Z
Comments.Text: Share your full command.
Comments.UserDisplayName: Gyan
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2023-07-20T12:49:40.263Z
Comments.Text: I have found an answer on this in SuperUser :
  https://superuser.com/questions/1764716/why-in-ffmpeg-with-libx265-the-timestamp-tbn-parameter-is-always-1k-even-when-i/1764722?noredirect=1#comment2747058_1764722
Comments.UserDisplayName: Nils Beaussé
Tags: <ffmpeg><encoding><h265>
Title: Why, in FFmpeg with libx265 the timestamp tbn parameter is always 1k even when it seems not logical?
UserDisplayName: Nils Beaussé
ThreadText: # Why, in FFmpeg with libx265 the timestamp tbn parameter is always 1k even when it seems not logical?
  
  (Asked by: username_0 on 2023-01-23)
  
  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 timestamp are 30000/1001 in one case and an other thing in the other case and the metric result is clearly false.
  
  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 parameter, 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 means ?
  
  Thanks you ;)
  
  **Tags:** ffmpeg, encoding, h265
  
  > **Comments:**
  > **username_1**: Share your full command.  
  > **username_0**: I have found an answer on this in SuperUser : https://superuser.com/questions/1764716/why-in-ffmpeg-with-libx265-the-timestamp-tbn-parameter-is-always-1k-even-when-i/1764722?noredirect=1#comment2747058_1764722  
  
  ---
  
  ## 0 answers
  
  