The attached files show the same problem, in Chrome OS and the Chrome browser on (GNU/)Linux.

So it has nothing to do with the mpeg4 demuxer.

Firefox, ffplay, vlc, and totem (using many of the same libraries as ffplay) all have some slight problems at the start of the file, and then are two frames (two seconds) late for the rest of the video.

Chrome ends up skipping numbered frames 3 and 9, and maybe later frames, due to them being late or something. <del>The displayed frames are otherwise the same as the decoded frame order, which is the same as the packet order in the original mp4 file. The packet order for the .avi file is ascending timestamp order, instead of presentation order, so they were rearranged when copied into the format.</del>

It's rather confusing and I might be getting numbers mixed up. The 'avicopy.mp4' has the decoded frames in the same order as the original, but the pts/presentation timestamp values are completely different. They skip around, while the dts/decode timestamp values ascend, and are always later. Maybe other applications are following the dts time strictly, always getting late frames that are in the wrong order, and always displaying them, even if the pts is lower than the previous frame's pts.

So it's possible that Chrome is displaying the frames correctly, based on what is shown for 'ffprobe -show_frames'...

It doesn't help that "decode" and "display" both start with a D, and even now I accidentally wrote "display" when expanding 'dts'. The avi file has no pts for the frames, only dts.

To verify that this isn't (just) an ffmpeg bug, I am attaching the first 1 MB of the original .avi file, as truncated.avi (with 'dd if=sample-file of=small-sample-file bs=1024 count=1000').

Deleted: ordered-frames.avi 20.0 KB

ordered-frames.avi 20.0 KB Download

Deleted: ordered-frames-avicopy.mp4 13.8 KB

	ordered-frames-avicopy.mp4 13.8 KB View Download

Deleted: truncated.avi 1000 KB

truncated.avi 1000 KB Download

So, the title of this bug is partially incorrect. Apparently, Chrome displays an mp4 file converted from avi 'incorrectly' only because it reads frames early, allowing it to notice presentation timestamps before other programs, even if it apparently reads less than 10 frames ahead so some frames can get missed and then dropped, if a file is 'broken' with dts being later than pts.

To reiterate, in copy.mp4, Chrome isn't displaying the decoded frames in stream order as shown in ffprobe. It is paying attention to presentation timestamps, not ignoring them. The frames are not in the wrong order, but they do appear to have the wrong presentation timestamps (pts), which is why Chrome displays them incorrectly. Other programs display them correctly because they avoid decoding frames early.

The reason for displaying an avi file incorrectly might be different. Chrome displays the avi file the same as it does the re-muxed (?) mp4 file, but avi files have no recorded pts value for Chrome to look for. It appears Chrome is showing frames based on their packet dts as shown in ffprobe, instead of the frame dts which is different.

So looking at ordered-frames.avi, using 'ffprobe -hide_banner -show_entries frame=pkt_pts_time,pkt_dts_time,pkt_size,coded_picture_number ordered-frames.avi -select_streams v | less'. The frames appear sorted, starting at pkt_dts_time=2 and increasing from there. But packet sizes go 1808, 351, 779.

If we look at the packets instead, with 'ffprobe -hide_banner -show_entries packet=dts_time,size ordered-frames.avi -select_streams v | less', the packets seem sorted here as well, going 0, 1, 2, 3...

But size goes 1808, 779, 351.

Based on ffprobe output for the original file, ordered-frames.mp4, the second frame should have size 351. (Also, coded_picture_number doesn't mean what I implied it did, and if their order was close to the 'buggy' output, probably coincidence.)

In the buggy output, the numbers displayed go 0, 2, 1. For the avi file, this matches the packet order and packet dts values, not the frame order or frame dts values that ffprobe shows. Presumably the packets contain the different dts value.

For pts values and mp4 files, it seems the packet and frame pts are the same. dts for frames is shown as always being the same as pts for the original file, ordered-frames.mp4, with no relation to the packet dts; but in ordered-frames-avicopy.mp4, the frame pts is always the same as the packet dts (and packet pts), which is two more than the packet pts for the original, while the frame dts is always two more than the frame dts for the original.

I'm not sure why the dts for a packet, and pkt_dts for a frame, are different when "pkt" seems like an abbreviation for packet.

For typical files that aren't copied from an avi, the frame dts and pts seem to always be the same. So if programs are ignoring the 'frame pts' recorded for a frame, and only using the dts value which has also been recorded for the frame separately than for the packet that contains it, they wouldn't have any bugs.

But Chrome doesn't ignore it or reads ahead when other programs don't, and also apparently handles avi files wrong in a way that coincidentally leads to the same output, so the video stutters.

I hope this problem can be fixed, so avi files and bugged mp4 files will play correctly in Chrome OS.

pts values reported as a bug for ffmpeg, but will not fix avi playback: https://trac.ffmpeg.org/ticket/6905

Using MP4Box, which is part of the 'gpac' package, I was able to get a non-bugged mp4 for the original avi I was testing with, but it didn't accept the 'avc1' (h.264) codec from ordered-frames.avi.

After copying the first few seconds of the original avi to copy.avi, I then performed

MP4Box -add copy.avi copy-MP4Box.mp4

The result is attached. It doesn't stutter in Chrome OS. When I unpacked the frames using ffmpeg's bitstream filter, the time to play that file ('time ffmpeg -i copy2-MP4Box.mp4 -f null -', with CPU frequency locked) is statistically indistinguishable from the non-unpacked version, though it could possibly affect hardware decoding.

Neither the unpacked nor the packed B-frame versions would play video in Chrome on Linux, so I am just including the original packed version.

In this file, the frame pts's are the same as the dts's when examined with ffprobe.

Deleted: copy-MP4Box.mp4 602 KB

	copy-MP4Box.mp4 602 KB View Download

I appreciate your debugging, but we intentionally do not support manual reordering of decoded frames. These files are considered broken if the encoded bitstream is not correctly marked for reordering (which doesn't use timestamps).

It seems you've found a way to remux the file with correct timestamps in c#4 without re-encoding which is great!

Chrome doesn't aim to play or work with every file; for reasons of maintenance and security over the lifetime of a project the size and age of Chrome, we try to error out on unexpected conditions as soon as possible.

You may want to prevent Chrome from playing .avi files, then. As it was, I spent some time looking for a cause and solution. Many answers about stuttering video said to disable hardware acceleration, which I tried.

I do wonder why Chrome OS has libraries to demux .avi files if it does not intend to correctly order the frames in it.