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

From: Randall Gellens <[email-masked]>
Date: Wed, 29 Aug 2012 09:30:15 -0700

At 12:13 AM -0400 8/29/12, Roman Shpount wrote:

>  I would argue G.711 should be the MTI codec. The rest can be left 
> up to browser implementers.

I agree.

>  We can argue all we want, but the best royalty free low bitrate 
> codec available will be the one everybody supports.

Very good point, and why we should mandate only one audio codec.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
The most likely way for the world to be destroyed, most experts agree,
is by accident.  That's where we come in; we're computer professionals.
We cause accidents.                              --Nathaniel Borenstein

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 30 Aug 2012 12:56:05 +0200

The counterpoint is that having G.711 as the only MTI means that you get 
interoperability failure for any application in which G.711 sound 
quality is not acceptable.

This includes all applications involving music.

On 08/29/2012 06:30 PM, Randall Gellens wrote:
>>  I would argue G.711 should be the MTI codec. The rest can be left up 
>> to browser implementers.
>
> I agree.
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 30 Aug 2012 14:38:09 +0200

Surely that argument extends to every possible codec.

If the codecs supported by both endpoints do not supply the characteristics needed for the communication, then you will get interoperability failure.

If I want more bandwidth or quality than OPUS supplies, then I will also get interoperability failure.

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Harald Alvestrand
> Sent: 30 August 2012 11:56
> To: [email-masked]
> Subject: Re: [rtcweb] RTCWEB needs an Internet Codec
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 30 Aug 2012 14:51:24 +0200

> Surely that argument extends to every possible codec.
The set of MTI codecs should cover the set of use cases that have been 
identified.
Additional MTI codecs that don't cover new use cases shouldn't be added.

I believe the use case "distributed music band" in 
draft-ietf-rtcweb-use-cases-and-requirements can't be satisified with G.711.

---

From: Stefan Hakansson LK <[email-masked]>
Date: Thu, 30 Aug 2012 16:15:07 +0200

On 08/30/2012 02:51 PM, Harald Alvestrand wrote:
> The set of MTI codecs should cover the set of use cases that have
> been identified. Additional MTI codecs that don't cover new use cases
> shouldn't be added.
>

I would argue that for most of the use cases (except those where the 
browser is used to interop with PSTN) the expected quality can't be 
satisfied with G.711. A wideband capable codec at the very least is needed.

Another story is that I think that this is not the right time to mandate 
a codec that meets the quality expectations (and I said why I think so 
in [1]).

[1] http://www.ietf.org/mail-archive/web/rtcweb/current/msg05148.html

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 30 Aug 2012 16:21:56 +0200

>The set of MTI codecs should cover the set of use cases that have been identified.
>I believe the use case "distributed music band" in draft-ietf-rtcweb-use-cases-and-requirements can't be satisified with G.711.

Maybe dubstep was invented that way ;)

Regards,

Christer

>> From: [email-masked] [mailto:[email-masked]] On 
>> Behalf Of Harald Alvestrand
>> The counterpoint is that having G.711 as the only MTI means that you 
>> get interoperability failure for any application in which G.711 sound

---

From: Randall Gellens <[email-masked]>
Date: Thu, 30 Aug 2012 10:31:08 -0700

At 2:51 PM +0200 8/30/12, Harald Alvestrand wrote:

> been identified.

That may be too many mandated codecs.  This business of mandating 
specific codecs is difficult and contentious, since there are so many 
competing interests involving different implementation platforms and 
operating environments.  It may also be unnecessary since, obviously, 
implementers want to interoperate and the spectrum of supported 
codecs will reflect this.

-------------- Randomly selected tag: ---------------
To err is human, to moo bovine.

---

From: "Mandyam, Giridhar" <[email-masked]>
Date: Thu, 30 Aug 2012 19:13:06 +0000

Hello Harald,
Can you clarify this viewpoint?  If we use the criterion that any MTI codec has to be suitable for all use cases as currently documented, then it seems neither Opus nor G.711 can suffice.  

