Re: [codec] #16: Multicast?

Hi Christian,

My comments about your question of CODEC requirements are in-line.

Raymond

From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Christian Hoene
Sent: Wednesday, April 21, 2010 12:27 PM
To: 'stephen botzko'
Cc: codec@ietf.org
Subject: Re: [codec] #16: Multicast?

Hi,

if we take those two scenarios (high quality and scalable teleconferencing), what are then the CODEC requirements?

High quality:

-          Quite the same requirement as an end-to-end audio transmission: high quality and low latency.
[Raymond]: High quality is a given, but I would like to emphasize the importance of low latency.
(1) It is well-known that the longer the latency, the lower the perceived quality of the communication link.  The E-model in the ITU-T Recommendation G.107 models such communication quality in MOS_cqe, which among other things depends on the so-called "delay impairment factor" Id.  Basically, MOS_cqe is a monotonically decreasing function of increasing latency, and beyond about 150 ms one-way delay, the perceived quality of the communication link drops rapidly with further delay increase.
(2) The lower the latency, the less audible the echo, and thus the lower the required echo return loss.  Hence, lower latency means easier echo control and simpler echo canceller, and as people already mentioned previously, below a certain delay, an echo is simply perceived as a harmless side-tone and no echo canceller is needed. It seems to me that echo control in conference calls is more difficult than in point-to-point calls.  While I hardly ever heard echoes in domestic point-to-point calls, in my experience with conference calls at work, even with the G.711 codec (which has almost no delay), sometimes I still hear echoes (I just heard another one this afternoon).  If a relatively long-delay IETF codec is used, the echo control will be even more problematic.
(3) In normal phone calls or conference calls, people routinely have a need to interrupt each other, but beyond a certain point, long latency makes it very difficult for people to interrupt each other on the call.  This is because when you try to interrupt another person, that person doesn't hear your interruption until a certain time later, so he keeps talking, but when you hear that he did not stop talking when you interrupted, you stop; then, he hears your interruption, so he stops. When you hear he stops, you start talking again, but then he also hears you stopped (due to the long delay), so he also starts talking again.  The net result is that with a long latency, when you try to interrupt him, you and he end up stopping and starting at roughly the same time for a few cycles, making it difficult to interrupt each other.
(4) We need to keep in mind that the IETF codec may not be the only codec involved in a phone call or a conference call.  We cannot assume that all conference call participants will be using a computer to conduct the call. Not only do people use cell phones for point-to-point phone calls, they also often use cell phones to call in to conference calls.  The one-way delay for a cell phone call through one carriers network is typically around 80 to 110 ms.  A call from a cell phone in a carrier network to another cell phone in a different type of carrier network can easily double this delay to 160 ~ 220 ms and makes the total one-way delay already far exceeding the 150 ms mentioned in (1) above.  Any coding delay added by the IETF codec will be on top of that long delay, and such coding delay will be applied twice when both cell phones call through the IETF codec to a conference bridge.  Even without the IETF codec delay, when I previously called from a Verizon cell phone to an AT&T cell phone, I already experienced the problem mentioned in (3) sometimes.  If the IETF codec has a relatively long delay, adding two times the IETF codec one-way delay to the already long delay of 160 ~ 220 ms will make the situation much worse.  Even if just one cell phone is involved in a conference call, adding twice the one-way delay of a relatively long-delay IETF codec can still easily push the total one-way delay beyond 150 ms.
To summarize, my point is that to help reduce potential echo problems and to ensure a high-quality experience in such a conference call, the IETF codec should have a delay as low as possible while maintaining good enough speech quality and a reasonable bit-rate.

-          Maybe additionally: variable bit rate encoding to achieve a multiplexing gain at the receiver

-          and thus, a fast control loop to cope with variable bitrates on transmission paths.

-          Maybe stereo/multichannel support to send the spatial audio to the headphone or loudspeakers.

Scalable:

-          Efficient encoding/transcoding for multiple different qualities (at the conference bridge)
[Raymond]: I am not sure whether by "efficient", you meant coding efficiency or computational efficiency.  In any case, I would like to take this opportunity to express my view that although codec complexity isn't much of an issue for PC-to-PC calls where there are GHz of processing power available, the codec complexity is an important issue in certain application scenarios.  The following are just some examples.
1) If a conference bridge has to decode a large number of voice channels, mix, and re-encode, and if compressed-domain mixing cannot be done (which is usually the case), then it is important to keep the decoder complexity low.
2) In topology b) of your other email (IPend-to-transcoding_gateway-to-PSTNend), the transcoding gateway, or VoIP gateway, often has to encode and decode thousands of voice channels in a single box, so not only the computational complexity, but also the per-instance RAM size requirement of the codec become very important for achieving high channel density in the gateway.
3) Many telephone terminal devices at the edge of the Internet use embedded processors with limited processing power, and the processors also have to handle many tasks other than speech coding.  If the IETF codec complexity is too high, some of such devices may not have sufficient processing power to run it.  Even if the codec can fit, some battery-powered mobile devices may prefer to run a lower-complexity codec to reduce power consumption and battery drain.  For example, even if you make a Internet phone call from a computer, you may like the convenience of using a Bluetooth headset that allows you to walk around a bit and have hands-free operation.  Currently most Bluetooth headsets have small form factors with a tiny battery.  This puts a severe constraint on power consumption.  Bluetooth headset chips typically have very limited processing capability, and it has to handle many other tasks such as echo cancellation and noise reduction.  There is just not enough processing power to handle a relatively high-complexity codec.  Most BT headsets today relies on the extremely low-complexity, hardware-based CVSD codec at 64 kb/s to transmit narrowband voice, but CVSD has audible coding noise, so it degrades the overall audio quality.  If the IETF codec has low enough complexity, it would be possible to directly encode and decode the IETF codec bit-stream at the BT headset, thus avoiding the quality degradation of CVSD transcoding.
In summary, my point is that the IETF codec should attempt to achieve a codec complexity as low as possible in both MHz consumption and RAM size requirement while maintaining good enough speech quality.

-          The control loop must not react (fast) because (multicast) group communication requires to encode at low quality anyhow.

-          Receiver side activity detection for music and voice having low complexity (for the conference bridge)

-          Efficient mixing of two to four(?) active flows (is this achievable without the complete process of decoding and encoding again?)

Are any teleconferencing requirements missing?

 Christian

---------------------------------------------------------------
Dr.-Ing. Christian Hoene
Interactive Communication Systems (ICS), University of Tübingen
Sand 13, 72076 Tübingen, Germany, Phone +49 7071 2970532
http://www.net.uni-tuebingen.de/

From: stephen botzko [mailto:stephen.botzko@gmail.com]
Sent: Wednesday, April 21, 2010 8:19 PM
To: Christian Hoene
Cc: codec@ietf.org
Subject: Re: [codec] #16: Multicast?

Inline
On Wed, Apr 21, 2010 at 1:27 PM, Christian Hoene <hoene@uni-tuebingen.de<mailto:hoene@uni-tuebingen.de>> wrote:
Hi Stephen,

not too bad. You answered faster than the mailing list distributes...
Not sure how that happened!