The container parser would not be dynamically downloaded, and may or may not be sandboxed.
We don't need a new container with almost every codec. We just need the new codec itself.
> WebAssembly codecs indeed exist, and they are impractical due to a lack in performance.
Mostly because they don't have vector instructions yet, I bet. But plenty of webassembly is within 50% of native, which is good enough for lots of things, which includes image decoding for sure.
The challenge remains for you to actually provide the codec you describe. Which a few comments ago was trivial because it was a hardware codec anyway, now it’s just a bit of WebAssembly away. Well that should be trivial because cross compilers to WebAssembly exist. So why don’t you just provide a few real world examples? Your probably not the first to think of these ideas, there has to be a reason why it hasn’t been done yet.
Not "magically". But you only need one or two, and they don't need to be very fast, so you can put a lot of effort into making them secure.
But more importantly, browsers already have many container decoders. This is not an expansion in attack surface. The goal here is allowing a lot more codecs compared to current browsers without a significant increase in attack surface compared to current browsers. Pointing out flaws that already exist doesn't disqualify the idea.
> So why don’t you just provide a few real world examples? Your probably not the first to think of these ideas, there has to be a reason why it hasn’t been done yet.
Image decoders in webassembly already exist. Did you even look? Including JXL!
Video decoding needs more support structure in the browser, and I already said some decoders need things that are being added to webassembly but aren't done yet. Even then, the first google result for "av1 webassembly" is a working decoder from five years ago.
WebAssembly codecs indeed exist, and they are impractical due to a lack in performance.