Subject: Re: [rtcweb] RTCWEB needs an Internet Codec

From: "Richard Shockey" <[email-masked]>
Date: Mon, 3 Sep 2012 13:52:34 -0400

So why, pray tell, did the IETF go through the grief of developing OPUS if
its most useful application will not mandate its implementation. 

SHOULD for 722 AMR-WB is very helpful in integration with Enterprise and
Mobile networks.

Its August .. clearly the silly season for technical discussions. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Randall Gellens
Sent: Friday, August 31, 2012 6:09 PM
To: John Leslie; Randell Jesup
Cc: [email-masked]
Subject: Re: [rtcweb] RTCWEB needs an Internet Codec

At 11:12 AM -0400 8/31/12, John Leslie wrote:

>  Our issue here is Mandatory-to-Implement. It is very important to  
> have at least one MTI audio codec. I could live with that being G.711,  
> because I trust the market to _actually_ implement others.

Exactly.  The discussion has been going in my view off-track into debates
about which codec is best for which environments.  The real issue is
mandatory versus recommended.

We can pick G.711 as MTI and rely on implementers to support others.

--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: --------------- One never sits in
hotel lobby chairs, my dear.  One never knows whom has been sitting in them
before one.
    --unknown
_______________________________________________
rtcweb mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Randall Gellens <[email-masked]>
Date: Mon, 3 Sep 2012 11:23:36 -0700

>  its most useful application will not mandate its implementation.

So OPUS won't be used unless it's mandated?

If OPUS has the benefits ascribed to it here, then developers will 
flock to it and it doesn't need to be mandated.  (If it doesn't have 
the benefits, then it shouldn't be mandated.)

-------------- Randomly selected tag: ---------------
I Think We're All Bozos on This Bus.           --Firesign Theatre

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 3 Sep 2012 15:50:02 -0400

-----Original Message-----
From: Randall Gellens [mailto:[email-masked]] 
Sent: Monday, September 03, 2012 2:24 PM
To: Richard Shockey; 'John Leslie'; 'Randell Jesup'
Cc: [email-masked]
Subject: RE: [rtcweb] RTCWEB needs an Internet Codec

At 1:52 PM -0400 9/3/12, Richard Shockey wrote:

>  So why, pray tell, did the IETF go through the grief of developing 
> OPUS if  its most useful application will not mandate its implementation.

[RS> ] Presumably we should try and make things better rather than just
accept the status quo which is the very definition of G.711

If OPUS has the benefits ascribed to it here, then developers will flock to
it and it doesn't need to be mandated.  (If it doesn't have the benefits,
then it shouldn't be mandated.)

 [RS> ] Humm should like a old argument for IPv6.

---

From: Basil Mohamed Gohar <[email-masked]>
Date: Mon, 03 Sep 2012 23:13:00 -0400

