Defending Opus IPR Status

[jmvalin]

For those who had been wondering what we thought of the recent France Telecom IPR declaration against Opus, here's our response. It's nice to be working for a company that isn't afraid of speaking publicly about patents.

Comments

Good to hear

[zik zak (from livejournal.com)]

I'm happy to read that teh changes were quite easy to prevent this patent issue.
Opus sounds good, I can't wait to see it replacing Vorbis.
I currently use it with Theora for my own videos while I wait for Daala ^_^

Maybe Way to solve codecs deadlock and trivial pattent attacks in future

[neurall.livejournal.com]

Hi Jean.
I highly appreciate the work you do for opensource community.
I know it sounds damn formal but I would really love to finally see open and and efficient codec in all browsers unleashing full html5 potential.

Don't give up. Selecting opus for WebRTC is big win.
Anyway I recently got so tired of browser wendor dragging their feet for so long with html5 audio codecs support.
So I got the following idea how to solve it.
Basicaly whole problem with codecs and patent trolls is that codecs are fixed binary and takes time to spread codec around all browsers and platforms So when codecs are finally out and cover large enough market only then patent submarines will surface. They simply take advantage of fact that codec cant by simply pulled out and adjusted even with two lines everywhere at once. we remember gif submarine. Yet there is way to fight trivial patent trolls.

Sollution are maybe what i started calling "SoftCodecs" ie codecs that are distributed only in open source. No c code thou. let me explain.

Basically if you look at block diagram of any coder/decoder you see the same basic building blocs that are not patent encumbered.
Ie looking at mp3 than aac is basically the same blocks with tweak here and there but much simpler. mdct is just variant of idct so basically cpu time in decoder is spending most of the time in those
basic blocks

idct huffman filter

Basic idea to add support to decode anything in any browser is to register in JS lets say Algotithm object very flexible and configurable those basic building blocs as hw accelerated methods( many phones have dsp etc). JS data transfer between those blocs is fast due to native typedarray code. JS will pretty much just set pipes up on high level and configure parameters like bands thresholds etc.

I expect performance drop at most around 10% in first dumb unoptimized version.

possible advantages of soft codec

[neurall.livejournal.com]

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.