Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended Audio Codecs)

[Roman Shpount <[e-mail]>]

On Wed, Jan 16, 2013 at 7:03 PM, Martin Thomson <[e-mail]>wrote:

> If we don't say "webrtc implementations SHOULD implement
> G.722/AMR/AMR-WB", what is the failure mode for your application?
> Keeping in mind that - because this isn't 2119 MUST - you have to
> expect that some non-negligible proportion of clients will not support
> this no matter how much extra ink we using in printing large letters,
> how much pain does this really cause you?
>
> I expect that the transcoding costs are what this come down to.  Does
> anyone care to quantify this?
>

If common codecs are not implemented in the browser this would mean
transcoding will need to be performed on some sort of server-side media
gateway. There are three distinct issues we need to take into account when
dealing with transcoding. I would list them in what, at least from my point
of view, is the order of importance:

1. If you need to do trancoding, you will need to implement a jitter buffer
on the transcoding media gateway. ICE processing and SRTP en/decoding can
be performed on out of order packets as they are received. You cannot
transcode out of order audio. This means audio packets would need to be
delayed by the jitter buffer size. In cases of good internet connection
this means 40 ms jitter buffer delay. In cases of consumer internet in US
(somebody sitting on a DSL connection at home behind a WiFi router) you are
typically looking at 60-80 ms jitter buffer delay. If you are dealing with
international internet connections jitter of 150 ms to 200 ms is not
unheard of. This means an additional delay due to jitter buffering of 40 ms
(best case) to 200 ms. This is in addition to any other delays that are
already present on the audio path. Adding an extra 100 ms of delay can make
audio conversions very awkward or unusable. On the other hand, if the
gateway were performing just ICE and SRTP, it would introduce 1-2 ms of
delay at most (In this case I am talking about a software based
implementation running on generic server hardware. A dedicated DSP solution
would probably be even faster).

2. Audio artifacts due to transcoding. Apart from usual audio degradation
due to transcoding (OPUS transcoded to AMR would sound worse then OPUS or
AMR), we would also deal with double packet loss concealment. Media gateway
will conceal lost packets when transcoding. Client will conceal lost packet
received from the gateway. This would actually sound worse then PLC
performed in one place.

3. Scalability of the transcoding gateway. Gateway which just deals with
ICE processing and SRTP en/decoding can handle from 2000 to 10000
concurrent call when running on a generic server CPU (different scalability
is due to differences in CPU performance and presence of AES specific
instructions). Gateway that would do G.722 to OPUS transcoding would most
likely handle from 500 to 1000 concurrent calls. We are looking at 10x
difference in performance. If we need to transcode AMR to OPUS the
difference would be even higher. This translates in 10x difference in
hardware, data center, power, and operations costs.
_____________
Roman Shpount