For instance, use case 4.2.7 - "... the user's provider of cellular access has QoS support enabled.  The user is able to take advantage of the QoS support both when accessing via the residential router and when using cellular."  If the guaranteed bit rate (GBR, part of the QoS Class Indicator in 3GPP defined networks) falls outside of the operating range where Opus is the best performing codec (e.g. the sub-8kbps part of the 'Quality vs Bitrate' curve in http://www.opus-codec.org/comparison/), another codec would be required.

The study available at http://research.nokia.com/files/public/%5B16%5D_InterSpeech2011_Voice_Quality_Characterization_of_IETF_Opus_Codec.pdf clearly shows a significant advantage in MOS scores at 5.9 kbps for  AMR-NB as compared to Opus (Silk).  The initial conclusion from my end is that using Opus when cellular QoS support results in a guaranteed bit rate less than 8 kbps would not result in the user being "able to take advantage of the QoS support" as per the use case.

I think we shouldn't try to mandate codecs to try to cover every single use case.  Rather we should mandate as few as necessary to avoid codec negotiation failure.

-Giri

---

From: Jean-Marc Valin <[email-masked]>
Date: Thu, 30 Aug 2012 15:39:52 -0400

On 12-08-30 03:13 PM, Mandyam, Giridhar wrote:
> The study available at
> http://research.nokia.com/files/public/%5B16%5D_InterSpeech2011_Voice_Quality_Characterization_of_IETF_Opus_Codec.pdf
> clearly shows a significant advantage in MOS scores at 5.9 kbps for
> AMR-NB as compared to Opus (Silk).  The initial conclusion from my
> end is that using Opus when cellular QoS support results in a
> guaranteed bit rate less than 8 kbps would not result in the user
> being "able to take advantage of the QoS support" as per the use
> case.

So because Opus is better except around 6 kb/s means that we have
negotiation failure and that we should instead use G.711 at 64 kb/s?
Also, keep in mind that browser-to-browser means RTP, which typically
means 16 kb/s worth of overhead anyway (with 20 ms frames). Even though
Opus is not optimal at 6 kb/s, we still have something that works and we
avoid interop failure. And what are the alternatives anyway? If we only
decide on G.711, then we not only have embarrassingly bad quality, but
we also have interop failure below 64 kb/s. If you want guaranteed good
quality without Opus, you can also make AMR-NB, AMR-WB, G.722.1C,
AAC-LD, HE-AAC, and AAC-LC all MTI. Then you'll have (on average)
quality that's almost as good as Opus alone can do, you'll cover almost
as many use cases, and as a bonus, you get all the negotiation and
switching nightmares involved.

	Jean-Marc

> -----Original Message----- From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Harald Alvestrand Sent:
> Thursday, August 30, 2012 5:51 AM To: DRAGE, Keith (Keith) Cc:
> [email-masked] Subject: Re: [rtcweb] RTCWEB needs an Internet Codec
> 
>> If the codecs supported by both endpoints do not supply the
>> characteristics needed for the communication, then you will get
>> interoperability failure.
>> 
>>> -----Original Message----- From: [email-masked]
>>> [mailto:[email-masked]] On Behalf Of Harald Alvestrand 
>>> Sent: 30 August 2012 11:56 To: [email-masked] Subject: Re:
>>> [rtcweb] RTCWEB needs an Internet Codec
>>> 
>>> The counterpoint is that having G.711 as the only MTI means that
>>> you get interoperability failure for any application in which
>>> G.711 sound quality is not acceptable.
>>> 
>>>>> I would argue G.711 should be the MTI codec. The rest can be
>>>>> left up to browser implementers.
>>>> I agree.
>>>> 
>>>>> We can argue all we want, but the best royalty free low
>>>>> bitrate codec available will be the one everybody supports.
>>> _______________________________________________ rtcweb mailing
>>> list [email-masked] 
> _______________________________________________ rtcweb mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/rtcweb 
> _______________________________________________ rtcweb mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 30 Aug 2012 21:40:47 +0200

> Can you clarify this viewpoint?  If we use the criterion that any MTI codec has to be suitable for all use cases as currently documented, then it seems neither Opus nor G.711 can suffice.
That's not what I said. I said that the *set* of MTI codecs should cover 
the use cases.
We have a requirement (F21) that explicitly mentions commonly supported 
codecs in telephony services; there's no way Opus can cover that case.
>    
>
> For instance, use case 4.2.7 - "... the user's provider of cellular access has QoS support enabled.  The user is able to take advantage of the QoS support both when accessing via the residential router and when using cellular."
You're not reading the latest draft. That section is now 4.2.6.
>    If the guaranteed bit rate (GBR, part of the QoS Class Indicator in 3GPP defined networks) falls outside of the operating range where Opus is the best performing codec (e.g. the sub-8kbps part of the 'Quality vs Bitrate' curve in http://www.opus-codec.org/comparison/), another codec would be required.
Section 4.1 of the draft defines "narrowband" to be "10s to 100s of 
Kbits/sec".
>
> The study available at http://research.nokia.com/files/public/%5B16%5D_InterSpeech2011_Voice_Quality_Characterization_of_IETF_Opus_Codec.pdf clearly shows a significant advantage in MOS scores at 5.9 kbps for  AMR-NB as compared to Opus (Silk).
Respectfully ..... the slight advantage in quality that AMR-NB seems to 
offer over Opus at 8 kbps is very different from the advantage that Opus 
enjoys over G.711 at 64 Kbits and above.
>    The initial conclusion from my end is that using Opus when cellular QoS support results in a guaranteed bit rate less than 8 kbps would not result in the user being "able to take advantage of the QoS support" as per the use case.
Neither does it cover the case where there's not enough bits to carry an 
IP+RTP header every 20 milliseconds. There are cases where WebRTC won't 
work.
> I think we shouldn't try to mandate codecs to try to cover every single use case.  Rather we should mandate as few as necessary to avoid codec negotiation failure.
Yes. And failure to negotiate an usable codec is a negotiation failure.

---

From: Jean-Marc Valin <[email-masked]>
Date: Thu, 30 Aug 2012 16:23:36 -0400

> also get interoperability failure.

Care to provide an example of use case to which Opus does not scale? It
starts from about 6 kb/s, which is certainly low enough (and far less
than the RTP overhead anyway). From there, it can scale to 512 kb/s
stereo, which is more than twice as much as the highest bitrate at which
anyone was ever able to ABX the coded audio against the original.
There's also multi-channel (>2) mappings if needed. Well, we don't cover
dogs, but I think I can live with that.

	Jean-Marc

>> you get interoperability failure for any application in which G.711
>> sound quality is not acceptable.
>> 
>> list [email-masked] https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Gregory Maxwell <[email-masked]>
Date: Thu, 30 Aug 2012 13:58:41 -0700

Jean-Marc Valin [[email-masked]] wrote:
> Well, we don't cover

But on the internet no one can tell you're a dog.

Fortunately preserving the anonymity of dogs was not an enumerated application.

Including Opus as MTI should be the most straightforward way to ensure interoperability for all the enumerated applications, and covering the space of human perception is also important for all the ones the working group inevitably forgot to enumerate.

Codecs are boring. It's important to have good infrastructure uniformly available so that the authors of applications that will build on the browsers that implement rtcweb won't have to worry about codecs and can spend their attention on the real innovation that will happen on top of this low level infrastructure.

---

From: "Mandyam, Giridhar" <[email-masked]>
Date: Fri, 31 Aug 2012 00:18:28 +0000

> So because Opus is better except around 6 kb/s means that we have negotiation failure and that we should instead use G.711 at 64 kb/s?

I don't follow. If both parties in the call support a codec suitable for 6 kb/s (e.g. AMR-NB) then there should be no negotiation failure.  MTI still allows for non-MTI codecs to be used on a WebRTC call.  The point I was trying to make was that Opus does not satisfy the use case as specified.  I never said that G.711 satisfied this use case.  I believe it is unrealistic to require that the set of MTI audio codecs (whatever they may be) satisfy every single use case as currently outlined.  

> Also, keep in mind that browser-to-browser means RTP, which typically means 16 kb/s worth of overhead anyway (with 20 ms frames).

All the more reason to achieve toll quality at codec data rates below 8 kbps when operating in a cellular environment.  Just because there is substantial overhead for IP/UDP/RTP when compared to that for a circuit-switched call does not mean we shouldn't strive for the best quality at the lowest data rate.  Keep in mind that there are codecs that exhibit suitable performance at even lower data rates than AMR-NB (e.g. EVRC-B at approximately 4 kbps).  If we assume Opus has operate at 8 kbps to exhibit suitable voice quality (which still needs to be verified under codec performance testing as per industry standards), that is still a significant increase in required data rate even accounting for the IP/UDP/RTP header overhead.  Going from Opus at approx.. 8 kbps to EVRC-B at approx. 4 kbps gives near 20% savings in required bitrate even when considering 16 kbps overhead. This is a significant savings for cellular access.  

For any interested parties, EVRC-B characterization tests have been presented previously in the 3GPP2, e.g. the document "Characterization Test Report for EVRC-Release B" (A. Sharpley and I. Panzer, 3GPP2 Document 3GPP2- C11-20060327-015, March 27-31, 2006).

> If you want guaranteed good quality without Opus, you can also make AMR-NB, AMR-WB, G.722.1C, AAC-LD, HE-AAC, and AAC-LC all MTI. Then you'll have (on average) quality that's almost as good as Opus alone can do, you'll cover almost as many use cases, and as a bonus, you get all the negotiation and switching nightmares involved.

I've already stated my position on MTI audio codecs on this mailing list.  I never advocated making every codec that is optimal given a particular operating condition as MTI.  I also think the performance loss due to the use of Opus at sub 10 kbps is not trivial, and it is worth leveraging other codecs at these lower data rates. 

-----Original Message-----
From: Jean-Marc Valin [mailto:[email-masked]] 
Sent: Thursday, August 30, 2012 12:40 PM
To: Mandyam, Giridhar
Cc: Harald Alvestrand; DRAGE, Keith (Keith); [email-masked]
Subject: Re: [rtcweb] RTCWEB needs an Internet Codec

On 12-08-30 03:13 PM, Mandyam, Giridhar wrote:
> The study available at
> http://research.nokia.com/files/public/%5B16%5D_InterSpeech2011_Voice_
> Quality_Characterization_of_IETF_Opus_Codec.pdf
> AMR-NB as compared to Opus (Silk).  The initial conclusion from my end 
> is that using Opus when cellular QoS support results in a guaranteed 
> bit rate less than 8 kbps would not result in the user being "able to 
> take advantage of the QoS support" as per the use case.

So because Opus is better except around 6 kb/s means that we have negotiation failure and that we should instead use G.711 at 64 kb/s?
Also, keep in mind that browser-to-browser means RTP, which typically means 16 kb/s worth of overhead anyway (with 20 ms frames). Even though Opus is not optimal at 6 kb/s, we still have something that works and we avoid interop failure. And what are the alternatives anyway? If we only decide on G.711, then we not only have embarrassingly bad quality, but we also have interop failure below 64 kb/s. If you want guaranteed good quality without Opus, you can also make AMR-NB, AMR-WB, G.722.1C, AAC-LD, HE-AAC, and AAC-LC all MTI. Then you'll have (on average) quality that's almost as good as Opus alone can do, you'll cover almost as many use cases, and as a bonus, you get all the negotiation and switching nightmares involved.

	Jean-Marc

> identified. Additional MTI codecs that don't cover new use cases 
> shouldn't be added.
> 
>>> get interoperability failure for any application in which

---

From: "Mandyam, Giridhar" <[email-masked]>
Date: Fri, 31 Aug 2012 00:20:21 +0000

>That's not what I said. I said that the *set* of MTI codecs should cover the use cases.
>We have a requirement (F21) that explicitly mentions commonly supported codecs in telephony services; there's no way Opus can cover that case.

Apologies - inaccurate wording on my part.  I still think it is unrealistic for any suite of MTI codecs to cover all use cases.  I think the QoS-based use case still stands as an example of why this is unrealistic.

> You're not reading the latest draft. That section is now 4.2.6.

The version I linked to from the RTCWEB status pages is -09, which has the relevant use case as 4.2.7 (see http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-09#section-4.2.7).  If the doc is rapidly evolving, then the use case doc may not be suitable for evaluation of codecs for MTI at this point in time.

> Section 4.1 of the draft defines "narrowband" to be "10s to 100s of Kbits/sec".

The full text states  "Clients can be on narrowband (10s to 100s of Kbits/sec)".  Does this definition refer to codecs or the underlying access technology?  I think in the context one could reasonably conclude that "narrowband" refers to dial-up or low data rate cellular (e.g. GPRS, GSM HSCSD, 1X).  The text in 4.1 says nothing about bandlimiting of the input voice signal to a codec.  Moreover, the ensuing text states  "Clients can be on variable-media-quality networks (wireless)".  To me, this means that the sub-10 kbps case for voice codecs is still relevant.

> Respectfully ..... the slight advantage in quality that AMR-NB seems to offer over Opus at 8 kbps is very different from the advantage that Opus enjoys over G.711 at 64 Kbits and above.

I don't view the quality advantage as 6 kbps as slight, and implementers still have the option of using Opus at any all data rates without designating it as MTI.  Just as implementers can use AMR-WB, G.722 and so on.  Moreover, the study I cited did not consider codecs such as EVRC-B that can operate in the sub 5 kbps range.  

>Neither does it cover the case where there's not enough bits to carry an IP+RTP header every 20 milliseconds. There are cases where WebRTC won't work.

I'm not sure what you are trying to say.  Do you believe the use of Opus will not satisfy the QoS use case?  Or do you believe that the QoS use case is one where WebRTC will simply not work?

-----Original Message-----
From: Harald Alvestrand [mailto:[email-masked]] 
Sent: Thursday, August 30, 2012 12:41 PM
To: Mandyam, Giridhar
Cc: DRAGE, Keith (Keith); [email-masked]
Subject: Re: [rtcweb] RTCWEB needs an Internet Codec

> Can you clarify this viewpoint?  If we use the criterion that any MTI codec has to be suitable for all use cases as currently documented, then it seems neither Opus nor G.711 can suffice.
That's not what I said. I said that the *set* of MTI codecs should cover the use cases.
We have a requirement (F21) that explicitly mentions commonly supported codecs in telephony services; there's no way Opus can cover that case.

---

From: Jean-Marc Valin <[email-masked]>
Date: Thu, 30 Aug 2012 21:43:05 -0400

On 08/30/2012 08:18 PM, Mandyam, Giridhar wrote:
> I don't follow. If both parties in the call support a codec
> suitable for 6 kb/s (e.g. AMR-NB) then there should be no
> negotiation failure. MTI still allows for non-MTI codecs to be used
> on a WebRTC call.  The point I was trying to make was that Opus
> does not satisfy the use case as specified.  I never said that
> G.711 satisfied this use case. I believe it is unrealistic to
> require that the set of MTI audio codecs (whatever they may be)
> satisfy every single use case as currently outlined.

Here's the thing. I'm not trying to prevent you from including AMR-NB
or any other codec. If all you have is 6 kb/s and you have AMR-NB on
both ends, then by all means use that. But what if that's not the case
and only one side supports it? If only G.711 is MTI, then the
negotiation *fails*. And it won't just fail at 6 kb/s. It'll fail all
the way up to 64 kb/s and that's unacceptable. OTOH, if you have Opus
as MTI, you'll still be able to talk, which is big improvement, even
if the quality isn't nearly as good as AMR-NB or EVRC-B at these
ridiculously low bitrates. Essentially, I've yet to understand your
reasoning that because Opus is "only" optimal for 99% of the use
cases, then we should use something (G.711) that's highly suboptimal
in all use cases.

The way I see this shaping up, it seems highly likely that

> All the more reason to achieve toll quality at codec data rates
> below 8 kbps when operating in a cellular environment.

Sure, go as low as you like. There's even codecs that work at 2 kb/s
and below if you like. If both sides support it, it's all good. But
when all we have in common are the MTI codecs, then please let's make
webrtc not suck or (worse) fail completely.

> I've already stated my position on MTI audio codecs on this
> mailing list.  I never advocated making every codec that is optimal
> given a particular operating condition as MTI.  I also think the
> performance loss due to the use of Opus at sub 10 kbps is not
> trivial, and it is worth leveraging other codecs at these lower
> data rates.

So here's the options we're looking at in the cases where all you have
in common are MTI codecs (and it seems that those will be common):
1) Optimal quality at almost all rates, but sub-optimal below 10 kb/s; or
2) Highly sub-optimal at 64 kb/s and above, with completely failure
below 64 kb/s.

I'm sure most people prefer 1) and I still don't understand why you
would prefer option 2). Option 2) essentially means "we have a really
crappy standard which can only work decently if you have extensions".

	Jean-Marc

