Answers.Body: <p>I ran into this same stuttering after remuxing to mkv and then playing the video on a Roku.  Solved the issue by first fixing the avi with the mpeg4_unpack_bframes filter, then remuxing that as mkv.</p>
  <p>See <a href="https://www.ffmpeg.org/ffmpeg-bitstream-filters.html#mpeg4_005funpack_005fbframes" rel="noreferrer">https://www.ffmpeg.org/ffmpeg-bitstream-filters.html#mpeg4_005funpack_005fbframes</a></p>
  <p>Posting here as this is the top Search result when searching &quot;avi to mkv stutter&quot;.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-06-17T00:50:12.150Z
Answers.Text: ffmpeg says that this BSF only works on mpeg4, not h264, so it's a valid answer but not if the input video is h264.
Answers.UserDisplayName: Jody Bruchon
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-02-26T02:53:53.160Z
Answers.LastActivityDate: 2021-02-26T02:53:53.160Z
Answers.UserDisplayName: Michael Ratliff
Answers.Body: <p>As of the date of your post, this was already a reported <a href="https://bugs.chromium.org/p/chromium/issues/detail?id=337606" rel="nofollow noreferrer">bug.</a> You stated that you had this problem both in Windows and Ubuntu. For Windows at least there was a <a href="https://bugs.chromium.org/p/chromium/issues/detail?id=337606#c33" rel="nofollow noreferrer">reported workaround:</a></p>
  
  <p><strong>For Chrome:</strong> Navigate to chrome://flags</p>
  
  <p>Enable "Enable D3D11 Windows"</p>
  
  <p>Chromium uses switches instead. It appears that the corresponding switch for Chromium is <code>-d3d11</code>See: <a href="https://peter.sh/experiments/chromium-command-line-switches/" rel="nofollow noreferrer">https://peter.sh/experiments/chromium-command-line-switches/</a> for more switches to modify Chromium`s behavior. Perhaps these will help you reach a solution that you are happy with. Since other players and browsers are capable of playing the same file smoothly, it doesn't seem logical (at least to me) to blame the encoding.</p>
  
  <p>This is likely no longer necessary as the aforementioned bug was reported Fixed and closed Oct 2015 (at least on Windows)</p>
  
  <p>EDIT: Since Firefox and totem use gstreamer plugins, it would appear that you may be able to resolve this issue by adding a gstreamer backend to chromium. It appears that this approach was first <a href="https://blogs.s-osg.org/announcing-a-new-gstreamer-backend-for-chromium/" rel="nofollow noreferrer">announced by the Samsung Open Source Group</a> July 6, 2015 and that there is a github project <a href="https://github.com/Samsung/ChromiumGStreamerBackend" rel="nofollow noreferrer">here.</a>/ChromiumGStreamerBackend) Further information and details on how to implement this approach can be found <a href="https://github.com/Samsung/ChromiumGStreamerBackend/blob/master/README.md" rel="nofollow noreferrer">here.</a></p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-10-04T11:42:26.220Z
