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

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

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.

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.

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.

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.

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.

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.

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.

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!

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:[e-mail]]<mailto:[mailto:[e-mail]]>
Sent: Thursday, August 16, 2012 2:41 AM
To: Mandyam, Giridhar
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [rtcweb] Qualcomm's Position on Mandatory-to-Implement Audio Codecs for RTCWeb


On 15 Aug 2012, at 14:48, Mandyam, Giridhar wrote:


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.

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

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

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


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 revisions or extensions.  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.




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