Re: [rtcweb] RTCWEB needs an Internet Codec

[Jean-Marc Valin <[e-mail]>]

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