4 ms·
Actually, recoiledsnake's scenario has already happened. The VP8 "spec" isn't a spec at all, it's just copy pasted C code. Unfortunately, they also chose to reu
by Locke1689 16y ago
Actually, recoiledsnake's scenario has already happened. The VP8 "spec" isn't a spec at all, it's just copy pasted C code. Unfortunately, they also chose to reuse the same code for the encoder and the decoder. This means bugs in either one can propagate into both. There was already one of these bugs found, fixed, and had a patch applied to the source tree. Google came in and reverted that patch because too much video had already been encoded with the bug in the encoder. This is exactly what happened with IE6, where bugs in the product become de facto requirements on the web.
Maybe the H264 spec drones on and on but at least it's a spec. The VP8 "spec" is just a mandate from Google. A shitty one, at that. I'll take the small risk of patent litigation among only the biggest players for an open specification and standard any day. Of course, there's also the fact that H264 is way better than VP8 which it seems like no one cares about.
- true_religion 16y agoIt was a 'bug fix' that caused a major regression. What would you have them do?
- Locke1689 16y agoWrite a spec, not a "bitstream guide," so that this problem doesn't happen in the first place? Or at least admit that your spec is not finalized and is, in reality, a piece of crap that needs wide peer review first.