IETF Logo Mail Archive

Re: [codec] #16: Multicast?

"Raymond (Juin-Hwey) Chen" <rchen@broadcom.com> Mon, 10 May 2010 19:08 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 153DA28C311 for <codec@core3.amsl.com>; Mon, 10 May 2010 12:08:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.172
X-Spam-Level:
X-Spam-Status: No, score=0.172 tagged_above=-999 required=5 tests=[AWL=-0.429, BAYES_50=0.001, J_CHICKENPOX_66=0.6]
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 jvCcekaLkWEb for <codec@core3.amsl.com>; Mon, 10 May 2010 12:08:00 -0700 (PDT)
Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by core3.amsl.com (Postfix) with ESMTP id DCB4128C355 for <codec@ietf.org>; Mon, 10 May 2010 12:00:19 -0700 (PDT)
Received: from [10.9.200.131] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Mon, 10 May 2010 11:59:55 -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; Mon, 10 May 2010 11:59:55 -0700
From: "Raymond (Juin-Hwey) Chen" <rchen@broadcom.com>
To: "bens@alum.mit.edu" <bens@alum.mit.edu>, Koen Vos <koen.vos@skype.net>
Date: Mon, 10 May 2010 11:59:54 -0700
Thread-Topic: [codec] #16: Multicast?
Thread-Index: Acrvweu7X98uXAVhT2uRwBDUSypKvwAsEEFA
Message-ID: <CB68DF4CFBEF4942881AD37AE1A7E8C74B90345E2F@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> <CB68DF4CFBEF4942881AD37AE1A7E8C74B90345C0D@IRVE XCHCC... <1273441939.4be72e937fdf5@webmail.fas.harvard.edu>
In-Reply-To: <1273441939.4be72e937fdf5@webmail.fas.harvard.edu>
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: 67F6882120S120580362-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: Mon, 10 May 2010 19:08:01 -0000

Hi Ben,

> I think this is a typo, and you mean "lessened the pressure to reduce bitrates
> and complexity, and has shifted the focus to fidelity and delay instead".

[Raymond]: I agree with you here.

>> All in all I'm happy with the current requirements document, and it's
>> unclear what specific changes (besides a Bluetooth mode) you have in
>> mind...?

> Me too; I'd also like some clarification as to whether we're talking about (a) > existing Bluetooth headsets or (b) future hardware designed to support the
> IWAC.  If (b), then this is just a matter of negotiating the acceptable
> encode+decode complexity, for eventual implementation by DSP or ASIC.  If (a)
> ... I'm surprised that such a retrofit is even conceivable.  If it is in fact
> possible, I would very much appreciate instructions on how to experiment with
> new codecs on existing headsets.  Once we know how to build test rigs, we can
> see what the complexity requirement there is.  If we can't test it, I don't
> think we can target it.

[Raymond]: I was definitely talking about (b), not (a).

v2.23.0 | Report a Bug | By Email