> -----Original Message----- From: Jean-Marc Valin 
> [mailto:[email-masked]] Sent: Thursday, August 30, 2012 12:40 
> PM To: Mandyam, Giridhar Cc: Harald Alvestrand; DRAGE, Keith
> (Keith); [email-masked] Subject: Re: [rtcweb] RTCWEB needs an
> Internet Codec
> 
>> clearly shows a significant advantage in MOS scores at 5.9 kbps
>> for AMR-NB as compared to Opus (Silk).  The initial conclusion
>> from my end is that using Opus when cellular QoS support results
>> in a guaranteed bit rate less than 8 kbps would not result in the
>> user being "able to take advantage of the QoS support" as per the
>> use case.
> 
> negotiation failure and that we should instead use G.711 at 64
> kb/s? Also, keep in mind that browser-to-browser means RTP, which
> typically means 16 kb/s worth of overhead anyway (with 20 ms
> frames). Even though Opus is not optimal at 6 kb/s, we still have
> something that works and we avoid interop failure. And what are the
> alternatives anyway? If we only decide on G.711, then we not only
> have embarrassingly bad quality, but we also have interop failure
> below 64 kb/s. If you want guaranteed good quality without Opus,
> you can also make AMR-NB, AMR-WB, G.722.1C, AAC-LD, HE-AAC, and
> AAC-LC all MTI. Then you'll have (on average) quality that's almost
> as good as Opus alone can do, you'll cover almost as many use
> cases, and as a bonus, you get all the negotiation and switching
> nightmares involved.
> 
> Jean-Marc
> 
>> Sent: Thursday, August 30, 2012 5:51 AM To: DRAGE, Keith (Keith) 
>> Cc: [email-masked] Subject: Re: [rtcweb] RTCWEB needs an
>> Internet Codec
>> 
>> The set of MTI codecs should cover the set of use cases that
>> have been identified. Additional MTI codecs that don't cover new
>> use cases shouldn't be added.
>> 
>>>> [mailto:[email-masked]] On Behalf Of Harald 
>>>> Alvestrand Sent: 30 August 2012 11:56 To: [email-masked] 
>>>> The counterpoint is that having G.711 as the only MTI means 
>>>> that you get interoperability failure for any application in 
>>>> which G.711 sound quality is not acceptable.
>>>> 
>>>>>> I would argue G.711 should be the MTI codec. The rest
>>>>>> can be left up to browser implementers.
>>>>> I agree.
>>>>> 
>>>> _______________________________________________ rtcweb
>>>> mailing list [email-masked]

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 31 Aug 2012 08:05:16 +0200

