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

[Tim Panton <[e-mail]>]

On 24 Dec 2012, at 10:52, Roman Shpount wrote:

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

Perhaps ;-)

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

How? by dipping into the SDP or with an API ? - see my point 4) 

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

And almost every one of them got this wrong the first time, and then had a regression 6 months later. Lets admit it - it's a mess.

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

Ah. now there we disagree. We can run opus over lossy Edge but not g722 - many people's only internet connection is Edge at best.
On the other side if I'm on a 50Mbps fibre I'll still only get 64kb/s 722 quality even though I could have been in CELT stereo. Non adaptable codecs
aren't fit for the modern internet (IMHO). (- I also voted against 711 being mandatory for exactly that reason).

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

I sorry, I forgot that - do all those legacy endpoints actually implement that?

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

Agreed. I'm not saying implementors cant add it. I just say the standard shouldn't even recommend something that isn't even close to the best we can do.

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

Interesting - I can't think of many full ICE clients that do SRTP and g722 and not opus - Jitsi perhaps - but that couldn't swallow chrome's SDP last 
I tried. My experience with legacy interop is that you _always_ need a gateway.

If the consensus is to make (non-dtls) SRTP support mandatory I might change my mind I suppose.


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

I can't agree that the reasons were about political appearance. Speaking purely for myself they were about security and quality. 
Phonefromhere was a start-up that built webrtc-like functionality into browsers (using a java applet). So we have quite a bit of experience of
what worked and what didn't - my views are shaped by that experience and that of running a security startup westpoint.ltd.uk .  

What works for the deskphone on a managed secure LAN does not necessarily work for someone in a cafe in India on the wi[l]der internet.

T.