Re: [dispatch] [AVT] Proposal to form Internet Wideband Audio Codec WG

Henning Schulzrinne <hgs@cs.columbia.edu> Tue, 02 June 2009 16:16 UTC

Return-Path: <hgs@cs.columbia.edu>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A5903A6F2D; Tue, 2 Jun 2009 09:16:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.844
X-Spam-Level:
X-Spam-Status: No, score=-1.844 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_ADOBE2=2.455, MANGLED_INXPNS=2.3, RCVD_IN_DNSWL_MED=-4]
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 RtHrmCP8GIPz; Tue, 2 Jun 2009 09:16:30 -0700 (PDT)
Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id D1F103A6BDE; Tue, 2 Jun 2009 09:16:29 -0700 (PDT)
Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id n52GFqU0013510 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 2 Jun 2009 12:15:52 -0400 (EDT)
Message-Id: <D1611ACB-4739-4A65-94F0-403FC24CDC43@cs.columbia.edu>
From: Henning Schulzrinne <hgs@cs.columbia.edu>
To: Roni Even <Even.roni@huawei.com>
In-Reply-To: <00d501c9e39a$dcbbbe50$96333af0$%roni@huawei.com>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Date: Tue, 02 Jun 2009 12:15:51 -0400
References: <AA5A65FC22B6F145830AC0EAC7586A6C04BF8E77@mail-srv.spiritcorp.com> <00a401c9e388$b25c2350$171469f0$%roni@huawei.com> <4A2541B9.2000805@octasic.com> <00d501c9e39a$dcbbbe50$96333af0$%roni@huawei.com>
X-Mailer: Apple Mail (2.935.3)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.65 on 128.59.29.8
Cc: dispatch@ietf.org, 'Jean-Marc Valin' <jean-marc.valin@octasic.com>, avt@ietf.org, hsinnrei@adobe.com, 'Slava Borilin' <Borilin@spiritdsp.com>
Subject: Re: [dispatch] [AVT] Proposal to form Internet Wideband Audio Codec WG
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Jun 2009 16:16:31 -0000

I view this as a trade-off. If we pursue this, there are risks:

- nothing may come of it since there are no experts willing to help
- somebody will claim IPR on the resulting work
- the quality of the codec may not be competitive

However, if we don't do this, we are stuck with the status quo, which  
is not all that satisfactory. Thus, unless there are significant costs  
for "innocent bystanders", I see this as a risk worth taking. In the  
worst case, we are no worse off than we are today. In all other cases,  
we'll have an additional choice for a wideband codec, even if it's not  
"the best", just "good enough". After all, most people use G.711  
today, which has a really hard time making that claim.

Most real work in the IETF is done by very small teams, typically less  
than 10, so as long as we have a handful of people that are willing to  
contribute, this can work. It might even work better, since you may  
get fewer people who have half-baked opinions - we may skip the binary  
vs. XML debates...

We can set some ground rules ("must be tested with packet loss of 5%")  
and then see what happens. Compared to most network protocols, the  
likely negative impacts (such as security or congestion control  
issues) of even a badly-designed codec are pretty limited.

Henning

On Jun 2, 2009, at 11:57 AM, Roni Even wrote:

> Hi,
> I do not want to sound like someone who is for IPR (I am not), but  
> why stop
> at codec, let's require it for all IETF work. There are IPR on IETF  
> work
> which is must simpler, in my view, than wide band audio codecs.
>
> I think that we can start with "royalty free" even though I am not  
> sure that
> it will accepted as part of the charter of any other work group so  
> why pick
> on codecs which require more work.
>
> This leaves the other reasons I heard for doing it at the IETF which  
> is the
> price of participating (cheaper than being an ITU-T member) and  
> maybe design
> less expensive characterization tests.
>
> Roni
>
>
> -----Original Message-----
> From: Jean-Marc Valin [mailto:jean-marc.valin@octasic.com]
> Sent: Tuesday, June 02, 2009 6:14 PM
> To: Roni Even
> Cc: 'Slava Borilin'; avt@ietf.org; 'Jason Fischl'; dispatch@ietf.org;
> hsinnrei@adobe.com
> Subject: Re: [AVT] [dispatch] Proposal to form Internet Wideband  
> Audio Codec
> WG
>
> Hi,
>
> Roni Even wrote:
>>
>> I am not sure what prevented you from doing it today at the ITU or
>> MPEG, why do you see the IETF handling it differently.
>>
>> I would also like to remind you and Jean-Marc that once you are
>> bringing work to a standard body it may require collaboration with
>> other people who will have other proposals that will also address the
>> same requirements and you may need to invest money in comparative
>> testing by independent listening labs.
>>
>> I also think that you will need to supply the codec in source code  
>> and
>> provide copy right to the IETF.
>>
>
> I am well aware that bringing work to the IETF would require
> collaboration with others. I am not seeking control over the work I am
> currently doing and would really welcome such collaboration. The  
> idea is
> only to have the best wideband codec possible without IPR issues.  
> Given
> the ITU and MPEG track record, I think it would be very unlikely for  
> any
> of those organisations to work on an IPR-free codec.
>
> I also agree with Henry that "the Internet has different criteria than
> ITU-T networks may have". Internet adoption follows different patterns
> than adoption in the ITU primary target markets. For example, the
> Internet has more consumer-reconfigurable software, while the ITU  
> has to
> deal with a lot of fixed hardware deployments. At the ITU, it makes
> sense to invest large sums of money into testing and  
> characterisation of
> codecs because the codecs deployed there usually stay around for a  
> long
> time and the infrastructure investments are usually very large. On the
> other hand, I would say the investments in codecs for the Internet are
> comparatively smaller and, while testing is still important, it is not
> as critical as it is for the ITU.
>
> It's also a choice one has to make. It is unlikely that companies  
> would
> invest money in expensive testing if they are not going to obtain
> royalties in return. However, I think we may be able to define some  
> more
> lightweight (collaborative?) testing that is sufficient and doesn't
> involve as much investments as what the ITU does. For the Internet, I
> believe an IPR-free codec that everyone agrees performs well is better
> than a patent-encumbered codec that has had more extensive testing.  
> This
> is again another difference with the ITU: patent-encumbered codecs  
> tend
> to hurt a lot more on the Internet because many applications (e.g.
> giving away the client) are very hard (or impossible) when one has to
> pay per-channel royalties.
>
> As for the source code issue you pointed out, all the Xiph codecs are
> already published under a very permissive open source license (BSD),  
> so
> this would not really change.
>
>    Jean-Marc
>
>> Roni
>>
>>
>>
>> *From:* avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] *On Behalf
>> Of *Slava Borilin
>> *Sent:* Monday, June 01, 2009 11:50 PM
>> *To:* jean-marc.valin@octasic.com
>> *Cc:* avt@ietf.org; Jason Fischl
>> *Subject:* Re: [AVT] [dispatch] Proposal to form Internet Wideband
>> Audio Codec WG
>>
>>
>>
>> Agree with Jean-Marc.
>> SPIRIT is interested to contribute as well - having a dozen of  
>> proprietary
> codecs developed, including
>> one specifically desgined for internet (SPIRIT IP-MR, which is now  
>> under
> WGLC on draft-ietf-avt-rtp-ipmr-04) -
>> multi-rate, scalable, adaptive, wideband codec.
>>
>> We can also continue this work with IETF.
>>
>> Moreover, most if not all efforts coming from ITU on codecs  
>> unfortunately
> are NOT really focused on
>> internet-specific codecs (that's why several companies have had to  
>> invent)
> - as ITU preference is mainly
>> specific (i.e. cellular) networks at first.
>>
>> however, as we see the greant rise of pure "internet-basd  
>> communications"
> (skype, webex/citrix, and many others) -
>> we all (and users) are suffering from inefficiency in all currently
> "standard" codecs and ambiguity in the choice of
>> internet-targeted ones.
>>
>> Again, we probably can put together enough number of contributors  
>> to the
> WG to have the expertise.
>>
>> regards,
>> Slava Borilin
>>
>> --
>> John Lazzaro wrote:
>>
>>    A traditional response to this type of request is to note that the
> IETF
>>
>>    really doesn't have much in the way of expertise in audio codec
> design.
>>
>>    I don't see many of the regulars who present at the AES codec  
>> paper
> sessions
>>
>>    posting here on AVT (ditto ICASSP paper sessions for voice  
>> codecs).
> It's
>>
>>    a full-time job to keep up-to-date and contribute to that
>>
>>    signal-processing lore.
>>
>>
>>
>> Well, there's no reason that the IETF cannot build such an expertise
>> in audio codecs. This is actually something in which I'd be  
>> interested
>> in getting involved and I'm sure others at Xiph.Org would be
>> interested as well. We have several people with audio codec expertise
>> from working on Vorbis, Speex and (more recently) CELT. It turns out
>> that the CELT codec currently under development at Xiph actually  
>> meets
>> most of the requirements from the original proposal in being a very
>> low delay codec with adaptive bit-rate and sampling rate (up to 48
>> kHz), scalable complexity, and good robustness to packet loss. We'd  
>> be
>> willing to continue the development with the IETF. Even if not with
>> CELT, it's still like to be involved in such a new WG.
>>
>> Cheers,
>>
>>   Jean-Marc
>
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt
>