> Apologies - inaccurate wording on my part.  I still think it is unrealistic for any suite of MTI codecs to cover all use cases.  I think the QoS-based use case still stands as an example of why thi…
I still think you are constructing an unrealistic use case, and one that 
isn't in the document.
If necessary, we should make the document more explicit to say that we 
don't solve for use cases where less than 10s of kilobits of Internet 
bandwidth is available; I believe the speech quality of Opus is not your 
biggest problem in that scenario.

The purpose of an use case document is to describe the problems we're 
solving so that we can separate them from the problems we don't solve. 
I'd be fine with ruling sustained sub-10-Kbits/sec available Internet 
bandwidth explicitly out of scope.
> The version I linked to from the RTCWEB status pages is -09, which has the relevant use case as 4.2.7 (see http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-09#section-4.2.7).…
Yes, apologies; I was the one with an unrefreshed archive.
> I'm not sure what you are trying to say.  Do you believe the use of Opus will not satisfy the QoS use case?  Or do you believe that the QoS use case is one where WebRTC will simply not work?
I believe we'll have a hard time getting the QoS use case working, not 
because of what you say, but because the QoS APIs on the Internet are 
still quite difficult to use. But this is entirely orthogonal to the 
codec question.

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Thu, 30 Aug 2012 23:15:01 -0700

> biggest problem in that scenario.

Agreed. Even if it was, as Jean-Marc points out elsewhere, making Opus 
non-MTI does not magically solve that problem. It just means that you 
may only be left with G.711 to solve that problem. That doesn't exactly 
seem like an improvement.

---

From: John Leslie <[email-masked]>
Date: Fri, 31 Aug 2012 09:38:45 -0400

Harald Alvestrand <[email-masked]> wrote:
> bandwidth is available...

   +1

   There are today some use-cases with less than 56Kbps; but they're
dying, and the infrastructure for them isn't being built anywhere
(including third-world countries, if you must ask).

   I'm very glad there _are_ codecs that can operate in such an
environment; but that's not where our effort belongs. We want something
optimized for 5-10 years down the road.

--
John Leslie <[email-masked]>

---

From: Randell Jesup <[email-masked]>
Date: Fri, 31 Aug 2012 10:46:10 -0400

>> bandwidth is available...

Agreed.

> optimized for 5-10 years down John Leslie

If you're talking audio-only calls, I agree - but for audio+video, you 
want a lot of bandwidth available for video.  If the user has 128Kbps, I 
don't want 56K of that devoted to audio; I probably want 15-25K for 
audio (which can give good wideband or better performance with Opus), 
and the rest for video.  I probably wouldn't open audio up to 56 or 64K 
(using Opus) below 300-500K of total bandwidth, because of diminishing 
rate of improvement over ~25K.

Having a *good* low-bitrate (and adaptable) audio codec is *critical* to 
having a good solution for video.  Without that all the cases that 
involve video are blown below 100's of Kbps; with a good low-bandwidth 
codec you can do video calls with 100Kbps or even less.  This is why I 
support Opus (+G.711 for legacy interop and testing) for MTI.

-- 
Randell Jesup
[email-masked]

---

From: "Mandyam, Giridhar" <[email-masked]>
Date: Fri, 31 Aug 2012 15:03:55 +0000

Harald, 
I don't think your suggestion is going to work.  As Jean-Marc pointed out in a separate email, RTP transmission imposes a floor of 16 kbps assuming 20 ms framing.  I agree with him.  Moreover even though the transmission rate has to be greater than 10 kbps, the need to use a bandwidth-efficient codec does not go away.

If you want to eliminate the cellular QoS use case altogether, I think you should explicitly state so.  I think this "moves the goalposts" for the WebRTC effort however, and needs significantly more discussion among the group.

-Giri

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Harald Alvestrand
Sent: Thursday, August 30, 2012 11:05 PM
To: Mandyam, Giridhar
Cc: [email-masked]
Subject: Re: [rtcweb] RTCWEB needs an Internet Codec

> Apologies - inaccurate wording on my part.  I still think it is unrealistic for any suite of MTI codecs to cover all use cases.  I think the QoS-based use case still stands as an example of why thi…
I still think you are constructing an unrealistic use case, and one that isn't in the document.
If necessary, we should make the document more explicit to say that we don't solve for use cases where less than 10s of kilobits of Internet bandwidth is available; I believe the speech quality of Opus is not your biggest problem in that scenario.

The purpose of an use case document is to describe the problems we're solving so that we can separate them from the problems we don't solve. 
I'd be fine with ruling sustained sub-10-Kbits/sec available Internet bandwidth explicitly out of scope.
> I'm not sure what you are trying to say.  Do you believe the use of Opus will not satisfy the QoS use case?  Or do you believe that the QoS use case is one where WebRTC will simply not work?
I believe we'll have a hard time getting the QoS use case working, not because of what you say, but because the QoS APIs on the Internet are still quite difficult to use. But this is entirely orthogonal to the codec question.
_______________________________________________
rtcweb mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: John Leslie <[email-masked]>
Date: Fri, 31 Aug 2012 11:12:47 -0400

> rate of improvement over ~25K.

   128Kbps is marginal for audio+video, yes.

   However, I don't believe it wise for us to try to standardize anything
about the audio-vs-video tradeoff.

   I will state my opinion that good audio plus one frame per second is
better in a conferencing environment than bad audio plus 128Kbps of
video; but I'd never impose that choice on anyone else.

   The point is: G.711 is suboptimal, yes, but not unusable.

   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.

> Having a *good* low-bitrate (and adaptable) audio codec is *critical*
> to having a good solution for video.

   I'm not sure I agree, though it is certainly _very_ helpful.

> Without that all the cases that involve video are blown below 100's
> of Kbps; with a good low-bandwidth codec you can do video calls
> with 100Kbps or even less.

   I'm not sure even this will remain true for five years.

   But I am sure that the market will implement Opus or something
like it within five years without our needing to call it MTI.

> This is why I support Opus (+G.711 for legacy interop and testing)
> for MTI.

   This _is_ a good argument: I don't mean to ridicule it.

   But we need to reach closure on this. If enough people are scared
of the IPR questions of Opus, I'm willing to retreat to a SHOULD
implement Opus.

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 31 Aug 2012 17:32:42 +0200

> If you want to eliminate the cellular QoS use case altogether, I think you should explicitly state so.  I think this "moves the goalposts" for the WebRTC effort however, and needs significantly mor…
I think you're the one moving the goalposts.... if you want to introduce 
an use case with audio communcation with an available Internet bit rate 
significantly below 10 Kbits/second, be my guest.

The QoS case is about interacting with QoS mechanisms (bandwidth 
reservation, DSCP, what have you). Reading it as mandating support for 
extremely low bandwidths is a stretch.

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 31 Aug 2012 08:40:43 -0700

> because I trust the market to _actually_ implement others.

Agree with the above. G.711 for mti only.

I want to push Opus and promote its use, but MTI is not the right method
for that.

CB

---

From: "Mandyam, Giridhar" <[email-masked]>
Date: Fri, 31 Aug 2012 15:57:46 +0000

Hi Harald,

> I think you're the one moving the goalposts.... if you want to introduce an use case with audio communcation with an available Internet bit rate significantly below 10 Kbits/second, be my guest.

What are you defining as "available internet bit rate"?  Is it the bps provided by the access technology to IP?  If so, I concede that an IP/UDP/RTP session will require more than 10 kbps from the underlying access technology.  There can be an explicit mention in the document as such if it helps.  If you are referring to the data rate available to a WebRTC application over RTP (i.e. the codec rate), then I don't agree that we should limit ourselves to only 10 kbps codec settings or greater.  

> The QoS case is about interacting with QoS mechanisms (bandwidth reservation, DSCP, what have you). Reading it as mandating support for extremely low bandwidths is a stretch.

The use case text states "In addition, the user's provider of cellular access has QoS support enabled." QoS with respect to cellular access is well-understood in the industry, and is not restricted to reservation or DSCP settings.  This includes access-network settings for guaranteed bit rate, maximum packet delay, acceptable packet loss rate. 

To clarify, when we mention "low bandwidth" do we mean low bandwidth from a codec perspective or from an access perspective?
  
-----Original Message-----
From: Harald Alvestrand [mailto:[email-masked]] 
Sent: Friday, August 31, 2012 8:33 AM
To: Mandyam, Giridhar
Cc: [email-masked]
Subject: Re: [rtcweb] RTCWEB needs an Internet Codec

> If you want to eliminate the cellular QoS use case altogether, I think you should explicitly state so.  I think this "moves the goalposts" for the WebRTC effort however, and needs significantly mor…
I think you're the one moving the goalposts.... if you want to introduce an use case with audio communcation with an available Internet bit rate significantly below 10 Kbits/second, be my guest.

The QoS case is about interacting with QoS mechanisms (bandwidth reservation, DSCP, what have you). Reading it as mandating support for extremely low bandwidths is a stretch.

---

From: Jean-Marc Valin <[email-masked]>
Date: Fri, 31 Aug 2012 12:34:45 -0400

> The point is: G.711 is suboptimal, yes, but not unusable.

Not necessarily unusable, but it'll pretty much guarantee that nobody
will *want* to use webrtc with that kind of quality. Not to mention
*actually* unusable below 64 kb/s (+overhead).

> have at least one MTI audio codec. I could live with that being
> G.711, because I trust the market to _actually_ implement others.

Oh, I'm absolutely certain they'd implement other codecs. But how do
you know they'll all implement the *same* codec? That's the whole
point of MTI. Otherwise we might as well say that the standard is "tin
cans with string" and then tell people to add whatever extension is
needed to get decent quality. That's not a standard and that's no
better than the current situation with plugins.

The current situation is this: there's existing platforms from Skype,
Google, and others that provide wideband and super-wideband speech at
low enough rates for pretty much everyone. And if you use (e.g.)
Skype, you know that you can always get super-wideband quality
(assuming enough bandwidth). What some here are proposing is a huge
step backwards. Why would I use WebRTC over Skype/Google if I'm likely
to end up with high bit-rate narrowband just because the person I'm
talking to uses a different vendor. Let's at least make sure that
WebRTC will be better or equal to other offerings at all time.
Otherwise what's the point? And it's not like this is really hard, is
it? We have Opus here that's standardized by the IETF (well, in a few
days anyway), and it's an improvement on top of what Skype currently
ships. I've yet to see a valid reason to settle for less.

	Jean-Marc

