Re: [codec] Suggested summary...

stephen botzko <stephen.botzko@gmail.com> Fri, 02 July 2010 11:13 UTC

Return-Path: <stephen.botzko@gmail.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 D78593A688A for <codec@core3.amsl.com>; Fri, 2 Jul 2010 04:13:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 QlEAlJW1sOWU for <codec@core3.amsl.com>; Fri, 2 Jul 2010 04:13:29 -0700 (PDT)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id DFC583A6858 for <codec@ietf.org>; Fri, 2 Jul 2010 04:13:28 -0700 (PDT)
Received: by gxk28 with SMTP id 28so463543gxk.31 for <codec@ietf.org>; Fri, 02 Jul 2010 04:13:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=GJGuBtwxs/y7xUGcC5F/FNoZWJTJg/i3ZdYwSwd4IjE=; b=U8X2Fxvqi+y9QfC7k2it7GKxd6GUa6aSw+4mTOUyh65LBA8O3H4ZLAaQsMUlCGL9Yz n5rh8b5zxlgQAcPdsAJrKhcZj/dGZ8zMJ6rPSjII/+bCA4aYqxn/t8ntfNy2IX7Tnydy P4N0P7bdtKwXLLS4HvAP6ExMGK5EUuEJoO/h0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=vriZgDzL7yTCdOTMiYk/dbTnM/y7kPGY0bTJRHO2FkmiiqLuYLKE0Xg9VohZ/GBgG8 WvUXDK+oFUIN55nLjDZkxTXkW7J7ZaliXI4YXrv4AvdNYK/GBa0c0uu3p1F9UFJAZjT7 DvASjjSmYCZX3Al8AGulqPjIa7uoYBrJOUdHo=
MIME-Version: 1.0
Received: by 10.90.80.5 with SMTP id d5mr1115435agb.17.1278069217767; Fri, 02 Jul 2010 04:13:37 -0700 (PDT)
Received: by 10.90.82.7 with HTTP; Fri, 2 Jul 2010 04:13:37 -0700 (PDT)
In-Reply-To: <001901cb19ce$a074d600$e15e8200$@de>
References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <D6C2F445-BE4A-4571-A56D-8712C16887F1@americafree.tv> <C0347188-A2A1-4681-9F1E-0D2ECC4BDB3B@csperkins.org> <u2x6e9223711004210733g823b4777y404b02330c49dec1@mail.gmail.com> <000001cae173$dba012f0$92e038d0$@de> <r2q6e9223711004211010gfdee1a70q972e8239fef10435@mail.gmail.com> <001101cae177$e8aa6780$b9ff3680$@de> <t2t6e9223711004211119i6b107798pa01fc4b1d33debf1@mail.gmail.com> <002d01cae188$a330b2c0$e9921840$@de> <CB68DF4CFBEF4942881AD37AE1A7E8C74AB3F4A017@IRVEXCHCCR01.corp.ad.broadcom.com> <4BD11C50.2020206@usherbrooke.ca> <CB68DF4CFBEF4942881AD37AE1A7E8C74AB3F4A270@IRVEXCHCCR01.corp.ad.broadcom.com> <12151537-165D-426A-B71F-8B3D76BE4854@cisco.com> <CB68DF4CFBEF4942881AD37AE1A7E8C74B901372FE@IRVEXCHCCR01.corp.ad.broadcom.com> <20100430230756.13687lc1s5o89gsc@mail.skype.net> <CB68DF4CFBEF4942881AD37AE1A7E8C74B90345522@IRVEXCHCCR01.corp.ad.broadcom.com> <909E12B9-984F-4051-A93E-2291EFE0A40E@cisco.com> <CB68DF4CFBEF4942881AD37AE1A7E8C74B9BE9EDB7@IRVEXCHCCR01.corp.ad.broadcom.com> <20100526151326.2882694zuaeslk3q@mail.skype.net> <CB68DF4CFBEF4942881AD37AE1A7E8C74B9BE9F2E7@IRVEXCHCCR01.corp.ad.broadcom.com> <20100526214255.206532jzf8wjld1r@mail.skype.net> <002901cafd89$acf402e0$06dc08a0$@de> <19367DD02EBD40829869907AEA0CE128@china.huawei.com> <000601cafd9b$148fd850$3daf88f0$@de> <568A92CB079CCF43BA5C8D7B08BCB4AE817DCBA900@SJEXCHCCR02.corp.ad.broadcom.com> <002501cafdb4$09394810$1babd830$@de> <56E363F9-AB88-43A3-8ECC-99A7E9796330@cisco.com> <001901cb19ce$a074d600$e15e8200$@de>
Date: Fri, 02 Jul 2010 07:13:37 -0400
Message-ID: <AANLkTik-bei7mg9l28yssj8l49tqGX1gbTB1JJ59eyn-@mail.gmail.com>
From: stephen botzko <stephen.botzko@gmail.com>
To: Christian Hoene <hoene@uni-tuebingen.de>
Content-Type: multipart/alternative; boundary="0016361e8782b93146048a65ad6d"
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 11:13:30 -0000

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
>