Re: [codec] #16: Multicast?

Gregory Maxwell <> Fri, 07 May 2010 18:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 261F43A67FA for <>; Fri, 7 May 2010 11:33:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.999
X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qN2AREpS5Ztw for <>; Fri, 7 May 2010 11:33:07 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3207C3A67EF for <>; Fri, 7 May 2010 11:33:07 -0700 (PDT)
Received: from source ([]) (using TLSv1) by ([]) with SMTP ID; Fri, 07 May 2010 11:32:55 PDT
Received: from ([fe80::c821:7c81:f21f:8bc7]) by ([fe80::a124:1ab1:8e0b:f671%11]) with mapi; Fri, 7 May 2010 11:31:19 -0700
From: Gregory Maxwell <>
To: Christian Hoene <>
Date: Fri, 07 May 2010 11:31:19 -0700
Thread-Topic: [codec] #16: Multicast?
Thread-Index: AcrimhyNUh3NLsf5RvSfcmuOhmvRfwBUwYUAAVLFoDAApwRsUACBX9BgAA3Nn9w=
Message-ID: <>
References: <> <> <> <> <> <000001cae173$dba012f0$92e038d0$@de> <> <001101cae177$e8aa6780$b9ff3680$@de> <> <002d01cae188$a330b2c0$e9921840$@de> <> <> <> <002c01cae939$5c01f400$1405dc00$@de> <>, <009901caede1$43f366d0$cbda3470$@de>
In-Reply-To: <009901caede1$43f366d0$cbda3470$@de>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [codec] #16: Multicast?
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Codec WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 07 May 2010 18:33:08 -0000

Christian Hoene [] wrote:
> And, are these requirements unique or are they covered by existing
> codecs like G.711 and G.729 already? Is it likely that gateways,
> which operate already on their limits, can support yet another codec?

I think this is an essential question.  

There are a number of excellent pre-existing codecs out there— during
the formation of this working group we concluded that there was a 
significant non-addressed application space which a new codec 
could satisfy,  but I've seen a number of  requirements raised here
which may be specific to applications for which existing codecs are
already well suited.  

In particular while computational burden is an essential concern, I don't
think it is reasonable to subject a full-band / super-band / wideband
codec to the same criteria which would be reasonable for a narrow band

If your gateway can't scale to acceptable size except with very
computationally cheap codecs, then you probably ought to be
using one of the already established narrow-band codecs.

I don't think it's a good idea to design for very high levels of complexity
but we ought to keep in mind that the working group is already targeted
at something high quality (and thus more complex) than narrow 
band.  Together with the normal "moore's law"  progress in  transistor
density, I think these factors may suggest a slight bias towards
additional computational complexity at least  where the increase in
complexity can be effectively used.