[rtcweb] Mandatory-to-Implement Audio Codecs for RTCWeb

[John Leslie <[e-mail]>]

Tim Panton <[e-mail]> wrote:
> On 15 Aug 2012, at 14:48, Mandyam, Giridhar 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. :^(

> Again - making Opus mandatory to implement does not preclude
> supporting or using any other 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.

   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 <[e-mail]>