History has shown time and again the companies with sufficient market 
power will opt to implement their own proprietary and/or patented 
formats, or formats which benefit them financially, over royalty free, 
widely-available formats, even when their own formats are technically 
inferiors.  Take, for example, Windows Media Audio, MP3, and AAC in the 
audio realm (in contrast to Vorbis) and Windows Media Video and also 
Quicktime formats (when, at the time, technically superior, more 
standardized formats exists, such as the MPEG family, though that has 
it's own problems).

Mandating the implementation a royalty free format is about the only way 
to get such corporations to implement it, even if it is technically 
superior, as the above examples demonstrate.

On 09/03/2012 02:23 PM, Randall Gellens wrote:
>> OPUS if
>>>  have at least one MTI audio codec. I could live with that being 
>>> G.711,  because I trust the market to _actually_ implement others.
>>

-- 
Libre Video
http://librevideo.org

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Tue, 04 Sep 2012 11:30:19 +0200

Maybe an stupid question, but how it is planned to enforce the mandated 
codecs implementation? What prevents any of those "corporations" not 
implementing a mandated codec in their WebRTC products?

Best regards
Sergio

El 04/09/2012 5:13, Basil Mohamed Gohar escribió:
> inferiors.  Take, for example, Windows Media Audio, MP3, and AAC in 
> the audio realm (in contrast to Vorbis) and Windows Media Video and 
> also Quicktime formats (when, at the time, technically superior, more 
> Mandating the implementation a royalty free format is about the only 
> way to get such corporations to implement it, even if it is 
> technically superior, as the above examples demonstrate.
>

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 04 Sep 2012 14:25:39 +0200

On 09/04/2012 11:30 AM, Sergio Garcia Murillo wrote:
> Maybe an stupid question, but how it is planned to enforce the 
> mandated codecs implementation? What prevents any of those 
> "corporations" not implementing a mandated codec in their WebRTC 
> products?

My first chance to quote the new, Web-page-format Tao of IETF:

"One more thing that is important for newcomers: the IETF in no way 
"runs the Internet", despite what some people mistakenly might say. The 
IETF makes voluntary standards that are often adopted by Internet users, 
but it does not control, or even patrol, the Internet. If your interest 
in the IETF is because you want to be part of the overseers, you may be 
badly disappointed by the IETF."

http://www.ietf.org/tao.html

There is no protocol police; anyone can implement a product that 
implements only part of an IETF standard. They just can't truthfully 
claim to have implemented that IETF standard.

>> formats, or formats which benefit them financially, over royalty 
>> free, widely-available formats, even when their own formats are 
>> technically inferiors. Take, for example, Windows Media Audio, MP3, 
>> and AAC in the audio realm (in contrast to Vorbis) and Windows Media 
>> Video and also Quicktime formats (when, at the time, technically 
>> superior, more standardized formats exists, such as the MPEG family, 
>> though that has it's own problems).
>>
>>>>>   Our issue here is Mandatory-to-Implement. It is very important 
>>>>> to  have at least one MTI audio codec. I could live with that 
>>>>> being G.711,  because I trust the market to _actually_ implement 
>>>>> others.
>>>>

---

From: Jim Gettys <[email-masked]>
Date: Tue, 04 Sep 2012 10:28:01 -0400

On 09/04/2012 08:25 AM, Harald Alvestrand wrote:
> "runs the Internet", despite what some people mistakenly might say.
> The IETF makes voluntary standards that are often adopted by Internet
> users, but it does not control, or even patrol, the Internet. If your
> interest in the IETF is because you want to be part of the overseers,
> you may be badly disappointed by the IETF."
>

To the extent that the IETF has any power, it is an *indirect* power. 
If a standard is valued, then organisations (at their own discretion)
may start to write "Must implement RFCxxxx" into requests for proposals,
and choose (or not choose) to spend their money buying products that
conform or do not conform.

RFC's are littered with ignored mandatory features; similarly for RFC's
themselves.
                                    - Jim

>>> History has shown time and again the companies with sufficient
>>> market power will opt to implement their own proprietary and/or
>>> patented formats, or formats which benefit them financially, over
>>> royalty free, widely-available formats, even when their own formats
>>> are technically inferiors.  Take, for example, Windows Media Audio,
>>> MP3, and AAC in the audio realm (in contrast to Vorbis) and Windows
>>> Media Video and also Quicktime formats (when, at the time,
>>> technically superior, more standardized formats exists, such as the
>>> MPEG family, though that has it's own problems).
>>>
>>>> flock to it and it doesn't need to be mandated.  (If it doesn't
>>>> have the benefits, then it shouldn't be mandated.)
>>>>

---

From: Ron <[email-masked]>
Date: Wed, 5 Sep 2012 06:30:55 +0930

> conform or do not conform.

Which in turn is of course precisely the compelling reason for Opus to be
explicitly specified here - so that _rtcweb_ *can* have a chance of being
a standard of value, which promises the people who follow it high-quality
results and interoperability with any others who implement the standard.

There are already plenty of Go It Alone, ad hoc solutions, which to date
have little to no market traction.  Anything which performs worse than
they do is unlikely to be attractive, and anything which doesn't promise
real interoperability doesn't solve the problem which has prevented them
from being widely used outside of small disjoint circles.

"The Market" has already decided.  It decided it wanted a Real standard
for this.  Our job here is to give them one that doesn't totally suck.

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.

If there's something _better_ than Opus for this, I'd love to hear all
about it.  But talk of things that are strictly and/or vastly worse is
kind of hard to take seriously.  I can see how some people might be
feeling a little frustrated at watching that tack push ever closer to
the wind.

  Luff and KISSes,
  Ron

---

From: Randall Gellens <[email-masked]>
Date: Wed, 5 Sep 2012 16:29:28 -0700

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.  Any implementation is free to support any codec 
out-of-the-box.

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 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.

-------------- Randomly selected tag: ---------------
The single biggest problem in communication is the illusion that it
has taken place.                                       --G. B. Shaw

---

From: Ted Hardie <[email-masked]>
Date: Wed, 5 Sep 2012 17:02:39 -0700

On Wed, Sep 5, 2012 at 4:29 PM, Randall Gellens <[email-masked]> wrote:
> 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.

Speaking personally, I would put this slightly differently.  After
all, a codec with low implementation burdens may have very poor
bandwidth consumption characteristics, relatively inferior acoustic
range, or other problematic aspects which don't read on the
implementation burden.

As you note below, the overall problem is one of cost/benefit
analysis.  In the end, we need to find a way to avoid implementation
failure with a set of choices that represent the best overall
cost/benefit ratio in the contexts identified by our use cases.

>Then, implementers are free to consider which additional codecs
> they will support, taking into account the costs and benefits.

Absolutely.

regards,

Ted Hardie

---

From: Jean-Marc Valin <[email-masked]>
Date: Wed, 05 Sep 2012 21:11:05 -0400

On 12-09-05 07:29 PM, Randall Gellens wrote:
> 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.

Following the same reasoning, I think we should consider ROT13 as the
MTI encryption algorithm in rtcweb, since it's clearly the one with the
lowest possible burden to implement. Then, implementers would be free to
consider AES, 3DES, Blowfish or Enigma, taking into account the costs
and benefits.

	Jean-Marc

---

From: Ron <[email-masked]>
Date: Thu, 6 Sep 2012 11:30:40 +0930

On Wed, Sep 05, 2012 at 04:29:28PM -0700, Randall Gellens wrote:
> 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.

> 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.

> 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

---

From: John Leslie <[email-masked]>
Date: Thu, 6 Sep 2012 12:51:42 -0400

> no other "burden" placed upon them to do anything else.

   See:

www.opus-codec.org/downloads/

(the libopus.sourceforge.net is quite unrelated).

http://downloads.xiph.org/releases/opus/opus-1.0.0-rc.tar.gz

is the release-candidate. Note:
] 
] The codec is still under development, in the final stages preparing
] the first production release.

   I find this very encouraging, but not quite enough to justify MTI
today.

   Note also:

https://developer.mozilla.org/en-US/docs/Media_formats_supported_by_the_audio_and_video_elements#Ogg_Opus

which shows some level of support already in Mozilla (but not Chrome,
Explorer, Opera, or Safari)

   Here is a case where "Google's position is" could actually be
helpful -- were they to announce Opus support in Chrome...

--
John Leslie <[email-masked]>

---

From: Jean-Marc Valin <[email-masked]>
Date: Thu, 06 Sep 2012 13:30:16 -0400

On 09/06/2012 12:51 PM, John Leslie wrote:
> is the release-candidate. Note: ] ] The codec is still under 
> development, in the final stages preparing ] the first production 
> release.

