Re: [rtcweb] JS friendly codec compromise?

[Zach Lym <[e-mail]>]

> Which aspect of "performance" do you mean here, and could you share some
> references to support the claim? References to a legal analysis would be
> helpful aswell.

ORBX claims performance on par with H.264.  We all know that's probably
marketing hype, but it's hard to imagine not being able to outperform
H.261.  Even if the working group chose to hack together a custom codec
which is worse than H.261, an upgradeable client means we can update the
spec as performance improvements are made by the browser vendors.

I know of no formal legal analysis of ORBX, but being able to update the
decoder means that any submarine patent would have to knock out every
known video encoding technique.  Software patents are generally simple
to work around, codecs may be more so but Google's due-diligence team
thought that VP8 managed to pull it off.  They paid shut-up money to
make the FUD go away but if you are really that concerned about
potential patents we could partner with Daala.  Mozilla was smart with
Opus and patented their "new methods" so they could force
cross-licensing deals with the trolls.  They are doing the same with
Daala, so the FUD around a submarine threat  against Daala is no better
or worse than with H.264.  I don't know how well Daala's encoding could
be adapted to WebCL, but we could include some patented methods of the
codec.

Come to think of it, the Daala group is looking to recreate the
development process they had for Opus.  Skype and Mumble, both VOIP
clients, were able to push updates to client software silently,
providing the Opus team with a live test-bed which they used to
benchmark their various tweaks.  They are also actively seeking "killer
features" for the codec.  H.26X designed to compress movies, not
low-motion talking heads and screencasts:
https://www.youtube.com/watch?v=u3Yc5Hn9bhQ