Re: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Codecs

[Tim Panton <[e-mail]>]

Looks like I'll be a lone voice again.

I'm against any recommendation of use of g722 in webRTC 
If implementers want to provide it that's fine but it should not be in the standard.
Even if it is available it always be at a lower preference than Opus

g722 has several disadvantages over Opus and no real advantages.

1) The spec for g722 contains a historical error, so it's sample rate gets 
declared as 8khz even though it is actually 16khz - this means that the rtp/audio processing code is
littered with if( codec == CODEC_G722) {} else {} clauses to try and implement this mistake.
I've seen g722 mis-implemented more often than any other codec.

2) g722 is a fixed rate codec - it uses 64kbits/sec irrespective of what is available - it won't play nice with any
congestion management that is specified with webRTC

3) g722 sounds ok  (despite using 14 or the available 16 bits)
- provided there is no packet loss - it has no built in FEC or PLC modes, so falls apart 
at quite low loss levels (especially compared to opus).

4) if we mandate g722 then we need to make some  methods  in the constraints API to ensure
that 2 browser endpoints that say they want wideband don't get g722 when they could both be doing opus in
full CELT mode for the same bandwidth.


The often stated advantage is that there are many existing g722 endpoints out there. This is
irrelevant - there is only 1 platform I know of that implements ICE+DTLS-SRTP and g722 but not opus 
(asterisk for the curious and there's an opus patch available). 
 

Tim.