Answers.Text: Thanks for the sleuthing - but that flag is not available (at least in Ubuntu chromium). I'd suspect a bug fixed and closed in 2015 is not the culprit.
Answers.UserDisplayName: Trees4theForest
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-10-04T12:01:54.003Z
Answers.Text: @Trees4theForest As of the first edit in your question it's clear that this problem occurred in Chrome as well. If not a bug in the browsers mentioned, Where do you think the problem lies if not with the player. I hope you don't mind me quoting you. "The file plays smooth in firefox, and also in the desktop viewer (Totem)"
Answers.UserDisplayName: Elder Geek
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-10-04T13:39:41.377Z
Answers.Text: I agree it's an issue with the browser. I was not aware of the command-line flags (thanks for the list) but unfortunately d3d11 is not the culprit. (I also tried a variety of GPU / video flags, none of which helped).
Answers.UserDisplayName: Trees4theForest
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-10-03T22:24:12.883Z
Answers.LastActivityDate: 2017-10-06T19:59:42.053Z
Answers.LastEditDate: 2017-10-06T19:59:42.053Z
Answers.UserDisplayName: Elder Geek
Body: <p>I have <code>file.avi</code> which contains a h264 video:</p>
  
  <pre><code>$ ffmpeg -i file.AVI
  Input #0, avi, from 'file.AVI':
    Duration: 00:00:20.61, start: 0.000000, bitrate: 1530 kb/s
      Stream #0:0: Video: h264 (Main) (H264 / 0x34363248), yuv420p, 640x480, 1459 kb/s, 18 fps, 18 tbr, 18 tbn, 36 tbc
      Stream #0:1: Audio: mp2 (P[0][0][0] / 0x0050), 44100 Hz, stereo, s16p, 64 kb/s
  </code></pre>
  
  <p>When I convert to a mp4 container using:</p>
  
  <pre><code>ffmpeg -i file.AVI -vcodec copy -acodec copy test.mp4
  </code></pre>
  
  <p>This produces the following file:</p>
  
  <pre><code>Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'test.mp4':
    Metadata:
      major_brand     : isom
      minor_version   : 512
      compatible_brands: isomiso2avc1mp41
      encoder         : Lavf56.40.101
    Duration: 00:00:20.72, start: 0.000000, bitrate: 1515 kb/s
      Stream #0:0(und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p, 640x480, 1455 kb/s, 18 fps, 18 tbr, 18432 tbn, 36864 tbc (default)
      Metadata:
        handler_name    : VideoHandler
      Stream #0:1(und): Audio: mp3 (mp4a / 0x6134706D), 44100 Hz, stereo, s16p, 64 kb/s (default)
      Metadata:
        handler_name    : SoundHandler
  </code></pre>
  
  <p>The output mp4 file plays in chromium using html5  but is choppy / stutters as it plays. </p>
  
  <p>The file plays smooth in firefox, and also in the desktop viewer (Totem), but I need it to play smooth in chromium.</p>
  
  <p>Are there any ffmpeg flags I need to set to achieve this, or is it something inherently wrong with Chromium?</p>
  
  <p>Note: if I re-encode the file with <code>ffmpeg -i file.AVI test2.mp4</code> the result works fine in Chromium, but I can't do this (for speed) I'd like to just re-package the h264 video... which <em>almost</em> works.</p>
  
  <p><strong>EDIT:</strong> The choppy playback occurs on both Linux (Ubuntu) and Windows and in both Chrome and Chromium.</p>
  
  <p><strong>EDIT 2:</strong> Full output from command (note, using flag <code>-an</code> to remove the possibility it's an audio issue.)</p>
  
  <pre><code>Input #0, avi, from 'file.AVI':
    Duration: 00:00:20.61, start: 0.000000, bitrate: 1530 kb/s
      Stream #0:0: Video: h264 (Main) (H264 / 0x34363248), yuv420p, 640x480, 1459 kb/s, 18 fps, 18 tbr, 18 tbn, 36 tbc
      Stream #0:1: Audio: mp2 (P[0][0][0] / 0x0050), 44100 Hz, stereo, s16p, 64 kb/s
  [mp4 @ 0x1734d80] Codec for stream 0 does not use global headers but container format requires global headers
  Output #0, mp4, to 'test.mp4':
    Metadata:
      encoder         : Lavf56.40.101
      Stream #0:0: Video: h264 ([33][0][0][0] / 0x0021), yuv420p, 640x480, q=2-31, 1459 kb/s, 18 fps, 18 tbr, 18432 tbn, 18 tbc
  Stream mapping:
    Stream #0:0 -&gt; #0:0 (copy)
  Press [q] to stop, [?] for help
  [mp4 @ 0x1734d80] pts has no value
      Last message repeated 370 times
  frame=  371 fps=0.0 q=-1.0 Lsize=    3664kB time=00:00:20.61 bitrate=1456.2kbits/s    
  video:3661kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.066175%
  </code></pre>
  
  <p>Notes: </p>
  
  <ul>
  <li>Adding <code>-fflags +genpts</code> removes the <code>[mp4 @ 0x1734d80] pts has no value</code> error, but does not improve the playback.</li>
  <li>Adding <code>-flags:v +global_header</code> removes the <code>[mp4 @ 0x1734d80] Codec for stream 0 does not use global headers</code> but does not improve the playback</li>
  <li>Setting the tbc output using <code>-r ##</code> does not improve playback</li>
  <li>Setting tbn using <code>-video_track_timescale ##</code> does not improve playback</li>
  </ul>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-09-15T06:13:55.933Z
Comments.Text: Show the complete console output from the command, not just an excerpt. Also, provide a link to the input file if possible. Why does the input show mp2 audio and the output mp3?
Comments.UserDisplayName: llogan
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-09-15T11:49:38.820Z
Comments.Text: The audio is odd as I'm using `-acodec copy` I assumed it was just repackaging. I'll see if I'm allowed to share the actual file. Thanks.
Comments.UserDisplayName: Trees4theForest
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-09-15T17:05:51.787Z
Comments.Text: Can you show the **complete** console output? Do you have a link to a file so we can attempt to duplicate the issue?
Comments.UserDisplayName: llogan
Tags: <ffmpeg><avi>
Title: ffmpeg repackaging AVI (h264) into mp4 gives choppy playback in html5 video on chromium
UserDisplayName: Trees4theForest
ThreadText: # ffmpeg repackaging AVI (h264) into mp4 gives choppy playback in html5 video on chromium
  
  (Asked by: username_0 on 2017-09-14)
  
  I have `file.avi` which contains a h264 video:
  
  ```
  $ ffmpeg -i file.AVI
  Input #0, avi, from 'file.AVI':
    Duration: 00:00:20.61, start: 0.000000, bitrate: 1530 kb/s
      Stream #0:0: Video: h264 (Main) (H264 / 0x34363248), yuv420p, 640x480, 1459 kb/s, 18 fps, 18 tbr, 18 tbn, 36 tbc
      Stream #0:1: Audio: mp2 (P[0][0][0] / 0x0050), 44100 Hz, stereo, s16p, 64 kb/s
  
  ```
  
  When I convert to a mp4 container using:
  
  ```
  ffmpeg -i file.AVI -vcodec copy -acodec copy test.mp4
  
  ```
  
  This produces the following file:
  
  ```
  Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'test.mp4':
    Metadata:
      major_brand     : isom
      minor_version   : 512
      compatible_brands: isomiso2avc1mp41
      encoder         : Lavf56.40.101
    Duration: 00:00:20.72, start: 0.000000, bitrate: 1515 kb/s
      Stream #0:0(und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p, 640x480, 1455 kb/s, 18 fps, 18 tbr, 18432 tbn, 36864 tbc (default)
      Metadata:
        handler_name    : VideoHandler
      Stream #0:1(und): Audio: mp3 (mp4a / 0x6134706D), 44100 Hz, stereo, s16p, 64 kb/s (default)
      Metadata:
        handler_name    : SoundHandler
  
  ```
  
  The output mp4 file plays in chromium using html5 but is choppy / stutters as it plays.
  
  The file plays smooth in firefox, and also in the desktop viewer (Totem), but I need it to play smooth in chromium.
  
  Are there any ffmpeg flags I need to set to achieve this, or is it something inherently wrong with Chromium?
  
  Note: if I re-encode the file with `ffmpeg -i file.AVI test2.mp4` the result works fine in Chromium, but I can't do this (for speed) I'd like to just re-package the h264 video... which *almost* works.
  
  **EDIT:** The choppy playback occurs on both Linux (Ubuntu) and Windows and in both Chrome and Chromium.
  
  **EDIT 2:** Full output from command (note, using flag `-an` to remove the possibility it's an audio issue.)
  
  ```
  Input #0, avi, from 'file.AVI':
    Duration: 00:00:20.61, start: 0.000000, bitrate: 1530 kb/s
      Stream #0:0: Video: h264 (Main) (H264 / 0x34363248), yuv420p, 640x480, 1459 kb/s, 18 fps, 18 tbr, 18 tbn, 36 tbc
      Stream #0:1: Audio: mp2 (P[0][0][0] / 0x0050), 44100 Hz, stereo, s16p, 64 kb/s
  [mp4 @ 0x1734d80] Codec for stream 0 does not use global headers but container format requires global headers
  Output #0, mp4, to 'test.mp4':
    Metadata:
      encoder         : Lavf56.40.101
      Stream #0:0: Video: h264 ([33][0][0][0] / 0x0021), yuv420p, 640x480, q=2-31, 1459 kb/s, 18 fps, 18 tbr, 18432 tbn, 18 tbc
  Stream mapping:
    Stream #0:0 -> #0:0 (copy)
  Press [q] to stop, [?] for help
  [mp4 @ 0x1734d80] pts has no value
      Last message repeated 370 times
  frame=  371 fps=0.0 q=-1.0 Lsize=    3664kB time=00:00:20.61 bitrate=1456.2kbits/s    
  video:3661kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.066175%
  
  ```
  
  Notes:
  
  * Adding `-fflags +genpts` removes the `[mp4 @ 0x1734d80] pts has no value` error, but does not improve the playback.
  * Adding `-flags:v +global_header` removes the `[mp4 @ 0x1734d80] Codec for stream 0 does not use global headers` but does not improve the playback
  * Setting the tbc output using `-r ##` does not improve playback
  * Setting tbn using `-video_track_timescale ##` does not improve playback
  
  **Tags:** ffmpeg, avi
  
  > **Comments:**
  > **username_1**: Show the complete console output from the command, not just an excerpt. Also, provide a link to the input file if possible. Why does the input show mp2 audio and the output mp3?  
  > **username_0**: The audio is odd as I'm using `-acodec copy` I assumed it was just repackaging. I'll see if I'm allowed to share the actual file. Thanks.  
  > **username_1**: Can you show the **complete** console output? Do you have a link to a file so we can attempt to duplicate the issue?  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_2 on 2021-02-26. Score: 5
  
  I ran into this same stuttering after remuxing to mkv and then playing the video on a Roku. Solved the issue by first fixing the avi with the mpeg4\_unpack\_bframes filter, then remuxing that as mkv.
  
  See <https://www.ffmpeg.org/ffmpeg-bitstream-filters.html#mpeg4_005funpack_005fbframes>
  
  Posting here as this is the top Search result when searching "avi to mkv stutter".
  
  > **Comments:**
  > **username_3**: ffmpeg says that this BSF only works on mpeg4, not h264, so it's a valid answer but not if the input video is h264.  
  
  ---
  
  ### Answer by username_4 on 2017-10-03. Score: 1
  
  As of the date of your post, this was already a reported [bug.](https://bugs.chromium.org/p/chromium/issues/detail?id=337606) You stated that you had this problem both in Windows and Ubuntu. For Windows at least there was a [reported workaround:](https://bugs.chromium.org/p/chromium/issues/detail?id=337606#c33)
  
  **For Chrome:** Navigate to chrome://flags
  
  Enable "Enable D3D11 Windows"
  
  Chromium uses switches instead. It appears that the corresponding switch for Chromium is `-d3d11`See: <https://peter.sh/experiments/chromium-command-line-switches/> for more switches to modify Chromium`s behavior. Perhaps these will help you reach a solution that you are happy with. Since other players and browsers are capable of playing the same file smoothly, it doesn't seem logical (at least to me) to blame the encoding.
  
  This is likely no longer necessary as the aforementioned bug was reported Fixed and closed Oct 2015 (at least on Windows)
  
  EDIT: Since Firefox and totem use gstreamer plugins, it would appear that you may be able to resolve this issue by adding a gstreamer backend to chromium. It appears that this approach was first [announced by the Samsung Open Source Group](https://blogs.s-osg.org/announcing-a-new-gstreamer-backend-for-chromium/) July 6, 2015 and that there is a github project [here.](https://github.com/Samsung/ChromiumGStreamerBackend)/ChromiumGStreamerBackend) Further information and details on how to implement this approach can be found [here.](https://github.com/Samsung/ChromiumGStreamerBackend/blob/master/README.md)
  
  > **Comments:**
  > **username_0**: Thanks for the sleuthing - but that flag is not available (at least in Ubuntu chromium). I'd suspect a bug fixed and closed in 2015 is not the culprit.  
  > **username_4**: @username_0 As of the first edit in your question it's clear that this problem occurred in Chrome as well. If not a bug in the browsers mentioned, Where do you think the problem lies if not with the player. I hope you don't mind me quoting you. "The file plays smooth in firefox, and also in the desktop viewer (Totem)"  
  > **username_0**: I agree it's an issue with the browser. I was not aware of the command-line flags (thanks for the list) but unfortunately d3d11 is not the culprit. (I also tried a variety of GPU / video flags, none of which helped).  
  
  ---
  
  