Re: [codec] Suggested summary...
Herve Taddei <herve.taddei@huawei.com> Mon, 05 July 2010 15:45 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 63E543A6995 for <codec@core3.amsl.com>; Mon, 5 Jul 2010 08:45:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.74
X-Spam-Level:
X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74]
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 SJMKRXChEZoK for <codec@core3.amsl.com>; Mon, 5 Jul 2010 08:45:23 -0700 (PDT)
Received: from lhrga04-in.huawei.com (lhrga04-in.huawei.com [195.33.106.149]) by core3.amsl.com (Postfix) with ESMTP id A257E3A693D for <codec@ietf.org>; Mon, 5 Jul 2010 08:45:22 -0700 (PDT)
Received: from huawei.com (localhost [127.0.0.1]) by lhrga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L5300DWBD3KVP@lhrga04-in.huawei.com> for codec@ietf.org; Mon, 05 Jul 2010 16:45:20 +0100 (BST)
Received: from h00900001 ([10.200.70.162]) by lhrga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L5300H1KD3GTG@lhrga04-in.huawei.com> for codec@ietf.org; Mon, 05 Jul 2010 16:45:19 +0100 (BST)
Date: Mon, 05 Jul 2010 17:45:15 +0200
From: Herve Taddei <herve.taddei@huawei.com>
In-reply-to: <000301cb19ff$c9c11420$5d433c60$@de>
To: 'Christian Hoene' <hoene@uni-tuebingen.de>, 'Michael Knappe' <mknappe@juniper.net>, 'stephen botzko' <stephen.botzko@gmail.com>
Message-id: <B91B4EED5FAF448B8DBCB82C3A01996A@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+YdH4xfW5wAA8IhwAAKPU6YAAKBJEAAFhyPwAJLn5oA=
References: <6A21D03881734E0AB69220FD6B6CCDCB@china.huawei.com> <C8532F8A.19060%mknappe@juniper.net> <33D8F96E0D56484C8E41BE982E4D1990@china.huawei.com> <000301cb19ff$c9c11420$5d433c60$@de>
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: Mon, 05 Jul 2010 15:45:24 -0000
Hi Christian, The wording is fine if everybody agrees that AMR-WB should be the reference complexity for an internet codec. Why is AMR-WB the anchor? What is then the complexity of the so called low computational mode? Is it half, one third, 10% of it? I don't see the wording low complexity anymore. This complexity would be the one of the full codec at all bitrates/bandwidth, correct? I am also fine with adding lower complexity values for lower sampling frequency (e.g. 8-16 kHz) as proposed by Raymond as well as taking care of the memory footprint. In some sense, the way proposed by Stephen is fine, "work forward from use cases and problem statements" to figure out the requirements. In that case, it would be needed to define where and how this codec is going to be used. Shouldn't it be in the draft documents you were working on? Best regards Herve > -----Original Message----- > From: Christian Hoene [mailto:hoene@uni-tuebingen.de] > Sent: Friday, July 02, 2010 6:01 PM > To: 'Herve Taddei'; 'Michael Knappe'; 'stephen botzko' > Cc: codec@ietf.org > Subject: RE: [codec] Suggested summary... > > Hello Herve, > > If I understand you correctly, you are not suggesting G.722.1 as reference. You just > say that AMR-WB is not known as low-complexity. > > So, a better wording would say > > "The IWAC codec MUST be able to operate at a mode that requires less > computational resources than the AMR-WB codec at 12.65 kbit/s. > Thus, the complexity of the IWAC codec MUST be less than 38 WMOPS if > measured with the ITU-T STL2005 BaseOP library." > > Fine? > > Christian > > > > > > -----Original Message----- > From: Herve Taddei [mailto:herve.taddei@huawei.com] > Sent: Friday, July 02, 2010 3:17 PM > To: 'Michael Knappe'; 'stephen botzko'; 'Christian Hoene' > Cc: codec@ietf.org > 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 > > > >
- [codec] #16: Multicast? codec issue tracker
- Re: [codec] #16: Multicast? Colin Perkins
- Re: [codec] #16: Multicast? Christian Hoene
- Re: [codec] #16: Multicast? Marshall Eubanks
- Re: [codec] #16: Multicast? stephen botzko
- Re: [codec] #16: Multicast? Colin Perkins
- Re: [codec] #16: Multicast? Colin Perkins
- Re: [codec] #16: Multicast? stephen botzko
- Re: [codec] #16: Multicast? Christian Hoene
- Re: [codec] #16: Multicast? stephen botzko
- Re: [codec] #16: Multicast? Marshall Eubanks
- Re: [codec] #16: Multicast? Christian Hoene
- Re: [codec] #16: Multicast? stephen botzko
- Re: [codec] #16: Multicast? Christian Hoene
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Jean-Marc Valin
- Re: [codec] #16: Multicast? Koen Vos
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Mikael Abrahamsson
- Re: [codec] #16: Multicast? Jean-Marc Valin
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Koen Vos
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? stephen botzko
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Koen Vos
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Mikael Abrahamsson
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Mikael Abrahamsson
- Re: [codec] #16: Multicast? (Bluetooth) Koen Vos
- Re: [codec] #16: Multicast? Koen Vos
- Re: [codec] #16: Multicast? stephen botzko
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Koen Vos
- Re: [codec] #16: Multicast? (Bluetooth) Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? (Bluetooth) stephen botzko
- Re: [codec] #16: Multicast? Christian Hoene
- Re: [codec] #16: Multicast? Christian Hoene
- Re: [codec] #16: Multicast? Christian Hoene
- Re: [codec] #16: Multicast? (USB) Roni Even
- Re: [codec] #16: Multicast? codec issue tracker
- Re: [codec] #16: Multicast? stephen botzko
- Re: [codec] #16: Multicast? Cullen Jennings
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Mikael Abrahamsson
- Re: [codec] #16: Multicast? Koen Vos
- Re: [codec] #16: Multicast? (Bluetooth) Koen Vos
- Re: [codec] #16: Multicast? stephen botzko
- Re: [codec] #16: Multicast? Christian Hoene
- Re: [codec] #19: How large is the frame size depe… Christian Hoene
- Re: [codec] #19: How large is the frame size depe… stephen botzko
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #19: How large is the frame size depe… Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? (Bluetooth) Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? stephen botzko
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? stephen botzko
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Koen Vos
- Re: [codec] #16: Multicast? Christian Hoene
- Re: [codec] #16: Multicast? Gregory Maxwell
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Koen Vos
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Koen Vos
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Koen Vos
- Re: [codec] #16: Multicast? Koen Vos
- Re: [codec] #16: Multicast? Benjamin M. Schwartz
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Kevin P. Fleming
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Jean-Marc Valin
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Jean-Marc Valin
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Christian Hoene
- Re: [codec] #16: Multicast? Koen Vos
- Re: [codec] #16: Multicast? Christian Hoene
- Re: [codec] #16: Multicast? Ben Schwartz
- Re: [codec] #16: Multicast? Marshall Eubanks
- Re: [codec] #16: Multicast? Brian Rosen
- Re: [codec] #16: Multicast? Christian Hoene
- Re: [codec] #16: Multicast? Jean-Marc Valin
- Re: [codec] Thresholds and delay. Ben Schwartz
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] Thresholds and delay. stephen botzko
- Re: [codec] #16: Multicast? Christian Hoene
- Re: [codec] Thresholds and delay. Ben Schwartz
- Re: [codec] #20: Computational complexity? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] Thresholds and delay. jari.hagqvist
- Re: [codec] Thresholds and delay. stephen botzko
- Re: [codec] Thresholds and delay. Ben Schwartz
- Re: [codec] Thresholds and delay. Marshall Eubanks
- Re: [codec] Thresholds and delay. stephen botzko
- Re: [codec] #16: Multicast? Cullen Jennings
- Re: [codec] Thresholds and delay. Michael Knappe
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Koen Vos
- Re: [codec] #16: Delay factor: algorithmic delay … Christian Hoene
- Re: [codec] #16: Delay factor: algorithmic delay … Mikael Abrahamsson
- Re: [codec] #16: Delay factor: algorithmic delay … Roman Shpount
- Re: [codec] #16: Delay factor: algorithmic delay … stephen botzko
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Cullen Jennings
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Koen Vos
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Koen Vos
- Re: [codec] #16: Multicast? Christian Hoene
- Re: [codec] #16: Multicast? Jean-Marc Valin
- Re: [codec] #16: Multicast? Herve Taddei
- Re: [codec] #16: Multicast? Christian Hoene
- Re: [codec] #16: Multicast? Jean-Marc Valin
- Re: [codec] #16: Multicast? Sandy (Alexander) MacInnis
- Re: [codec] #16: Multicast? Christian Hoene
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Roman Shpount
- Re: [codec] #16: Multicast? Herve Taddei
- Re: [codec] #16: Multicast? Cullen Jennings
- [codec] Suggested summary... Christian Hoene
- Re: [codec] Suggested summary... stephen botzko
- Re: [codec] Suggested summary... Herve Taddei
- Re: [codec] Suggested summary... Christian Hoene
- Re: [codec] Suggested summary... Michael Knappe
- Re: [codec] Suggested summary... Herve Taddei
- Re: [codec] Suggested summary... stephen botzko
- Re: [codec] Suggested summary... Christian Hoene
- Re: [codec] Suggested summary... Christian Hoene
- Re: [codec] Suggested summary... stephen botzko
- Re: [codec] Suggested summary... Raymond (Juin-Hwey) Chen
- Re: [codec] Suggested summary... Christian Hoene
- Re: [codec] Suggested summary... Herve Taddei
- Re: [codec] Suggested summary... Raymond (Juin-Hwey) Chen