Re: [codec] #16: Multicast?

"Christian Hoene" <hoene@uni-tuebingen.de> Tue, 11 May 2010 14:39 UTC

Return-Path: <hoene@uni-tuebingen.de>
X-Original-To: codec@core3.amsl.com
Delivered-To: codec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC3A93A698A for <codec@core3.amsl.com>; Tue, 11 May 2010 07:39:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.459
X-Spam-Level:
X-Spam-Status: No, score=-3.459 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_50=0.001, HELO_EQ_DE=0.35, HTML_IMAGE_RATIO_08=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xzLD8mlj7WHI for <codec@core3.amsl.com>; Tue, 11 May 2010 07:39:43 -0700 (PDT)
Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by core3.amsl.com (Postfix) with ESMTP id BFB133A6911 for <codec@ietf.org>; Tue, 11 May 2010 07:39:36 -0700 (PDT)
Received: from hoeneT60 ([178.2.215.148]) (authenticated bits=0) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id o4BEcf5e023269 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 11 May 2010 16:38:48 +0200
From: Christian Hoene <hoene@uni-tuebingen.de>
To: 'Koen Vos' <koen.vos@skype.net>
References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <D6C2F445-BE4A-4571-A56D-8712C16887F1@americafree.tv> <C0347188-A2A1-4681-9F1E-0D2ECC4BDB3B@csperkins.org> <u2x6e9223711004210733g823b4777y404b02330c49dec1@mail.gmail.com> <000001cae173$dba012f0$92e038d0$@de> <r2q6e9223711004211010gfdee1a70q972e8239fef10435@mail.gmail.com> <001101cae177$e8aa6780$b9ff3680$@de> <t2t6e9223711004211119i6b107798pa01fc4b1d33debf1@mail.gmail.com> <002d01cae188$a330b2c0$e9921840$@de> <CB68DF4CFBEF4942881AD37AE1A7E8C74AB3F4A017@IRVEXCHCCR01.corp.ad.broadcom.com> <4BD11C50.2020206@usherbrooke.ca> <CB68DF4CFBEF4942881AD37AE1A7E8C74AB3F4A287@IRVEXCHCCR01.corp.ad.broadcom.com> <002c01cae939$5c01f400$1405dc00$@de> <CB68DF4CFBEF4942881AD37AE1A7E8C74B903454B3@IRVEXCHCCR01.corp.ad.broadcom.com>, <009901caede1$43f366d0$cbda3470$@de> <BCB3F026FAC4C145A4A3330806FEFDA93AB072BCC6@EMBX01-HQ.jnpr.net> <CB68DF4CFBEF4942881AD37AE1A7E8C74B90345C0D@IRV! E XCHCC... <1273441939. 4be72e937fdf5@webmail.fas.harvard.edu> <20100510232234.16632o6l2ecu3wyy@mail.skype.net>
In-Reply-To: <20100510232234.16632o6l2ecu3wyy@mail.skype.net>
Date: Tue, 11 May 2010 16:38:40 +0200
Message-ID: <006101caf117$aaf3b2c0$00db1840$@de>
MIME-Version: 1.0
Content-Type: multipart/related; boundary="----=_NextPart_000_0062_01CAF128.6E7C82C0"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acrw0m8GNXZpDck0Qjy3nWpGN9Rz1gAQeaxw
Content-Language: de
X-AntiVirus: NOT checked by Avira MailGate (version: 3.0.0-4; host: mx06)
Cc: codec@ietf.org
Subject: Re: [codec] #16: Multicast?
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 May 2010 14:39:51 -0000

Hello,

 

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:



Legend:

MOS-CQS are subjective conversational tests

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

MOS-LQO are result from listening-only tests.

 

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:

 



and



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...

 

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 

http://www.net.uni-tuebingen.de/

 

 

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

>From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Koen Vos

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

>To: bens@alum.mit.edu; Benjamin M. Schwartz

>Cc: codec@ietf.org

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

> 

>Quoting Benjamin M. Schwartz:

> 

>> Quoting Koen Vos <koen.vos@skype.net>:

>>> 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

>accident.

> 

>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.

> 

>koen.

> 

>_______________________________________________

>codec mailing list

>codec@ietf.org

>https://www.ietf.org/mailman/listinfo/codec