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

["Roy, Radhika R CIV USARMY (US)" <[e-mail]>]

Classification: UNCLASSIFIED
Caveats: NONE

Hi, all:

A good assessment - thanks to Roman. 

So, the transcoding cost is enormous from both performance and HW/SW
implementation point of view.

In the end it may so appear that we are not hearing each other.

BR/Radhika

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
Roman Shpount
Sent: Thursday, January 17, 2013 5:32 AM
To: Martin Thomson
Cc: [e-mail]
Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus
Regarding Selecting Recommended Audio Codecs)


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

Classification: UNCLASSIFIED
Caveats: NONE