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


user12153: As of the date of your post, this was already a reported bug. You stated that you had this problem both in Windows and Ubuntu. For Windows at least there was a reported workaround:
For Chrome: Navigate to chrome://flags
Enable "Enable D3D11 Windows"
Chromium uses switches instead. It appears that the corresponding switch for Chromium is -d3d11See: 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 July 6, 2015 and that there is a github project here./ChromiumGStreamerBackend) Further information and details on how to implement this approach can be found here.

user34045: 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".

20036: <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>
 12153: <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>
 34045: <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>
