Subject: [rtcweb] Qualcomm's Position on Mandatory-to-Implement Audio Codecs for RTCWeb

From: "Mandyam, Giridhar" <[email-masked]>
Date: Wed, 15 Aug 2012 13:48:17 +0000

Hello All,
Qualcomm is in favor of G.711 being the only mandatory-to-implement codec for RTCWeb.  We do not support having both Opus and G.711 as mandatory-to-implement codecs.  We state the following reasons:

a)      There is no technical need to have an audio codec besides G.711 be designated as mandatory to implement.  Because RTCWeb uses SDP to negotiate the codecs, the only reason to have anything as mandatory is to make sure there is always at least one codec that both sides can use, a lowest common denominator.  This allows the market to decide which codecs to support, rather than edict from a standards body.  Implementations can base their choice of which codec to support based on what they are trying to optimize.  For example, better performance for the environment at the time of the session, such as cell phone or desktop.

b)      G.711 is universal, unencumbered, and widely implemented.    In addition, note that codec implementation and testing is quite costly for chip and device manufacturers, and that cost is ultimately reflected in the cost of the end-user device.  The computational simplicity of G.711 and its long-time availability on a broad range of platforms means that the implementation is available on low/entry-tier devices and testing costs have already been amortized over many years, thereby enabling its use in low cost end-user devices.  If we want to see widespread use of RTCWeb for voice, than we will reach a much broader population if the minimum requirements do not prohibit low-cost devices.

c)       A mandate for Opus will limit initial RTCWeb clients to use software-based  codecs (on general purpose processors) where Opus can be implemented and tested easily until it is available on a variety of DSPs.  Even then, it will likely start on high-cost platforms.  This may in turn mean that RTCWeb clients could consume significantly more battery power than DSP-based codecs used in many traditional (circuit-switched) voice services, further inhibiting the end-user from choosing RTCWeb over those services.

d)      We do not believe Opus is more versatile than other standardized codecs, because any measure of versatility should take into account quality at a given bitrate.  If Opus is not able to deliver superior quality at all supported bitrates when compared to other codecs, then it cannot be deemed as being more versatile simply because it supports more bitrates when compared to other standardized codecs.

In conclusion - the IETF has a strong tradition of starting work with the least amount of complexity and specification possible, gaining operational experience, and then refining things with revisions or extensions.  So, the least amount of complexity would be G.711 as the sole audio codec.

---

From: Tim Panton <[email-masked]>
Date: Thu, 16 Aug 2012 10:40:53 +0100

> a)      There is no technical need to have an audio codec besides G.711 be designated as mandatory to implement.  Because RTCWeb uses SDP to negotiate the codecs, the only reason to have anything a…

I made exactly the same argument about H261 and was told (correctly) that it was unacceptable to mandate a codec that would give users a
poorer than necessary experience. I think what applies for video applies for audio.

Specifically g711 is a poor codec choice in a wide variety of network situations - e.g. 3g and edge of wifi. In my experience a lower bandwidth
codec which supports wideband, dynamically variable bitrates and error correction / packet loss concealment is required to give these users audio
that is acceptable to use in the  coffee-shop / airport scenario. 

> b)      G.711 is universal, unencumbered, and widely implemented.    In addition, note that codec implementation and testing is quite costly for chip and device manufacturers, and that cost is ulti…

There are many codecs which that can be said for. We happily run speex on low end smartphones. - Heck we even use the java implementation in
applets and get acceptable performance. g722 has recently dropped out of patent, uses the same bandwidth as 711 and gives significantly better audio.
Any device capable of running SRTP is capable of running either 722 or speex in my experience. 

> c)       A mandate for Opus will limit initial RTCWeb clients to use software-based  codecs (on general purpose processors) where Opus can be implemented and tested easily until it is available on…

You are confusing mandatory-to-implement and mandatory-to-use. Just because Opus must be available , you don't have to use it. The devices you 
mention almost all have AMR in DSP - but unfortunately that is encumbered so isn't ideal as a mandatory-to-implememnt codec but may well be 
used when it is available. 

> d)      We do not believe Opus is more versatile than other standardized codecs, because any measure of versatility should take into account quality at a given bitrate.  If Opus is not able to deli…

Again - making Opus mandatory to implement does not preclude supporting or using any other codecs. 