Thanks for reporting this. It was old text that hadn't been updated in
a long time and which I have now fixed. In fact, the code has been in
a stable state for about one year now. The only reason we haven't
called it 1.0 yet is because we wanted to wait for the official RFC.
The good news is that RFC 6716 should be published any day now.

> which shows some level of support already in Mozilla (but not 
> Chrome, Explorer, Opera, or Safari)
> 

Quoting from Harald Alvestrand's email on this topic:

> Since the number of people stating their opinion has been large,
> I'll just reiterate the opinion I had (and hummed for) in
> Vancouver: Opus and G.711 should be mandatory to implement for
> RTCWEB. Since the question of whether there's any value to making
> the decision now has been raised: The first interoperable products
> implementing RTCWEB are shipping within a very short timeframe.
> Those first implementations will shape the market for what's
> actually used in practice. In order to allow applications requiring
> high quality sound to be among the first ones developed, those
> first products need to include a common choice of a high quality
> codec.

I think that can be counted as Google going with Opus. As for
Microsoft, I haven't seen their official position, but I can only
assume that considering their investment in this codec, they'd
probably like to use it. Regarding Opera, some people have reported
Opus already working (even before Firefox) through GStreamer builds
that included Opus. I don't know what Opera's official position is on
Opus, but support is definitely trivial for them.

Cheers,

	Jean-Marc

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Thu, 06 Sep 2012 13:17:57 -0700

> Opus, but support is definitely trivial for them.

I spoke with Simon Peters at FOMS this week in Paris, and he told me 
that Opera did plan to enable Opus on platforms that do not provide 
their own version of gstreamer (where, of course, it is already enabled, 
providing they ship at least version 0.10.23).