People generally make the assumption that when they make an MP3 file, an MP3 player will play it. When they save a PNG file, a browser will display it. And when they save a PDF, any PDF application will view it.
And so we assume that H.264 decoders abide by the specification. If they claim to support Main Profile, they’ll play back Main Profile. There’s a whole set of rather exhaustive official test cases to validate compliance, which would hopefully ensure that all decoders would work with even the most bizarre combinations of features that fall under the subset of what they claim to support.
Among other things, this makes development dramatically easier: imagine how ridiculous it would be to have to test every change on dozens upon dozens of decoders to make sure that they all still worked. Instead, we can just test against the official reference to ensure that our streams are still valid.
A week ago Dylan finished up the weighted P-frame prediction Google Summer of Code project. It passed the JM verification test and it worked with libavcodec too. We also tested a few other decoders to make sure; all were fine.
And then we committed it.
We immediately got reports of artifacting in a wide variety of decoders, despite all of them claiming to support the feature. As such, here is a hall of shame of products that are distributed with broken decoders that do not abide by the spec.
Hopefully by making the world’s most popular H.264 encoder generate such problematic bitstreams by default, we will force the makers of these decoders to fix their software. I’ll update the list as the decoders are fixed (already contacted DivX [Mainconcept owners] and Adobe).
NB: this is not a new feature; it’s been around for 6 years without any relevant change in the specification, so nobody has any excuse.
Adobe Flash Player [fixed in 10.1, thanks Adobe!]
Archos players (being worked on as we speak)
CoreCodec CoreAVC [fixed in 2.0]
MediaTek chipsets, in Oppo and some LG and Phillips Blu-ray players [reported to Oppo, fixed on March 29th]
Want to see if your decoder is broken? Download this sample and watch it, especially frames 310-330. If you notice obvious artifacting, compare it to the output of a working decoder (e.g. libavcodec) for reference. If you get issues and your decoder isn’t on the list, post your results in the comments.
Edit/Note: It seems that earlier we were testing with a stream that was actually invalid; the reference decoder didn’t complain, but after putting it through a stream validator, it found an obvious issue (which we fixed in x264 r1342). As such, the list is a lot shorter now.