1)
It defearts any current and future trivial patents(if anyone can invent it than there is either easy way around or patent is questionable like (patenting wheel) )

For example. Some patent troll objects that using snr is patented by him (FT).
No problem since codec is js dynamic code in html still evolving and just included simmilarly to jqery.

it is flexible to immediate change with no noticeable performance loss as you easily demonstreated yourself in FT 2 line patch case yoursef.
But deploying changes after such claim on all browsers platforms with codecs in binary form is unrealistic. we all know how old browser binaries stick around and then there is ie.

So this would not be possible with fixed codec in binary. And maybe many will hesitate to use binary codec with fear for patent submarines due to not trusting Microsoft and skype patents atc.

But with dynamic piping in JS that is codec outside browser.
html5 and web progress is no longer hostage like it is now for at least 10 years.
if patent submarine arises one day for example with skype based codec.
No problem to switch in hosted js codec to speex or any othe celp pretty much on the fly.
Just as you would fix hosted jquery.js globally.

2)
Immediate hw decoding support for any past and most importantly future codec on any browser or platform. ie truly open platform that is not bogged down by fixed binary.

3)
Every codec even old ones get future optimization benefits of basic building blocs. ie you make use of neon version of huffman on arm just optimizing this one basic building block ( for example done recently by mozilla in libjpeg)

4)
small but excelent browser teams like opera can now finally play anything
when codec is external. burden of licence costs is not any longer on browser vendor since codec is part of the web page . More importantly if free and more performant codecs are now thanks to this supported in all browsers then most of the sites would swich to them pretty much immediately for one simple reason saved bandwith or after being trolled by patent trolls. one way or another.


Now is JS performance problem?

Few years ago opengl in browser was deemed impossible but look
at webgl today and especially at games like quake3 in browser.
It all boils down to implementing most cpu intensive blocs as native methods just registered in js which serves just as high-level piping and configuration of blocs together.

Is it hard to implement?

My naive idea is this

Lets create new Algorithm object in JavaScript
Lets add configurable huffman, filter, quantize, idct, synth methods

exteremely creative folks at http://labs.official.fm/codecs/
already did pure decoders in js.flac mp3 aac
Unfortunately pure js is out of the question for most application scenarios except simple web player. Reasons ar lag and cpu perf.

In fact. When I got curious and proposed it on es-discuss mailing list.
http://www.mail-archive.com/es-discuss@mozilla.org/msg21188.html

The first response I got was none other than author http://labs.official.fm/codecs/ he is very talented and knows exactly where js biggest bottlenecks in such soft codecs are.
Whats more he seemed to kinda on board of such idea saying that similar efforts are already under way as part of web dsp processing standard. he mentioned that adding idct as variant of fft can surely by done.

But the most interesting thing is that i didnt got any dismissive response from leading EcmaScript standard guys like brendan even thou introducing new standard Object to JS is huge change.

Althou registering those basic building blocs(that are already implemented in browsers) as methods should not be hard.

But some educated effort (gurus like you ?) would need to be spend mainly on on Which and how configurable those few methods need to be to cover current and future codecs. Anyway first version can be just flexible enough for opus for example.

So what you think about it ?

Ladislav.