Re: [rtcweb] RTCWEB needs an Internet Codec

[Ron <[e-mail]>]

On Wed, Sep 05, 2012 at 04:29:28PM -0700, Randall Gellens wrote:
> At 6:30 AM +0930 9/5/12, Ron wrote:
> > It's not about "forcing Opus on people who don't want it", it's about
> > making rtcweb actually work for all those people who are serious about
> > wanting something that actually works.  We're clearly not going to give
> > them that by saying: "Here's some valve-age technology that's been all
> > but obsolete for decades now - if you want this to be Any Good, you'll
> > have to figure that part out for yourselves.  Good Luck with that!"
> >
> > However much valves might be the stuff of True Audiophile wet dreams,
> > that just won't fly.  And I'm pretty sure almost everyone here knows it.
> 
> 
> At 3:42 PM +0930 9/1/12, Ron wrote:
> > The question is what is the minimum
> > guarantee that any rtcweb user will have when talking to any other
> > rtcweb user, without first needing to sign consent forms and download
> > optional extras (possibly for a reasonably non-discriminatory fee,
> > and even possibly trojaned).
> 
> 
> I'm puzzled by the repeated statements that imply that any
> non-mandatory codec can't be supported without separate downloads
> (now extended to include signed consent forms and fees).  That's
> simply not true.

I'm not sure exactly what you find puzzling about the idea that if
non-mandatory codecs are _required_ for adequate performance, then
for people using different implementations, that provide different
subsets of all the available codecs by default, *someone* is almost
certain to have to add on something extra to enable interoperability
with adequate performance.

That should be simply self-evident.

Enough so that I'll leave deeper study of venn-diagrams as a homework
exercise for any still-bewildered readers.

>  Any implementation is free to support any codec out-of-the-box.

Especially since this point was repeated alongside the others with
approximately equal frequency.  I'm pretty sure we have a clear
consensus on that.  I'm a little puzzled myself why you trimmed
that from the messages you quoted, only to repeat it again.

But we have list archives for anyone who wants the full context.


> One of the goals of rtcweb is to encourage greater use of native
> codecs, and greater access to such codecs by applications such as
> those running in browsers.  These are worthy goals, since native
> codecs often have better performance within the environment.
> (Examples include AMR and EVRC on handsets.)  These codecs also can
> be supported out-of-the-box, no separate downloads, no signed forms.

The unspoken assumption there being "provided you both happen to be
using the same platform with the same native codecs", (and of course
provided your vendor already signed the forms and payed the fees to
obtain a licence for you for the specific examples you cite).

That's fine if you do happen to.  It's when you don't that the MTI
codecs are what is relevant for interoperability.

The tiny performance difference between AMR and Opus might be of
value to some people, and if both their devices support it, and
both of them have a licence to use it, then great.

But if rtcweb sucks if you don't have those things, then this group
will have failed to meet its charter.  Which does explicitly consider
interoperability as a deliverable (but doesn't seem to actually
mention anything about native codecs at all?).

It does mention that the IETF has a codec working group whose
work should be considered though.


> The discussion is over which codecs MUST be supported.  Since
> mandatory codecs are required, with no choice, they should have the
> lowest possible burden to implement, taking into account all aspects
> of the implementation burden.  Then, implementers are free to
> consider which additional codecs they will support, taking into
> account the costs and benefits.

The libopus reference implementation source can be freely download
by anyone, at any time, and redistributed at will by any party with
no other "burden" placed upon them to do anything else.

Much of the (small amount of) extra work needed to interface that to
many existing audio processing abstractions is already done too.


How does that compare to the burden of your preferred example AMR?

Let's see.
Wikipedia tells me:

 "The initial fee for professional content creation tools and
  "real-time channel" products is $6,500. The minimum annual
  royalty shall be $10,000, excluding the initial fee in year 1
  of the license agreement"

3GPP apparently provides a reference implementation, though it's
not clear to me at this stage if that implementation actually
provides the quality claimed by the people who say it is better
than Opus for the extreme low-bandwidth niche.

What does appear to be clear though is that I'm not able to
redistribute the source of that, so I couldn't actually provide
it with my rtcweb implementation if I also wanted to give my
users the source for that (whether they paid me for it or not).

If those people wanted to use it, they'd have to jump through
all the hoops themselves to obtain it and a licence to use it.


So it's not at all clear to me how Opus isn't convincingly the
winner of the "lowest possible burden" test you propose either.

"Lowest possible" is of course a silly extreme.  That would be
raw PCM (modulo endianness trouble).  So I'm assuming you meant
something more sensible than that like lowest practical.

One codec, which covers all ranges and is as near as possible
in this modern world to being completely unencumbered would
seem to be the obvious answer there.


Luckily for us, such a thing actually exists, and the IETF even
has change control over it.

  What more could we wish for,
  Ron