---

From: Roman Shpount <[email-masked]>
Date: Fri, 31 Aug 2012 20:23:15 +0300

One issue I want to bring into consideration is computation complexity of
Opus. It is normally acceptable for end user devices in point-to-point
calls (I do not want to start all the mobile device CPU vs battery live
discussion. It is irrelevant), but in cases where you need to process all
the calls on some sort of central server (such as conferencing, or virtual
reality, or massive multi-player games) the additional processing cost of
supporting Opus can be significant. In such cases G.722 (ideally in
combination with  PLC and CN to save bandwidth) can be a valid compromise,
since it can provide quality better then G.711 with CPU processing
requirements order of magnitude less then Opus.

My point is I see no downside of making G.722 an MTI codec in addition to
G.711 and Opus. Additional code is minimal and well understood, there are
no royalties. On the upside there are at least two significant use cases
(conferencing or other central audio processing scenarious and interop with
enterprise equipment) that will justify this.
_____________
Roman Shpount

On Fri, Aug 31, 2012 at 7:34 PM, Jean-Marc Valin <[email-masked]>wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJQQOelAAoJEJ6/8sItn9q9yuUIAI1NZvZZmwAr2vjrifQUecz2
> Zkx4EVPmeDqpmbtt8kCGLozS33w1+TLG8npNPb05Gwndo4Jpv8cgVAH1LFVqJyj3
> 0278+fYnYGZP6Xa8LEqveQzAaZgNrPEBmVp4ZbwjH9U35j7xuSLw3qbs3dkuE4pt
> QJshSTiW9ZjoC26O6SBM101EgisLoTkdSIEjKOs46epb6SsIrm/VOhcCc0Gt1xhR
> /grzxONeiKnOX/uS0bUDMEAMfobrDQxRwakiCFEIxBa7JLvcoLj18t1IeHhQ6vNU
> /K+IV3a0a8COc0HiVETznarAOgHSNLH/Vww9hZf+dO2R2cIxASGiVoDFQzdkxWc=
> =w4qQ
> -----END PGP SIGNATURE-----