By the way point d) applies to any codec you choose to name - so you are probably arguing for no mandatory-to-implement codec - which would be
a mistake I think. It certainly applies to g711 - in spades!

> In conclusion - the IETF has a strong tradition of starting work with the least amount of complexity and specification possible, gaining operational experience, and then refining things with revisi…

RTCweb is never going to be a _least_possible_complexity_ project. The requirements mean we need  SRTP (DTLS?), a video modern codec, Echo cancellation, AGC, etc. Adding a good audio codec will not significantly extend the complexity.

> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: "Mandyam, Giridhar" <[email-masked]>
Date: Mon, 20 Aug 2012 03:26:02 +0000

Hello Tim,
Thank you for your well-thought out reply.  Please note that I was using the options presented in the straw poll conducted on mandatory-to-implement (MTI) audio codecs at the RTCWeb meeting in Vancouver IETF 84 as the basis for this position statement.  Since I have not seen official RTCWeb minutes from that meeting yet, I will have to reproduce from memory the voting options presented to the attendees:  (1) G.711 only for MTI, (2) G.711 and Opus only for MTI, and (3) Opus only for MTI.  Based on Cullen's email from last week, I assume that the call for consensus is still around these three options alone.

Can you clarify what you would suggest as an alternative?  If one is willing to concede that Opus is not the best audio codec for many lower bandwidth situations (which is depicted in http://www.opus-codec.org/comparison/), then "poorer than necessary" would seem to point to mandating the codec that provides best-in-class performance at a given operating condition.  This would provide optimal user experience but would also lead to many codecs being designated as MTI.

Sorry to request clarification again, but do you believe G.722 should be re-examined as an MTI option?  Based on my understanding, .722 is not considered in the current call-for-consensus (although other participants have suggested it as well).  If we are to open up such a debate, it would be helpful if you could provide quantitative data backing your position.

That was not my intention - maybe my original wording was unclear.  It is a burden on app developers to have to provide SW-based Opus libraries if Opus is not available natively on the HW platforms they are targeting.  They will have to do this if Opus is MTI.  They will also have to optimize their SW-based implementation for each target HW platform, which also is costly.

And not having Opus as MTI does not preclude its use either.  If we assume the "poorer than necessary" criterion over a wide range of operating conditions as a prerequisite for MTI, then neither Opus nor G.711 are adequate.  With G.711 as the sole MTI audio codec, implementations are free to negotiate the best possible user experience given the environment at the moment and what each side supports.

From: Tim Panton [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Thursday, August 16, 2012 2:41 AM
To: Mandyam, Giridhar
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [rtcweb] Qualcomm's Position on Mandatory-to-Implement Audio Codecs for RTCWeb

Hello All,

_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: John Leslie <[email-masked]>
Date: Mon, 20 Aug 2012 12:26:26 -0400

Tim Panton <[email-masked]> wrote:
>> Qualcomm is in favor of G.711 being the only mandatory-to-implement
>> codec for RTCWeb.

   An otherwise valid argument is mortally wounded by this statement.
We participate as individuals in IETF Working Groups; and stating
something as a "position" tends to make others consign you to "the rough".

>> We do not support having both Opus and G.711 as mandatory-to-implement
>> codecs.  We state the following reasons:
>>  
>> There is no technical need to have an audio codec besides G.711 be
>> designated as mandatory to implement. Because RTCWeb uses SDP to
>> negotiate the codecs, the only reason to have anything as mandatory
>> is to make sure there is always at least one codec that both sides
>> can use, a lowest common denominator.

   Exactly true!

>> This allows the market to decide which codecs to support, rather than
>> edict from a standards body. Implementations can base their choice of
>> which codec to support based on what they are trying to optimize. For
>> example, better performance for the environment at the time of the
>> session, such as cell phone or desktop.

   The intended situation as RTCWEB matures is that the endpoints will
choose among a number of codecs which both support, taking into account
the characteristics of the link between them.

> I made exactly the same argument about H261 and was told (correctly)
> that it was unacceptable to mandate a codec that would give users a
> poorer than necessary experience.

   No, that is not "correctly"!

   It would be unacceptable to mandate the _use_ of a codec giving
sub-standard experience; but it is _exactly_ acceptable to mandate the
_implementation_ of a codec which gives "poorer than necessary
experience" in even a _majority_ of actual conditions.

   We certainly hope there will be better options available for
particular conditions; and we certainly hope that the conditions
available will improve.

> I think what applies for video applies for audio.

   Mostly true; but given a century of experience with audio-only
telephone use, there is perhaps wiggle-room for failure to agree on
a video codec. (What I mean here is that _if_ we can't find any video
codec that all RTCWEB stacks "can" implement, we could theoretically
fall back to a short list of SHOULD implement.)

> Specifically g711 is a poor codec choice in a wide variety of
> network situations - e.g. 3g and edge of wifi.

   True, but that's the wrong consideration. A mandatory-to-implement
codec isn't asked to give "good" results in every case.

> In my experience a lower bandwidth codec which supports wideband,
> dynamically variable bitrates and error correction / packet loss
> concealment is required to give these users audio that is acceptable
> to use in the coffee-shop / airport scenario. 

   That's a good argument; but it goes beyond the target we're aiming
for as "mandatory-to-implement".

>> G.711 is universal, unencumbered, and widely implemented. In addition,
>> note that codec implementation and testing is quite costly for chip
>> and device manufacturers, and that cost is ultimately reflected in
>> the cost of the end-user device. The computational simplicity of
>> G.711 and its long-time availability on a broad range of platforms
>> means that the implementation is available on low/entry-tier devices
>> and testing costs have already been amortized over many years,
>> thereby enabling its use in low cost end-user devices.

   This is also a good argument; and it is pretty much on-target.

>> If we want to see widespread use of RTCWeb for voice, than we will
>> reach a much broader population if the minimum requirements do not
>> prohibit low-cost devices. 

   This is a weaker argument, but still appropriate IMHO.

> There are many codecs which that can be said for. We happily run
> speex on low end smartphones. - Heck we even use the java
> implementation in applets and get acceptable performance. g722 has
> recently dropped out of patent, uses the same bandwidth as 711 and
> gives significantly better audio. Any device capable of running
> SRTP is capable of running either 722 or speex in my experience. 

   And this is a good counter-argument...

>> A mandate for Opus will limit initial RTCWeb clients to use
>> software-based codecs (on general purpose processors) where Opus
>> can be implemented and tested easily until it is available on a
>> variety of DSPs. Even then, it will likely start on high-cost
>> platforms.

   I find this argument weak. I would expect any RTCWEB device to
need to _start_ on this path.

>> This may in turn mean that RTCWeb clients could consume
>> significantly more battery power than DSP-based codecs used in
>> many traditional (circuit-switched) voice services, further
>> inhibiting the end-user from choosing RTCWeb over those services.

   That's a valid argument; but it's about a commercial tradeoff,
and I don't see a good reason why we need to optimize for a particular
commercial environment.

> You are confusing mandatory-to-implement and mandatory-to-use.

   A lot of us seem to be suffering from that confusion!

> Just because Opus must be available, you don't have to use it.

   You _might_ have to use it... But it's only required as a last
resort, and it's perfectly reasonable to warn the end-user that
battery life will suffer.

> The devices you mention almost all have AMR in DSP - but
> unfortunately that is encumbered so isn't ideal as a
> mandatory-to-implememnt codec but may well be used when it is
> available. 
> 
>> We do not believe Opus is more versatile than other standardized
>> codecs, because any measure of versatility should take into account
>> quality at a given bitrate. If Opus is not able to deliver superior
>> quality at all supported bitrates when compared to other codecs,
>> then it cannot be deemed as being more versatile simply because it
>> supports more bitrates when compared to other standardized codecs.

   This is a straw-man. :^(

>> In conclusion - the IETF has a strong tradition of starting work
>> with the least amount of complexity and specification possible,
>> gaining operational experience, and then refining things with
>> revisions or extensions.

   That's not as true as it used to be. :^(

>> So, the least amount of complexity would be G.711 as the sole
>> audio codec.
> 
> RTCweb is never going to be a _least_possible_complexity_ project.
> The requirements mean we need SRTP (DTLS?), a video modern codec,
> Echo cancellation, AGC, etc. Adding a good audio codec will not
> significantly extend the complexity.

   This thread is full of good arguments!

   I hope we will contiue it, but hold a little better to what we
mean by "mandatory-to-implement".

--
John Leslie <[email-masked]>