Re: [codec] additional topics for discussion

Roman Shpount <roman@telurix.com> Fri, 09 April 2010 16:20 UTC

Return-Path: <roman@telurix.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 D8FB028C0E4 for <codec@core3.amsl.com>; Fri, 9 Apr 2010 09:20:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.976
X-Spam-Level:
X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
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 CbcsDtL7Vo0u for <codec@core3.amsl.com>; Fri, 9 Apr 2010 09:20:24 -0700 (PDT)
Received: from mail-pz0-f191.google.com (mail-pz0-f191.google.com [209.85.222.191]) by core3.amsl.com (Postfix) with ESMTP id A6A5028C0FC for <codec@ietf.org>; Fri, 9 Apr 2010 09:20:17 -0700 (PDT)
Received: by pzk29 with SMTP id 29so2968862pzk.29 for <codec@ietf.org>; Fri, 09 Apr 2010 09:19:57 -0700 (PDT)
Received: by 10.114.214.26 with SMTP id m26mr425145wag.204.1270829992907; Fri, 09 Apr 2010 09:19:52 -0700 (PDT)
Received: from mail-iw0-f194.google.com (mail-iw0-f194.google.com [209.85.223.194]) by mx.google.com with ESMTPS id c21sm988552ibr.10.2010.04.09.09.19.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 09 Apr 2010 09:19:52 -0700 (PDT)
Received: by iwn32 with SMTP id 32so2173617iwn.18 for <codec@ietf.org>; Fri, 09 Apr 2010 09:19:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.14.205 with HTTP; Fri, 9 Apr 2010 09:19:49 -0700 (PDT)
In-Reply-To: <C7E47C33.14368%mknappe@juniper.net>
References: <C7E47C33.14368%mknappe@juniper.net>
Date: Fri, 9 Apr 2010 12:19:49 -0400
Received: by 10.231.59.5 with SMTP id j5mr125603ibh.6.1270829989433; Fri, 09 Apr 2010 09:19:49 -0700 (PDT)
Message-ID: <g2p28bf2c661004090919x5ea55a3bp8c62aa6fdd47b462@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Michael Knappe <mknappe@juniper.net>
Content-Type: multipart/alternative; boundary=001485e7c9fc1715780483d02a57
Cc: "codec@ietf.org" <codec@ietf.org>
Subject: Re: [codec] additional topics for discussion
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, 09 Apr 2010 16:20:26 -0000

Couple more items I wanted to raise:

1. Should VAD and separate noise encoding be a mandatory part of this codec?
As a conferencing server vendor I would be very interested in client doing
VAD, allowing the conferencing server only to decode and mix (or just pass
through without transcoding) speech audio.

2. Ability to efficiently combine pre-encoded audio into a single stream.
For instance, if a server needs to play an announcement it would be nice to
be able to send pre-encoded, cached audio data to the client in such a way
that decoder will reset its state and decode this audio properly. Or, in
case of conference server, to switch to another audio source without the
need to decode and encode the audio again.
_____________________________
Roman Shpount - www.telurix.com


On Fri, Apr 9, 2010 at 9:39 AM, Michael Knappe <mknappe@juniper.net> wrote:

> We’ve had some good discussion around DTMF carriage and tandem/transcode
> situations, let’s continue to open up discussion to other points of
> interest. Here’s a few that we’ve had some initial discussion about at
> IETF77 and/or on the mailing list:
>
> 1. sample rates: which sample rate(s) will the proposed codec support? If
> more than one, will one of the sample rates be a MUST handled by all
> implementations, with the others optional dependent on the capabilities of
> the endpoint? Will each sample rate variation of the codec be treated as a
> unique codec as far as SDP negotiation is concerned?
> 2. joint stereo/channel coding: will joint channel coding be supported,
> perhaps optionally?
> 3. multi-channel frame ordering: what channel naming and ordering scheme
> will we support or specify for packing variations of multiple channels in
> each frame?
> 4. packet loss concealment: will PLC be a mandatory component of the codec?
> Will the codec provide an implementation of PLC, but with the hooks to allow
> different and potentially improved (or network condition specific)
> implementations of PLC to be substituted in the codec?
> 5. bit-exact vs. bit-compatible: will all variations of the codec allow
> bit-compatible implementation, or will we specify a bit-exact variation of
> the codec (e.g. Specifying a bit-exact fixed point implementation of the
> lowest sample rate variation of the codec)?
> 6. reference use-cases and topologies: let’s start putting together a doc
> of use-cases and topologies that we expect the proposed codec to operate in.
> This will be useful for both determining implementation characteristics of
> the codec as well as its test regimen. Any takers for kicking this off?
> 7. quality assessment / qualification process: we need to begin putting
> together a doc that details how we will assess the proposed codec, anyone
> interested in working on this?
>
> Comments and discussion welcome!
>
> Cheers,
>
> Mike
> _______________________________________________
> codec mailing list
> codec@ietf.org
> https://www.ietf.org/mailman/listinfo/codec
>