Re: [codec] #16: Multicast?

"Raymond (Juin-Hwey) Chen" <rchen@broadcom.com> Fri, 07 May 2010 21:29 UTC

Return-Path: <rchen@broadcom.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 91CBA3A67EA for <codec@core3.amsl.com>; Fri, 7 May 2010 14:29:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[AWL=-0.316, BAYES_50=0.001, SARE_MILLIONSOF=0.315]
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 ySXWPsliehju for <codec@core3.amsl.com>; Fri, 7 May 2010 14:29:17 -0700 (PDT)
Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by core3.amsl.com (Postfix) with ESMTP id 44F323A6980 for <codec@ietf.org>; Fri, 7 May 2010 14:29:16 -0700 (PDT)
Received: from [10.9.200.131] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Fri, 07 May 2010 14:28:48 -0700
X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A
Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.31]) by IRVEXCHHUB01.corp.ad.broadcom.com ([10.9.200.131]) with mapi; Fri, 7 May 2010 14:28:49 -0700
From: "Raymond (Juin-Hwey) Chen" <rchen@broadcom.com>
To: Gregory Maxwell <gmaxwell@juniper.net>, Christian Hoene <hoene@uni-tuebingen.de>
Date: Fri, 07 May 2010 14:28:47 -0700
Thread-Topic: [codec] #16: Multicast?
Thread-Index: AcrimhyNUh3NLsf5RvSfcmuOhmvRfwBUwYUAAVLFoDAApwRsUACBX9BgAA3Nn9wABCPpQA==
Message-ID: <CB68DF4CFBEF4942881AD37AE1A7E8C74B90345C0D@IRVEXCHCCR01.corp.ad.broadcom.com>
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> <CB68DF4CFBEF4942881AD37AE1A7E8C74AB3F4A287@IRVEXCHCCR01.corp.ad.broadcom.com> <002c01cae939$5c01f400$1405dc00$@de> <CB68DF4CFBEF4942881AD37AE1A7E8C74B903454B3@IRVEXCHCCR01.corp.ad.broadcom.com>, <009901caede1$43f366d0$cbda3470$@de> <BCB3F026FAC4C145A4A3330806FEFDA93AB072BCC6@EMBX01-HQ.jnpr.net>
In-Reply-To: <BCB3F026FAC4C145A4A3330806FEFDA93AB072BCC6@EMBX01-HQ.jnpr.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
MIME-Version: 1.0
X-WSS-ID: 67FA599A20S117777147-01-01
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Cc: "codec@ietf.org" <codec@ietf.org>
Subject: Re: [codec] #16: Multicast?
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, 07 May 2010 21:29:18 -0000

Hi Gregory,

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

[Raymond]: I am not sure which codecs satisfy the three conditions 
listed in the codec WG charter. Would you please share which 
codecs you have in mind?  Thanks.

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

[Raymond]: Agreed. I never propose that we should subject full-
/super-/wide-band codecs to the same complexity constraints as for 
narrowband codecs.  What I am proposing, though, is that for a 
particular sampling-rate, be it 16, 32, 44.1, or 48 kHz, when we 
consider different codec options, we should not ignore the codec 
complexity, because high codec complexity have negative consequences 
in low-end devices and gateways. 

My other point is that although the WG does want a wideband/super-
wideband/full-band audio codec, we shouldn't completely ignore 
narrowband, because that's still how most of the point-to-point 
voice calls and multi-party voice conferencing (the first two of the 
six applications listed in the charter) are conducted today and in 
the foreseeable future.  Just North American cable operators alone 
have tens of millions of VoIP telephony subscribers. If you add 
other countries, telcos, independent VoIP operators like Vonage, and 
enterprise IP phone users, although I don't have the stats, I 
wouldn't be surprised if the total VoIP users worldwide exceed 100M, 
probably significantly.  Most of these are still narrowband.  
Therefore, it makes the most sense for the IETF codec to be able to 
also address narrowband speech coding so it has a chance to be used 
by these VoIP users.  If a call goes through the IETF codec and 
reaches out to a conventional phone through a VoIP gateway, then it 
is better if the call doesn't have to be transcoded to another 
medium- or low-bit-rate codec so the additional codec distortion and 
coding delay can be avoided.  This is where the recent discussion of 
VoIP gateways come in.

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

[Raymond]: I completely agree with you that we should allow 
additional complexity (compared with narrowband) to enable higher-
bandwidth, higher-quality audio. On the other hand, if we are 
evaluating, say, two wideband (16 kHz) codecs, where one requires 50 
MHz on a DSP while the other requires 20 MHz, then such a 
substantial difference in computational complexity should be taken 
into account when considering all other aspects of the codecs.

_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.org/mailman/listinfo/codec