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

[Burger Eric <[e-mail]>]

So the argument here is the cost to the user is USD 0.0000001/call instead of USD 0.00000001/call?

On Jan 17, 2013, at 8:14 AM, Stefan Håkansson LK <[e-mail]> wrote:

> On 2013-01-17 11:31, Roman Shpount wrote:
>> 
>> On Wed, Jan 16, 2013 at 7:03 PM, Martin Thomson
>> <[e-mail] <mailto:[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.
> 
> This was a good summary. I'm mostly concerned with the quality degradations experienced by the end user and less about the cost (on the other hand, I guess this would in the end hit the end users as well).
> 
> I think having a 'SHOULD' for a few additional codecs would reduce the number of end users impacted by the degradations (and cost) mentioned, and I think that would make a lot of sense.
> 
> Stefan
> 
>> _____________
>> Roman Shpount
>> 
>> 
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>> 
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb