I'm lucky I noticed this today or else I'd have to redo many more files.

Forgot to set severity but I don't consider this Low. It's critical because it doesn't crash but actually produces corrupt output.

Errors you might see when playing a corruptedly muxed by ffmpeg 3.3 file:

[ffmpeg/video] h264: co located POCs unavailable
or
WARNING: Invalid RefPicListX[] entry!!! It is not included in DPB

The same file muxed by ffmpeg 2.8.11 gives no such error and doesn't start off with visible artifacts.

It doesn't have to be mp4 -> mkv. Muxing mp4 to mp4 and just recoding the audio track will have the same effect.

Reported upstream: https://trac.ffmpeg.org/ticket/6350

Thanks, I was able to reproduce it as well with a few files, but didn't have time to look into it further. I'll stalk upstream for a fix.

Cool. Can you please force 3.2.4 or 2.8.11 in place of 3.3? The corruption is irreversible and any file corruption is unmistakably a grave regression from my perspective. I've already noticed streaming sites (not youtube) that serve such corrupted files.

I won't downgrade unless upstream takes too long, in the meantime please build 3.2.4 and add ffmpeg to the IgnorePkg entry in pacman.conf. Note that I'll be upgrading x265 in a few hours, which contains a soname bump.

I understand your point and don't know what process arch packages maintainers usually follow in such a situation. However please allow me to make a last appeal before I stop mentioning it.

Corruption of files is a severe regression and even more so since recoding media files is heavy on cpu time and maybe impossible because the source material is not available. Since there's a simple fix in the form of promoting 3.2.4/2.8.11 in arch stable index until upstream releases a fix, I'm unable to understand why users' files should knowingly be corrupted anytime they remux while changing the audio track (volume adjustments, codec changes, filters etc.).

If arch testing was ffmpeg 3.3 and it didn't land in stable yet, I wouldn't ask, but I think silent corruption is the worst bug. If it crashed, users would notice something is up.

Admittedly Arch Linux is not an LTS distro, but we have a fix for a serious regression, and waiting for upstream which has been aware of the bug long before 3.3 has been taged, if you read the duplicate upstream tickets, doesn't seem like the logical decision. The earliest bug report is https://trac.ffmpeg.org/ticket/6227 (7 weeks ago) (which I didn't find before submitting my ticket since I didn't search for dropped packets).

To be clear, I'm not mad about this and I would just like to protect the rest of the arch users.

At the very least, I would appreciate a news post on arch announce or the homepage, letting users know that they should install 2.8.11 from archive.archlinux.org and pacman ignore ffmpeg in the meantime. This could work since arch users can be expected to follow.

If that issue affected a lot of people I'm sure it would have had a higher priority, an annoucement for such a thing seems like overkill to me. If you wish to speed up its resolution you can start by upvoting the upstream bug report to get the devs' attention (I already did it), once a patch is available I'll backport it in our ffmpeg package.

FYI, I just pushed a new ffmpeg2.8 to [testing], this one includes binaries which you can use instead of the 3.3 ones.

I disagree on the severity of the issue and stand by my point that any silent corruption of files is the worst bug and demands resolving especially if there is a clear remedy available. But as promised I won't be asking for you to downgrade and I do accept your decision. I solved the problem for myself and hope not many other users are affected by it.

Please, if you can spare a moment, I'd like to know the implications of a downgrade which make it a hard decision to take. It's possible I don't know the problems (of a downgrade) and have been suggesting it too quickly.

This was fixed 12 days ago upstream. Will be included in the 3.3.1 point update which will likely be released within a day or two.