Answers.Body: <p>MKV does not store a frame rate in its container. So ffmpeg/vlc looks at the default duration of a frame instead. It sees 33.333ms and does the math, which is where your weird number comes from. </p>
  
  <p>For more information, see: <a href="https://gitlab.com/mbunkus/mkvtoolnix/wikis/Wrong-frame-rate-displayed" rel="nofollow noreferrer">https://gitlab.com/mbunkus/mkvtoolnix/wikis/Wrong-frame-rate-displayed</a></p>
  
  <p>To test this out, you can run <code>ffprobe</code> with <code>-show_frames</code>. I think you'll find the presentation times for each frame are spot on.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2016-05-13T07:22:31.620Z
Answers.LastActivityDate: 2019-04-07T18:15:36.843Z
Answers.LastEditDate: 2019-04-07T18:15:36.843Z
Answers.UserDisplayName: Michael Steinberg
Body: <p>If the Matroska format is used, in certain framerates it doesn't record at exact input framerate, but rather at a little higher than the input framerate.</p>
  
  <p>As an example:</p>
  
  <pre><code>ffmpeg -video_size 1920x1080 -f x11grab -framerate 30 -i :0.0 -c:v libx264rgb -crf 0 -preset ultrafast video.mkv
  </code></pre>
  
  <p>doesn't generate a recording at 30fps, but rather at 30.0003fps.</p>
  
  <p>This is not good, because even a slight change in input framerate can cause major frame stutter. Unless ffmpeg is speeding up the stream by 1.00001x, which I don't think so when using x11grab.</p>
  
  <p>To prove this, VLC can be used for checking the frame rate.</p>
  
  <p>Is there any way to force exactly 30fps, or is this a format flaw?</p>
  
  <p>Also, <code>uname -a</code>:</p>
  
  <pre><code>Linux linux 4.1.15-rt17-1-rt-fixedtimers #1 SMP PREEMPT RT Sat Jan 16 01:14:52 GMT+5 2016 x86_64 GNU/Linux
  </code></pre>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-05-12T00:12:57.230Z
Comments.Text: How does "major frame stutter" manifest itself? I can imagine sync issues but I can't quite picture how anything major could come from a 1 part per 10000 rate error.
Comments.UserDisplayName: Jim Mack
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-05-12T16:38:02.987Z
Comments.Text: Please show the complete console output from your `ffmpeg` command.
Comments.UserDisplayName: llogan
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-05-13T00:53:20.853Z
Comments.Text: I just noticed this only happens on .mkv format. I'm updating information about this. Here's the paste: http://pastebin.com/yUbn1zrL
Comments.UserDisplayName: tildearrow
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-05-13T07:08:54.623Z
Comments.Text: For recording to MKV, insert `-vsync 0`. Whatever rate the source supplies, MKV will encode the same timings.
Comments.UserDisplayName: Gyan
Tags: <ffmpeg><framerate><screen-casting><matroska>
Title: Matroska format's framerate is not accurate with certain values
UserDisplayName: tildearrow
ThreadText: # Matroska format's framerate is not accurate with certain values
  
  (Asked by: username_0 on 2016-05-11)
  
  If the Matroska format is used, in certain framerates it doesn't record at exact input framerate, but rather at a little higher than the input framerate.
  
  As an example:
  
  ```
  ffmpeg -video_size 1920x1080 -f x11grab -framerate 30 -i :0.0 -c:v libx264rgb -crf 0 -preset ultrafast video.mkv
  
  ```
  
  doesn't generate a recording at 30fps, but rather at 30.0003fps.
  
  This is not good, because even a slight change in input framerate can cause major frame stutter. Unless ffmpeg is speeding up the stream by 1.00001x, which I don't think so when using x11grab.
  
  To prove this, VLC can be used for checking the frame rate.
  
  Is there any way to force exactly 30fps, or is this a format flaw?
  
  Also, `uname -a`:
  
  ```
  Linux linux 4.1.15-rt17-1-rt-fixedtimers #1 SMP PREEMPT RT Sat Jan 16 01:14:52 GMT+5 2016 x86_64 GNU/Linux
  
  ```
  
  **Tags:** ffmpeg, framerate, screen-casting, matroska
  
  > **Comments:**
  > **username_1**: How does "major frame stutter" manifest itself? I can imagine sync issues but I can't quite picture how anything major could come from a 1 part per 10000 rate error.  
  > **username_2**: Please show the complete console output from your `ffmpeg` command.  
  > **username_0**: I just noticed this only happens on .mkv format. I'm updating information about this. Here's the paste: http://pastebin.com/yUbn1zrL  
  > **username_3**: For recording to MKV, insert `-vsync 0`. Whatever rate the source supplies, MKV will encode the same timings.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_4 on 2016-05-13. Score: 4
  
  MKV does not store a frame rate in its container. So ffmpeg/vlc looks at the default duration of a frame instead. It sees 33.333ms and does the math, which is where your weird number comes from.
  
  For more information, see: <https://gitlab.com/mbunkus/mkvtoolnix/wikis/Wrong-frame-rate-displayed>
  
  To test this out, you can run `ffprobe` with `-show_frames`. I think you'll find the presentation times for each frame are spot on.
  
  
  ---
  
  