[codec] Codec requirements discussion summary from IETF78

Michael Knappe <mknappe@juniper.net> Fri, 08 October 2010 15:54 UTC

Return-Path: <mknappe@juniper.net>
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 C5ADE3A686B for <codec@core3.amsl.com>; Fri, 8 Oct 2010 08:54:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.042
X-Spam-Level:
X-Spam-Status: No, score=-106.042 tagged_above=-999 required=5 tests=[AWL=0.557, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 jda+YnnrnisK for <codec@core3.amsl.com>; Fri, 8 Oct 2010 08:53:59 -0700 (PDT)
Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id 835B03A686A for <codec@ietf.org>; Fri, 8 Oct 2010 08:53:59 -0700 (PDT)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKTK8+2CB2LGshqGS/dvkSGpBKg44WGcok@postini.com; Fri, 08 Oct 2010 08:55:04 PDT
Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Fri, 8 Oct 2010 08:49:26 -0700
From: Michael Knappe <mknappe@juniper.net>
To: "codec@ietf.org" <codec@ietf.org>
Date: Fri, 08 Oct 2010 08:49:21 -0700
Thread-Topic: [codec] Codec requirements discussion summary from IETF78
Thread-Index: ActnAF9+Yn5EMnBCXUKMo+pFICRvFw==
Message-ID: <C8D48B91.1E215%mknappe@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-Entourage/13.3.0.091002
acceptlanguage: en-US
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [codec] Codec requirements discussion summary from IETF78
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, 08 Oct 2010 15:54:00 -0000

Below is a brief summary of the discussion Q&A around the requirements doc held at IETF78. Please refer to the audio ( http://nagasaki.bogus.com/ietf78/ietf78-ch8-mon-noon.mp3) and jabber archives for details.

Jean-Marc and Koen, can you update the requirements doc to reflect consensus achieved on the 4 points below?

Thanks,

Mike

IETF 78 requirements discussion summary
==================================


 1.  Q: should we have SDP selectable audio bandwidths? Discussion: RTP payload formats (sample rates and channel ordering) should be discussed in AVT. Need to come up with specific proposal(s) for the negotiation of preferred bitrate / internal sample rate. One suggestion was simply provisioning invites with the highest preferred rate for the codec in the SDP offer as first preference, with lower bit rates in succession as desired.
 2.  Q: what is a reasonable upper bit rate for the codec? Discussion: 128 kbps as an upper bit rate limit seems to be reasonable (further clarification needed – is that 128 kbps per channel?), will continue codec development and see what bit rates are offered before any decisions are made on allowable bit rate ranges
 3.  Q: shall we implement sample rate layering? Discussion: prototype codec in discussion already implements a two layer scheme
 4.  Q: shall we provide a bit exact implementation? Discussion: consensus to be optional with no requirement for bit exactness, where interest lay in the optional specification of a bit exact implementation as one possible implementation among other bit compatible versions
 5.  Q: shall we provide a joint stereo mode? Discussion: consensus as highly desirable where it provides a bit-rate reduction benefit (or conversely a quality improvement at the same bit-rate) at reasonable computational cost. Some anecdotal evidence of 35% or better bit-rate savings noted, further study needed.
 6.  Q: shall we provide a low-delay mode? Discussion: consensus as desirable, already implemented as a mode in prototype codec as 5 ms total (2.5 ms look-ahead + 2.5 ms frame size)
 7.  Q: shall we provide a basic packet-loss concealment mechanism? Discussion: consensus that an informative version of the PLC mechanism be included in the codec specification, with the ability to replace that mechanism with another implementation.