Re: [codec] Suggested summary...

Herve Taddei <> Fri, 02 July 2010 12:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DE2843A67E2 for <>; Fri, 2 Jul 2010 05:18:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id P5DsFyZbxOIc for <>; Fri, 2 Jul 2010 05:18:03 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D9B843A635F for <>; Fri, 2 Jul 2010 05:18:02 -0700 (PDT)
Received: from (lhrga02-in []) by (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <> for; Fri, 02 Jul 2010 13:18:13 +0100 (BST)
Received: from h00900001 ([]) by (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <> for; Fri, 02 Jul 2010 13:18:12 +0100 (BST)
Date: Fri, 02 Jul 2010 14:18:08 +0200
From: Herve Taddei <>
In-reply-to: <>
To: 'stephen botzko' <>, 'Christian Hoene' <>
Message-id: <>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
X-Mailer: Microsoft Office Outlook 11
Content-type: multipart/alternative; boundary="Boundary_(ID_0n5gkk6h1jYmSa5pmqNrug)"
Thread-index: AcsZ169OESl0TknWTyqm+YdH4xfW5wAA8Ihw
iPlanet-SMTP-Warning: Lines longer than SMTP allows found and truncated.
References: <> <> <> <> <> <000001cae173$dba012f0$92e038d0$@de> <> <001101cae177$e8aa6780$b9ff3680$@de> <> <002d01cae188$a330b2c0$e9921840$@de> <> <> <> <> <> <> <> <"909E12B9-984F-405 FE0A40E"> <> <> <> <> <002901cafd89$acf402e0$06dc08a0$@de> <> <000601cafd9b$148fd850$3daf88f0$@de> <> <002501cafdb4$09394810$1babd830$@de> <> <001901cb19ce$a074d600$e15e8200$@de> <>
Subject: Re: [codec] Suggested summary...
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: Fri, 02 Jul 2010 12:18:05 -0000

I think I have the same opinion as Stephen, this does not really represent a
consensus as it never came on the table. This is exactly what I was asking
in my email by end of May when you wrote there was consensus, what is the


The 5 1/3 ms is quite precise, why this value? The AMR-WB codec complexity
as reference, for which reason? 


Kind regards


Herve Taddei



From: [] On Behalf Of
stephen botzko
Sent: Friday, July 02, 2010 1:14 PM
To: Christian Hoene
Subject: Re: [codec] Suggested summary...


Maybe I somehow missed it, but i do not see any discussions on the list that
support your consensus claim.  While perhaps they are reasonable suggestions
that we can discuss further, for me consensus means that the specifics were
expressly discussed and generally agreed.  

There seem to be details here that I do not find on the list.  For instance,
a general support for a complexity ceiling of AMR-WB, and a 5 1/3 ceiling on
low-delay frame size.

Stephen Botzko

2010/7/2 Christian Hoene <>


taking Cullen advise, I would like to suggest the following summary.

> 1) low delay mode

The codec shall be able to operated at a mode having an algorithmic delay of
8ms or less while having a frame duration of 5 1/3 ms or less. This is
require to support ensemble performances over the Internet and other highly
interactive conversational tasks.

> 2) low complexity mode (whatever this means)

The codec shall be able to operate at a low complexity mode while requiring
less computational resources than a AMR-WB codec
(< 38 WMOPS if measured with ITU-T STL2005 BaseOP (ITU-T G.192)).

> 3) technical understanding on how latency sums up on different platforms

Standard ITU-T G.114 (05/00 and 05/03) describes how different system
components contribute to the one-way transmission delay. It states that the
processing time of the codec contributes with an additional delay as large
as the frame duration.

However, it is common consensus that plenty computational resources will be
available most of the time. Then, the codec processing will be much faster
than one frame duration. Typical values are range from a factor faster of
100 (smart phones) to 1000 (PCs). A device working at full load is a rare

Any suggestion to improve it?

With best regards,


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: Cullen Jennings []
Sent: Monday, June 21, 2010 7:21 PM
To: Christian Hoene
Subject: Re: [codec] #16: Multicast?

On May 27, 2010, at 9:48 AM, Christian Hoene wrote:

> So, we have consensus on
> 1) low delay mode
> 2) low complexity mode (whatever this means)
> 3) technical understanding on how latency sums up on different platforms

>From a Chair point of view, I don't think the Chairs could summarize or call
consensus on these three - however, I'm not sure that matters. If you think
a key piece of consensus has come out of this conversation and that it needs
to captured in the archive, can you summarize what you think it is folks
agree with and then the chairs can make some sort of consensus call.

Thanks, Cullen <with my chair hat on>

codec mailing list