Subject: [codec] additional topics for discussion

From: Michael Knappe <[email-masked]>
Date: Fri, 9 Apr 2010 06:39:47 -0700

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

---

From: Roman Shpount <[email-masked]>
Date: Fri, 9 Apr 2010 12:19:49 -0400

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 <[email-masked]> 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?
> 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?
>
> _______________________________________________
> codec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/codec
>