Re: [codec] Suggested summary...

Herve Marcel Taddei 00900001 <herve.taddei@huawei.com> Fri, 02 July 2010 17:13 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 449AA28C0EE for <codec@core3.amsl.com>; Fri, 2 Jul 2010 10:13:26 -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=[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 woDPGpwHsu96 for <codec@core3.amsl.com>; Fri, 2 Jul 2010 10:13:22 -0700 (PDT)
Received: from lhrga02-in.huawei.com (lhrga02-in.huawei.com [195.33.106.143]) by core3.amsl.com (Postfix) with ESMTP id 19FE928C112 for <codec@ietf.org>; Fri, 2 Jul 2010 10:13:22 -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 <0L4X008AVX6KU2@lhrga02-in.huawei.com> for codec@ietf.org; Fri, 02 Jul 2010 18:13:33 +0100 (BST)
Received: from huawei.com ([172.18.7.118]) by lhrga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L4X00FY7X6KSS@lhrga02-in.huawei.com> for codec@ietf.org; Fri, 02 Jul 2010 18:13:32 +0100 (BST)
Received: from [172.24.1.6] (Forwarded-For: [77.4.112.78]) by lhrms01-in.huawei.com (mshttpd); Fri, 02 Jul 2010 19:13:32 +0200
Date: Fri, 02 Jul 2010 19:13:32 +0200
From: Herve Marcel Taddei 00900001 <herve.taddei@huawei.com>
In-reply-to: <05542EC42316164383B5180707A489EE1D6689B2C4@EMBX02-HQ.jnpr.net>
To: Michael Knappe <mknappe@juniper.net>
Message-id: <f80cfd6e96ff.96fff80cfd6e@huawei.com>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006)
Content-type: text/plain; charset="iso-8859-1"
Content-language: en
Content-transfer-encoding: quoted-printable
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <05542EC42316164383B5180707A489EE1D6689B2C4@EMBX02-HQ.jnpr.net>
Cc: "codec@ietf.org" <codec@ietf.org>, "stephen.botzko@gmail.com" <stephen.botzko@gmail.com>
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 17:13:26 -0000

Actually on my side, I am commenting on the Low complexity mode as described by Christian.

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

What is less than 38 WMOPS, the LC mode or the codec by itself. Perhaps some re-wording is needed there if the 38 WMOPS are not for the LC mode. In that case it would be nice to write down the complexity of the LC mode.

BTW, if you plan to use some ITU-T tools for your activity, it is perhaps a good idea to inform them. They could tell you for example that there is a STL 2009 library. :-)

Hervé



******************************************************************************************
 This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it!
 *****************************************************************************************

----- Original Message -----
From: Michael Knappe <mknappe@juniper.net>
Date: Friday, July 2, 2010 6:08 pm
Subject: Re: [codec] Suggested summary...
To: "herve.taddei@huawei.com" <herve.taddei@huawei.com>, "stephen.botzko@gmail.com" <stephen.botzko@gmail.com>, "hoene@uni-tuebingen.de" <hoene@uni-tuebingen.de>
Cc: "codec@ietf.org" <codec@ietf.org>

> Herve,
> 
> I am not pointing to that codec (AMR-WB) as an example of a low 
> complexity codec. Was just commenting that popular codecs (of any 
> complexity) often get informally chosen as a comparative benchmark.
> 
> Mike
> 
> ----- Original Message -----
> From: Herve Taddei <herve.taddei@huawei.com>
> To: Michael Knappe; stephen.botzko@gmail.com 
> <stephen.botzko@gmail.com>; hoene@uni-tuebingen.de <hoene@uni-
> tuebingen.de>Cc: codec@ietf.org <codec@ietf.org>
> Sent: Fri Jul 02 11:52:54 2010
> Subject: RE: [codec] Suggested summary...
> 
> Codecs as G.722 (10 MIPS), G.722.1 (about 5 WMOPS), G.722.1C 
> (about 11
> WMOPS) and G.719 (about 21 WMOPS) are usually considered as low 
> complexitycodecs for WB, SWB and FB bandwidths. 
> 
> Other codecs as G.711 and its newly extensions have also very low 
> complexityversions with G.711.0 (less than 2 WMOPS), G.711.1 
> (about 9 WMOPS) and very
> soon G.722/G.711.1 SWB.
> 
> So 38 WMOPS is not really in the range of low complexity.
> 
> Herve Taddei
> 
> 
> > -----Original Message-----
> > From: Michael Knappe [mailto:mknappe@juniper.net]
> > Sent: Friday, July 02, 2010 5:22 PM
> > To: herve.taddei@huawei.com; stephen.botzko@gmail.com; hoene@uni-
> > tuebingen.de
> > Cc: codec@ietf.org
> > Subject: Re: [codec] Suggested summary...
> > 
> > Herve,
> > 
> > I wasn't specifically suggesting AMR-WB (that came from Christian's
> email). I was
> > simply saying that popular named codecs are often used as informal
> benchmarks
> > by the industry at large.
> > 
> > Mike
> > 
> > ----- Original Message -----
> > From: Herve Taddei <herve.taddei@huawei.com>
> > To: Michael Knappe; 'stephen botzko' <stephen.botzko@gmail.com>;
> 'Christian
> > Hoene' <hoene@uni-tuebingen.de>
> > Cc: codec@ietf.org <codec@ietf.org>
> > Sent: Fri Jul 02 09:16:47 2010
> > Subject: RE: [codec] Suggested summary...
> > 
> > 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 
> exampleof
> > 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.729Acomes
> > to
> > > mind for narrowband codec comparisons), but some form of 
> generalizedfixed
> > 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 
> algorithmicdelay
> > 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 
> muchfaster
> > 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
> > >
> > 
> > 
> 
> 
> 
>