Re: [rtcweb] RTCWEB needs an Internet Codec

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

> 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:[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
>