<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>

CC BY-SA 4.0
2021-06-17T00:50:12.150Z
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.
Jody Bruchon
CC BY-SA 4.0
2021-02-26T02:53:53.160Z
2021-02-26T02:53:53.160Z
Michael Ratliff
<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>

CC BY-SA 3.0
2017-10-04T11:42:26.220Z
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.
Trees4theForest
CC BY-SA 3.0
2017-10-04T12:01:54.003Z
@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)"
Elder Geek
CC BY-SA 3.0
2017-10-04T13:39:41.377Z
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).
Trees4theForest
CC BY-SA 3.0
2017-10-03T22:24:12.883Z
2017-10-06T19:59:42.053Z
2017-10-06T19:59:42.053Z
Elder Geek
<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>

CC BY-SA 3.0
2017-09-15T06:13:55.933Z
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?
llogan
CC BY-SA 3.0
2017-09-15T11:49:38.820Z
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.
Trees4theForest
CC BY-SA 3.0
2017-09-15T17:05:51.787Z
Can you show the **complete** console output? Do you have a link to a file so we can attempt to duplicate the issue?
llogan
<ffmpeg><avi>
ffmpeg repackaging AVI (h264) into mp4 gives choppy playback in html5 video on chromium
Trees4theForest
# 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).  

---

