Re: [codec] Suggested summary...
Michael Knappe <mknappe@juniper.net> Fri, 02 July 2010 15:27 UTC
Return-Path: <mknappe@juniper.net>
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 96F553A68B2 for <codec@core3.amsl.com>; Fri, 2 Jul 2010 08:27:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 kuZyfmj0uA-a for <codec@core3.amsl.com>; Fri, 2 Jul 2010 08:27:51 -0700 (PDT)
Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by core3.amsl.com (Postfix) with ESMTP id 1E9603A67B7 for <codec@ietf.org>; Fri, 2 Jul 2010 08:27:51 -0700 (PDT)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKTC4FdggNLtwORFwovHqxuk9zOBpjIwgM@postini.com; Fri, 02 Jul 2010 08:28:03 PDT
Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Fri, 2 Jul 2010 08:22:19 -0700
From: Michael Knappe <mknappe@juniper.net>
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>
Date: Fri, 02 Jul 2010 08:22:18 -0700
Thread-Topic: [codec] Suggested summary...
Thread-Index: AcsZ169OESl0TknWTyqm+YdH4xfW5wAA8IhwAAKPU6YAAKBJEAAEinYG
Message-ID: <05542EC42316164383B5180707A489EE1D6689B2C3@EMBX02-HQ.jnpr.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "codec@ietf.org" <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 15:27:52 -0000
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 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 >
- Re: [codec] Suggested summary... Michael Knappe
- Re: [codec] Suggested summary... Herve Taddei
- Re: [codec] Suggested summary... Michael Knappe
- Re: [codec] Suggested summary... Herve Marcel Taddei 00900001
- Re: [codec] Suggested summary... Michael Knappe
- [codec] Don't use "lower complexity than that oth… Stephan Wenger