---

From: "Mandyam, Giridhar" <[email-masked]>
Date: Fri, 31 Aug 2012 17:25:33 +0000

>Here's the thing. I'm not trying to prevent you from including AMR-NB or any other codec. If all you have is 6 kb/s and you have AMR-NB on both ends, then by all means use that. But what if that's not the case and only one side supports it? If only G.711 is >MTI, then the negotiation *fails*. And it won't just fail at 6 kb/s. It'll fail all the way up to 64 kb/s and that's unacceptable. OTOH, if you have Opus as MTI, you'll still be able to talk, which is big improvement, even if the quality isn't nearly as good as AMR->NB or EVRC-B at these ridiculously low bitrates. Essentially, I've yet to understand your reasoning that because Opus is "only" optimal for 99% of the use cases, then we should use something (G.711) that's highly suboptimal in all use cases.

I'm not sure I understand your logic either.  You could make the same argument in favor of having AMR-NB or EVRC-B as MTI.  Why not do so and cover 100% of the use cases?

In addition, I don't view all use cases as being of equal importance (at least with initial implementations).  Conversational voice over cellular must work for WebRTC.  

Moreover, I don't believe the standardization process for any codec suitable for conversational voice is complete without a characterization under lossy conditions and with human listeners (true MOS score).  This is the approach that standards bodies such as 3GPP and 3GPP2 have taken towards codec standardization.  I think the studies you pointed to in a separate email (from Google and Nokia) are a good start, but until we see testing like the Dynastat study I referenced in my previous email then to say Opus satisfies any of the conversational voice use cases is premature.

Implementers that choose not to use the best possible codec under common operating conditions (e.g. ridiculously low bitrates, which happens frequently in cellular environments) will suffer in the marketplace as a result.  But this is not an issue for standardization.

> Sure, go as low as you like. There's even codecs that work at 2 kb/s and below if you like. If both sides support it, it's all good. But when all we have in common are the MTI codecs, then please let's make webrtc not suck or (worse) fail completely.

No, it's not good.  2 kb/s codecs such as MELP are not toll quality.  Intelligibility alone may be OK for military applications, but toll quality is a requirement for consumer apps.

> I'm sure most people prefer 1) and I still don't understand why you would prefer option 2). Option 2) essentially means "we have a really crappy standard which can only work decently if you have extensions".

Implementers are expected to support more codecs than just whatever is MTI.  As Ted mentioned in another email, one of the goals of RTCWeb is promoting support for native codecs:

