Jonathan Blow

Because compression is easy to encapsulate and hide in code. You would be able to use video formats without knowing or caring what the compression was. If video formats were usable. Which they aren't. The biggest culprits in terms of complication are...

(a) idea that you should separate the package format from the content and allow people to use any package format (b) idea that you should separate the audio encoding from the video, and allow people to use any audio encoding (c) idea that you should break your audio playback ...

... code into 237 different libraries (d) idea that you should interface with OS-installed codecs to play videos (e) idea that people want to do a bunch of work to be able to use your format (f) idea that videos shouldn't be simple to play Feel free to reorder these.

[Worth mentioning, Bink doesn't have any of these problems, which is one reason RAD is so successful getting people to pay money for it.]

the way I see it, the reason we have the complexity of container formats is to avoid constantly redesigning the file format every time someone comes up with a new compression algorithm, which isn't something bink has to deal with

But file formats are very easy, and there is almost no practical benefit to re-using a well-understood kind of format. You make the job way harder by trying to reuse formats, and make the software much less robust, as we see empirically.

Being contrarian and having worked both sides of the fence, this is like the video side announcing graphics APIs should all be scene graphs. Needless complication in the video world does exist, however, there is sad but necessary pain around security, hardware and distribution.

Bink is in a narrow niche on those variables, which it handles very well, but if video is core to your business you'll often need the DRM/analytics while keeping that separate from the DSP/CODEC. Security often mandates the CPU has no access to the decoded content, for example.