Re: [codec] Suggested summary...

Herve Taddei <herve.taddei@huawei.com> Fri, 02 July 2010 13:16 UTC

Return-Path: <herve.taddei@huawei.com>
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 C39573A6820 for <codec@core3.amsl.com>; Fri, 2 Jul 2010 06:16:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599]
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 ItmcvwFnqfWC for <codec@core3.amsl.com>; Fri, 2 Jul 2010 06:16:44 -0700 (PDT)
Received: from lhrga02-in.huawei.com (lhrga02-in.huawei.com [195.33.106.143]) by core3.amsl.com (Postfix) with ESMTP id F22FA3A6818 for <codec@ietf.org>; Fri, 2 Jul 2010 06:16:43 -0700 (PDT)
Received: from huawei.com (lhrga02-in [172.18.7.45]) by lhrga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L4X0085PM84U2@lhrga02-in.huawei.com> for codec@ietf.org; Fri, 02 Jul 2010 14:16:52 +0100 (BST)
Received: from h00900001 ([10.200.70.162]) by lhrga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L4X00J90M80OJ@lhrga02-in.huawei.com> for codec@ietf.org; Fri, 02 Jul 2010 14:16:51 +0100 (BST)
Date: Fri, 02 Jul 2010 15:16:47 +0200
From: Herve Taddei <herve.taddei@huawei.com>
In-reply-to: <C8532F8A.19060%mknappe@juniper.net>
To: 'Michael Knappe' <mknappe@juniper.net>, 'stephen botzko' <stephen.botzko@gmail.com>, 'Christian Hoene' <hoene@uni-tuebingen.de>
Message-id: <33D8F96E0D56484C8E41BE982E4D1990@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset="ISO-8859-2"
Content-transfer-encoding: quoted-printable
Thread-index: AcsZ169OESl0TknWTyqm+YdH4xfW5wAA8IhwAAKPU6YAAKBJEA==
References: <6A21D03881734E0AB69220FD6B6CCDCB@china.huawei.com> <C8532F8A.19060%mknappe@juniper.net>
Cc: codec@ietf.org
Subject: Re: [codec] Suggested summary...
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: Fri, 02 Jul 2010 13:16:45 -0000

Hi Mike,

Actually if you ask me to name a low complexity codec (by the way at which
bandwidth?) I don't think I would name AMR-WB. G.722.1 is a good example of
a low complexity codec for WB services. 

Best regards

Herve 


> -----Original Message-----
> From: Michael Knappe [mailto:mknappe@juniper.net]
> Sent: Friday, July 02, 2010 2:54 PM
> To: Herve Taddei; 'stephen botzko'; 'Christian Hoene'
> Cc: codec@ietf.org
> Subject: Re: [codec] Suggested summary...
> 
> On codec complexity benchmarking, there is certainly industry precedence
for
> using an existing codec as a rough relative complexity guide (G.729A comes
to
> mind for narrowband codec comparisons), but some form of generalized fixed
point
> / floating point instruction count rating would hopefully be less
algorithm specific.
> Herve, Stephen, any suggestion(s) for codec complexity ratings?
> 
> Mike
> 
> 
> On 7/2/10 5:18 AM, "Herve Taddei" <herve.taddei@huawei.com> wrote:
> 
> 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
consensus?
> 
> 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: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of
> stephen botzko
> Sent: Friday, July 02, 2010 1:14 PM
> To: Christian Hoene
> Cc: codec@ietf.org
> 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.
> 
> Regards
> Stephen Botzko
> 
> 
> 2010/7/2 Christian Hoene <hoene@uni-tuebingen.de>
> Hello,
> 
> 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 case.
> 
> Any suggestion to improve it?
> 
> With best regards,
> 
>  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/
> 
> 
> -----Original Message-----
> From: Cullen Jennings [mailto:fluffy@cisco.com]
> Sent: Monday, June 21, 2010 7:21 PM
> To: Christian Hoene
> Cc: codec@ietf.org
> 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
> codec@ietf.org
> https://www.ietf.org/mailman/listinfo/codec
>