It's worth noting that most communications specifications that involve an encoder/decoder pair communicating over a channel only specify the encoder. Standards purposely leave the decoder open to allow systems to progress as technology develops and to allow competition between implementations. This also makes a standard simpler, as a decoder is usually more complex than an encoder since it has to deal with noise and other effects introduced by the channel. Consequently, implementing a competitive standards compliant decoder involves R&D and is not a case of following a predefined path.

I've always seen Bellard as an engineer who programs rather than a pure programmer.

That's actually how I was trained. The spec and the implementation (and the testing) were separate areas; sometimes, done by different people.

These days, I tend to mix them all together, and I think I get good results.

I strongly suspect that a lot of folks, these days, only do the middle one.

There was a time when we would spend an enormous amount of time defining a spec, so that we can farm out the code. Now, we farm out the spec so that we can spend an enormous amount of time with the code.

If you actually work with ffmpeg, it's rather quite impressive how pluggable the architecture is. The codecs have huge amount of quirks and disagreements about basics (what is a "frame" in audio, subtitle, and video worlds?) and even their environment (passing frames around software and hardware coders is way different).

That fact that you can (almost) freely mix and match processing between such different worlds is quite an achievement and libav (IMO) is decently well designed to allow that.