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

[Roman Shpount <[e-mail]>]

On Mon, Dec 24, 2012 at 5:25 AM, Tim Panton <[e-mail]> wrote:


> Looks like I'll be a lone voice again.
>

And I thought I was the lonely voice of reason saying exactly the opposite.


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

I agree it should be lower preference by default, but the application
developer can change this if needed.


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

I've seen more G722 implementations then of any other wide band codec. In
fact this is the most commonly implemented and used wideband codec right
now, may be with an exception of SILK.


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

So does G.711, but it still supported for interop reasons. In most cases
64kbps is little enough not to worry about it.


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

That is simply not true. PLC for G.722 is defined in Appendixes III and IV.
It is not as good as OPUS but it is acceptable.


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

This should be up to the application developers, not a standard comity.  By
default OPUS should have higher preference.


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

It is not irrelevant. If SRTP is supported there are a lot of end points
that support ICE+SRTP+G.722.

P.S. A saner, more conservative approach would have been to make G.722 a
MUST and OPUS a SHOULD. Unfortunately, this ship has sailed together with
such things like support of plain RTP, due to worrying about political
appearences first and stable product later.