Re: [rtcweb] RTCWEB needs an Internet Codec

["Mandyam, Giridhar" <[e-mail]>]

>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:[e-mail]] 
Sent: Thursday, August 30, 2012 6:43 PM
To: Mandyam, Giridhar
Cc: Harald Alvestrand; DRAGE, Keith (Keith); [e-mail]
Subject: Re: [rtcweb] RTCWEB needs an Internet Codec

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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:[e-mail]] Sent: Thursday, August 30, 2012 12:40 PM 
> To: Mandyam, Giridhar Cc: Harald Alvestrand; DRAGE, Keith (Keith); 
> [e-mail] 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
>> 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: [e-mail] 
>> [mailto:[e-mail]] On Behalf Of Harald Alvestrand
>> Sent: Thursday, August 30, 2012 5:51 AM To: DRAGE, Keith (Keith)
>> Cc: [e-mail] Subject: Re: [rtcweb] RTCWEB needs an Internet 
>> Codec
>> 
>> On 08/30/2012 02:38 PM, DRAGE, Keith (Keith) wrote:
>>> 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.
>> 
>>> 
>>> 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: [e-mail] 
>>>> [mailto:[e-mail]] On Behalf Of Harald Alvestrand 
>>>> Sent: 30 August 2012 11:56 To: [e-mail]
>>>> 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.
>>>> 
>>>> This includes all applications involving music.
>>>> 
>>>> On 08/29/2012 06:30 PM, Randall Gellens wrote:
>>>>> 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.
>>>>> 
>>>> _______________________________________________ rtcweb mailing list 
>>>> [e-mail] https://www.ietf.org/mailman/listinfo/rtcweb
>> 
>> _______________________________________________ rtcweb mailing list 
>> [e-mail] https://www.ietf.org/mailman/listinfo/rtcweb
>>  _______________________________________________ rtcweb mailing list 
>> [e-mail] https://www.ietf.org/mailman/listinfo/rtcweb
>> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQEcBAEBAgAGBQJQQBapAAoJEJ6/8sItn9q9pioH/iR6CTa6iLdN3wkuK5O1XbsI
/2JY3zqUaqlokaivWZzl0imCN5Rnkfl9Y7l3kyeBPXv6P++VJ5HG/9xTX9Pm+OKE
HNEI4nE5npiA+A5FoDqR2rcHprj2hPjRM3J62uFgxk9Kof4onQTMG87AUCAUciyN
aBfrzDVBiSz68Ha51yYM5oOHiZzBHRW9Ysccbf6DrkzzcuKoavs+OJ7bVaKSuc2I
4TsEdP33qJa+NHsOzCeFIZ6xmC/wSpF5/3oXNEaV/Mz5zUoTA2I1Cfr4G/vP/YIW
r4JMzPh+kwXJQ4Aawiv6eyP5KRI4hRkSkXoP7brfG+ZoVr44HKyGCnNywXYtXac=
=jjKQ
-----END PGP SIGNATURE-----