At 8:39 PM -0700 8/21/12, Ted Hardie <ted.ietf at gmail.com> wrote:
>  the fundamental design of RTCWEB allows for the  negotiation of any 
> codec mutually supported.  The decision to chose a  
> Mandatory-to-implement was not made to eliminate other choices, but to  
> eliminate interoperability failures by ensuring that at least one  
> common codec is always available.

Codecs should be MTI only to prevent negotiation failure, not to guarantee ideal performance, especially in light of Ted's next statement:

At 8:39 PM -0700 8/21/12, Ted Hardie <ted.ietf at gmail.com> wrote:
>  the group presumes that codec support does not  come from the 
> downloadable Javascript application, but from the  application 
> environment into which it is downloaded (commonly a  browser or mobile 
> environment using similar technology).  Promoting  support for those 
> environments to have access to codecs supported by  the underlying 
> hardware is the best way to further this goal, at least  in my 
> personal opinion.

Moreover, claiming that access to codecs such as AMR is only possible with software extensions ignores the installed base in the handheld market.  Developers can certainly have access to such implementations, and shouldn't have to burden themselves with implementing more codecs than minimally necessary because of MTI requirements.

-----Original Message-----
From: Jean-Marc Valin [mailto:[email-masked]] 
Sent: Thursday, August 30, 2012 6:43 PM
To: Mandyam, Giridhar
Cc: Harald Alvestrand; DRAGE, Keith (Keith); [email-masked]
Subject: Re: [rtcweb] RTCWEB needs an Internet Codec

On 08/30/2012 08:18 PM, Mandyam, Giridhar wrote:
> I don't follow. If both parties in the call support a codec suitable 
> for 6 kb/s (e.g. AMR-NB) then there should be no negotiation failure. 
> MTI still allows for non-MTI codecs to be used on a WebRTC call.  The 
> point I was trying to make was that Opus does not satisfy the use case 
> as specified.  I never said that
> G.711 satisfied this use case. I believe it is unrealistic to require 
> that the set of MTI audio codecs (whatever they may be) satisfy every 
> single use case as currently outlined.

Here's the thing. I'm not trying to prevent you from including AMR-NB or any other codec. If all you have is 6 kb/s and you have AMR-NB on both ends, then by all means use that. But what if that's not the case and only one side supports it? If only G.711 is MTI, then the negotiation *fails*. And it won't just fail at 6 kb/s. It'll fail all the way up to 64 kb/s and that's unacceptable. OTOH, if you have Opus as MTI, you'll still be able to talk, which is big improvement, even if the quality isn't nearly as good as AMR-NB or EVRC-B at these ridiculously low bitrates. Essentially, I've yet to understand your reasoning that because Opus is "only" optimal for 99% of the use cases, then we should use something (G.711) that's highly suboptimal in all use cases.

> All the more reason to achieve toll quality at codec data rates below 
> 8 kbps when operating in a cellular environment.

Sure, go as low as you like. There's even codecs that work at 2 kb/s and below if you like. If both sides support it, it's all good. But when all we have in common are the MTI codecs, then please let's make webrtc not suck or (worse) fail completely.

> I've already stated my position on MTI audio codecs on this mailing 
> list.  I never advocated making every codec that is optimal given a 
> particular operating condition as MTI.  I also think the performance 
> loss due to the use of Opus at sub 10 kbps is not trivial, and it is 
> worth leveraging other codecs at these lower data rates.

So here's the options we're looking at in the cases where all you have in common are MTI codecs (and it seems that those will be common):
1) Optimal quality at almost all rates, but sub-optimal below 10 kb/s; or
2) Highly sub-optimal at 64 kb/s and above, with completely failure below 64 kb/s.

I'm sure most people prefer 1) and I still don't understand why you would prefer option 2). Option 2) essentially means "we have a really crappy standard which can only work decently if you have extensions".

	Jean-Marc

> [mailto:[email-masked]] Sent: Thursday, August 30, 2012 12:40 PM 
> To: Mandyam, Giridhar Cc: Harald Alvestrand; DRAGE, Keith (Keith); 
> means 16 kb/s worth of overhead anyway (with 20 ms frames). Even 
> though Opus is not optimal at 6 kb/s, we still have something that 
> works and we avoid interop failure. And what are the alternatives 
> anyway? If we only decide on G.711, then we not only have 
> embarrassingly bad quality, but we also have interop failure below 64 
> kb/s. If you want guaranteed good quality without Opus, you can also 
> make AMR-NB, AMR-WB, G.722.1C, AAC-LD, HE-AAC, and AAC-LC all MTI. 
> Then you'll have (on average) quality that's almost as good as Opus 
> alone can do, you'll cover almost as many use cases, and as a bonus, 
> you get all the negotiation and switching nightmares involved.
> 
> Jean-Marc
> 
>> Cc: [email-masked] Subject: Re: [rtcweb] RTCWEB needs an Internet 
>> Codec
>> 
>>>> Sent: 30 August 2012 11:56 To: [email-masked]

---

From: Tim Panton <[email-masked]>
Date: Fri, 31 Aug 2012 12:42:57 -0700

> In addition, I don't view all use cases as being of equal importance (at least with initial implementations).  Conversational voice over cellular must work for WebRTC. 
All use cases are equal, but some are more equal than others ?

I think it is a _huge_ mistake to assume we know what will be important use cases for webRTC. 
The use case you cite is _very_ well served by adding a tel: url to a mobile web page and placing a 2g gsm call.

Tim.

---

From: Jean-Marc Valin <[email-masked]>
Date: Fri, 31 Aug 2012 16:33:08 -0400

On 08/31/2012 01:23 PM, Roman Shpount wrote:
> One issue I want to bring into consideration is computation
> complexity of Opus. It is normally acceptable for end user devices
> in point-to-point calls (I do not want to start all the mobile
> device CPU vs battery live discussion. It is irrelevant), but in
> cases where you need to process all the calls on some sort of
> central server (such as conferencing, or virtual reality, or
> massive multi-player games) the additional processing cost of
> combination with  PLC and CN to save bandwidth) can be a valid
> compromise, since it can provide quality better then G.711 with CPU
> processing requirements order of magnitude less then Opus.

Actually, you're making a really good point about complexity on the
server side. One important feature in Opus is scalable complexity.
Sure you can use it in ways that eat a lot of CPU to fully optimize
quality, but you can also get good enough quality at much lower
complexity. I just ran a quick test on my two year-old laptop. Using
the unoptimized C reference implementation with a single core, I can
encode and decode at 40 kb/s (higher quality than G.722) 150 channels
in real-time. Using architecture-specific optimizations and both
cores, we should be able to handle about 500 channels on my poor
laptop. And that's assuming that we're actually decoding and
re-encoding all streams, which we'd never do. In a mixing case where
we're decoding all channels, but only encoding one, we end up with
1000 channels.

