The spec-violation hall of shame
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.