Re: [codec] #16: Multicast?

"Christian Hoene" <> Tue, 11 May 2010 18:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5198828C227 for <>; Tue, 11 May 2010 11:46:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.483
X-Spam-Status: No, score=-3.483 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_50=0.001, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JuHY+TXs0zvP for <>; Tue, 11 May 2010 11:46:12 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9D3E728C1E5 for <>; Tue, 11 May 2010 11:45:56 -0700 (PDT)
Received: from hoeneT60 ([]) (authenticated bits=0) by (8.13.6/8.13.6) with ESMTP id o4BIjPhA007729 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 11 May 2010 20:45:31 +0200
From: Christian Hoene <>
To: 'Koen Vos' <>
References: <> <> <> <> <> <000001cae173$dba012f0$92e038d0$@de> <> <001101cae177$e8aa6780$b9ff3680$@de> <> <002d01cae188$a330b2c0$e9921840$@de> <> <> <> <002c01cae939$5c01f400$1405dc00$@de> <>, <009901caede1$43f366d0$cbda3470$@de> <> <CB68DF4CFBEF4942881AD37AE1A7E8C74B90345C0D@IRV! ! E XCHCC... <127344193 9.> <> <006101caf117$aaf3b2c0$00db1840$@de>
In-Reply-To: <006101caf117$aaf3b2c0$00db1840$@de>
Date: Tue, 11 May 2010 20:45:24 +0200
Message-ID: <00ac01caf13a$21f741d0$65e5c570$@de>
MIME-Version: 1.0
Content-Type: multipart/related; boundary="----=_NextPart_000_00AD_01CAF14A.E58011D0"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acrw0m8GNXZpDck0Qjy3nWpGN9Rz1gAQeaxwAAio1BA=
Content-Language: de
X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.0.0-4; spam filter version: 3.0.0/2.0; host: mx05)
X-AntiVirus: checked by Avira MailGate (version: 3.0.0-4; AVE:; VDF:; host: mx05); id=5136-P8aefP
Subject: Re: [codec] #16: Multicast?
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Codec WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 11 May 2010 18:46:21 -0000

Sorry, for the lacking description. I added some more information into the email.


From: [] On Behalf Of Christian Hoene
Sent: Tuesday, May 11, 2010 4:39 PM
To: 'Koen Vos'
Subject: Re: [codec] #16: Multicast?




may I present some results of the ITU-T SG12 on the perceptual effects of delay?

For many years, it was assumed that 150ms is the boundary for interactive voice conversations (see Nobuhiko Kitawaki, and Kenzo
Itoh: Pure Delay Effects on Speech Quality in Telecommunications, IEEE J. on Selected Areas in Commun., Vol.9, No.4, pp.586-593, May
1991) Until 400ms quality is still acceptable (about toll quality). The ITU-T G.107 quality model reflects this opinion.

However, in the recent years, new results have shown that the impact of delay on conversation quality is NOT as strong as assumed.
At the ITU-T, numerous contributions have been made on this issue:

Contribution of BT “Comparison of E-Model and subjective test data for pure-delay conditions” from 2007-01-08:

Link  <>

The conversational tests were done in controlled environments with nine pairs of subjects. Two subjects had the common tasks of
their set of sorting pictures in the same order. Other conditions: No echos, G.711, no frame loss



MOS-CQS are subjective conversational tests

MOS-CQE is the E-Modell (G.107)

MOS-LQO are result from PESQ.

The delay is a one-way delay. Beside MOS values, they also studied the subjective rating of percentage difficultly (%D). Starting at
about 150ms is goes up at reaches 35% at 900ms. After that it remains constant.


Also, LM Ericsson described very interesting results in “Investigation of the influence of pure delay, packet loss and audio-video
synchronization for different conversation tasks” from 2007-09-24. 


For example: The done conversational tests similar to ITU-T P.805. The conversation lasted about 3 to 5 minutes. 11 pairs of experts
were taken part.


The tasks at 160ms were done about 50s faster than the same task at 600ms


And in the second tests about 60 naïve subjects and experts were taken part to solve a conversational task.


If they were asked for interactivity the ratings look worse.


Overall, it seems that the limit of 150ms is greatly overestimated. A much relaxed timing is allowed.

Seeing these figures, I have to assume that the ITU-T G.107 standard was a plot of the telcos to make life of VoIP vendors hard.
Well done...


Hopefully, I will not get trouble because of providing these information.

With best regards,


 Christian Hoene






Dr.-Ing. Christian Hoene

Interactive Communication Systems (ICS), University of Tübingen 

Sand 13, 72076 Tübingen, Germany, Phone +49 7071 2970532



>-----Original Message-----

>From: [] On Behalf Of Koen Vos

>Sent: Tuesday, May 11, 2010 8:23 AM

>To:; Benjamin M. Schwartz


>Subject: Re: [codec] #16: Multicast?


>Quoting Benjamin M. Schwartz:


>> Quoting Koen Vos <>:

>>> For typical VoIP applications, Moore's law has lessened the pressure

>>> to reduce bitrates, delay and complexity, and has shifted the focus to

>>> fidelity instead.


>> I think this is a typo, and you mean "lessened the pressure to

>> reduce bitrates and complexity, and has shifted the focus to

>> fidelity and delay instead".


>Not a typo: codecs have become more wasteful with delay, while

>delivering better fidelity.  G.718 evolved out of AMR-WB and has more

>than twice the delay.  Same for G.729.1 versus G.729.  This is not by



>The main rationale for codec delay being less important today is that

>faster hardware has reduced end-to-end delay in every step along the

>way.  As a result, a typical VoIP connection now operates at a flatter

>part of the "impairment-vs-delay" curve, meaning that reducing delay

>by N ms at a given fidelity gives a smaller improvement to end users

>today than it did some years ago.  Therefore, the weight on minimizing

>delay in the "codec design problem" has gone down, and the optimum

>codec operating point has naturally shifted towards higher delay, in

>favor of fidelity.


>I've mentioned before that average delay on Internet connections seems

>to be 40% to 50% lower now than just 5 years ago, which is just one

>contributor to lower end-to-end delay.  That doesn't mean high-delay

>connections don't exist - they do, for instance over dial-up or 3G.

>But in those cases it's still better to use a moderate packet rate

>(and bitrate), to minimize congestion risk.


>The confusion may come from the fact that the trade-off between

>fidelity and delay changes towards high quality levels: once fidelity

>saturates, delay gets priority.  Even more so because such high

>fidelity enables new, delay-sensitive applications like distributed

>music performances.  This is reflected in the ultra-low delay

>requirements in the requirements document.


>To summarize, the case for using sub-20 ms frame sizes with

>medium-fidelity quality is now weaker than ever, because the relative

>importance of fidelity has gone up.





>codec mailing list