Oh, one feature I forgot to mention about Opus is that (unlike G722)
it's *really* cheap to figure out which channels are active without
having to decode everything. That alone should provide at least a 2x
saving (more for larger conferences). So we're now at 2000 channels on
my poor old laptop. I think a recent multi-core server should have
about 10x that power. Conclusion, the audio codec complexity will just
*not* be a problem.

	Jean-Marc

---

From: Jean-Marc Valin <[email-masked]>
Date: Fri, 31 Aug 2012 17:00:50 -0400

On 08/31/2012 01:25 PM, Mandyam, Giridhar wrote:
> I'm not sure I understand your logic either.  You could make the
> same argument in favor of having AMR-NB or EVRC-B as MTI.  Why not
> do so and cover 100% of the use cases?

Problem is that adding AMR-NB or EVRC-B would only prevent failure
below 64 kb/s, but still leave us with embarrassingly bad quality. On
the other hand, Opus will work (i.e. not fail) for all use cases, and
actually be optimal or near-optimal for the vast majority of these use
cases. Want slightly lower quality below 10 kb/s, go ahead and
implement AMR/EVRC, but at least you're guarantee the call will not
fail if it's not implemented.

	Jean-Marc

---

From: Randall Gellens <[email-masked]>
Date: Fri, 31 Aug 2012 15:09:10 -0700

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

-------------- Randomly selected tag: ---------------
One never sits in hotel lobby chairs, my dear.  One never knows whom
has been sitting in them before one.
    --unknown

---

From: Gregory Maxwell <[email-masked]>
Date: Fri, 31 Aug 2012 15:35:02 -0700

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

And then end up with a specification which is not actually interoperable for but a fraction of the well known intended applications.

---

From: Stefan Hacker <[email-masked]>
Date: Sat, 01 Sep 2012 01:15:31 +0200

> We can pick G.711 as MTI and rely on implementers to support others.
Imho this would be a big mistake. Even if implementers were to pick up 
Opus as quasi MTI after the fact, which I'm not convinced would reliably 
happen, this would critically damage the abilities of RTCWEB at launch.

Remember that the first implementations are not likely to venture far 
into "recommended" territory and for many Opus is still an unknown no 
matter its credentials and advantages.

Opus as an MTI offers the chance to make RTCWEB worth, even desirable, 
using Out-Of-The-Box for the majority of the intended use-cases. It 
ensures implementers have a codec at their hands that not only 
guarantees interoperability but also lets them pick the best possible 
quality, be it for low/high bandwidth or CPU or latency.

Regards,
Stefan

---

From: Ron <[email-masked]>
Date: Sat, 1 Sep 2012 12:49:55 +0930

> I want to push Opus and promote its use, but MTI is not the right method

I haven't got the impression from this discussion that anybody thinks it
is about "pushing Opus" at all.  The question is what is best for rtcweb.

Since the charter of this group is to produce a standard that facilitates
"direct interactive rich communication", using things that already exist
as much as possible - I thought it was clear that the only important point
is that all this engineering work to produce rtcweb should not be a complete
waste of time for the people actually implementing it, and produce something
that gives such a poor experience in its baseline configuration that nobody
would ever actually want to use it for any of its intended purposes.

That Opus is a very obvious choice of existing technology, which no other
single codec comes anywhere close to matching for this purpose, stands out
like an elephant in the room.  Blind men might argue about whether it is a
pillar or a brush, or whether enough double blinded men have yet touched it
to be sure of this, but no amount of "pushing" is going to realistically
move it from that position one way or the other.

Pretending that other much-poorer codecs could fill this role is abandoning
the "rich communication" part of the charter, and condemning this group to
an embarrassing failure to achieve its goals in any meaningful way.

Let's not do that shall we.  It seems quite clear that many people have an
intense interest in its success.  Delaying this indefinitely, or selecting
poorer options than are already available today do not seem like the choices
that rational people who actually do want this to succeed would make.

Interoperability requires an adequate MTI codec.  Nobody has proposed an
alternative codec that is not clearly inadequate by comparison to Opus.
In a room full of clever engineers who want rtcweb to excel as a best of
breed specification, this decision should be a total no-brainer.

This time would be much better spent on the Actually Hard questions that
still remain for rtcweb.

 Best,
 Ron

---

From: Basil Mohamed Gohar <[email-masked]>
Date: Fri, 31 Aug 2012 23:42:14 -0400

> This time would be much better spent on the Actually Hard questions that
+1, I couldn't have expressed myself any better than this, personally.

-- 
Libre Video
http://librevideo.org

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 31 Aug 2012 21:38:11 -0700

> breed specification, this decision should be a total no-brainer.

MTI is not about a room full of clever engineers, this thread and the
position statements from XYZ companies should make that clear.  MTI is
about the least common denominator for a series of latent issues,
including IPR FUD and legacy baggage.

Consenting adults are free to offer and answer whatever codecs they like.

CB

---

From: Ron <[email-masked]>
Date: Sat, 1 Sep 2012 15:42:36 +0930

> about the least common denominator for a series of latent issues,

Yes, and least common denominator here doesn't mean "the worst possible
codec that we can think of which might be called a codec".  Nobody has
proposed any credible alternative to Opus that might reasonably be seen
as a plausible common denominator to a broad spectrum of the use cases.

Opus doesn't just simply cover that range.  It trounces pretty much every
other codec across the whole spectrum, except for a tiny little corner of
the extreme low-bandwidth case, where it's marginally worse than something
which already sounds terrible.

When your least common denominator also happens to be the best of breed
across that whole range, that's a Good Thing right?  Something to thank
your lucky engineering stars for, not something to prevaricate about.

> including IPR FUD and legacy baggage.

FUD has no place here whatsoever, however popular it might be.
Legacy baggage is a "will consider" item in the group charter, not a
"will be stupidly constrained by to the detriment of the project".

> Consenting adults are free to offer and answer whatever codecs they like.

Yes.  Yes, they are.  And nobody has said or is saying they can't do so.

It's also not the question here.  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).

If the answer to that is "something terrible", then it's like suggesting
that "Consenting adults are free to put wheels on their car".

Of course they are, but it will be pretty useless for its intended purpose
without them - and nobody in their right mind would make something like
that deliberately.

 hth,
 Ron