Re: [codec] WG Review: Internet Wideband Audio Codec (codec)

[Daniel Petrie <[e-mail]>]

Hi Roni:
I agree that transporting this information is code independent information.  However calculating these as part of the encoding may be possible significant performance savings depending upon the codec algorithm.

Cheers,
Dan

--- On Wed, 1/13/10, Roni Even <[e-mail]> wrote:

> From: Roni Even <[e-mail]>
> Subject: RE: [codec] WG Review: Internet Wideband Audio Codec (codec)
> To: [e-mail], "'Alexander Chemeris'" <[e-mail]>, "'Christian Hoene'" <[e-mail]>
> Cc: [e-mail]
> Date: Wednesday, January 13, 2010, 3:53 PM
> Daniel,
> These are not a codec specific information and there is
> work on it in AVT.
> See
> http://tools.ietf.org/id/draft-lennox-avt-rtp-audio-level-exthdr-01.txt
> and
> there is also
> http://tools.ietf.org/id/draft-ivov-avt-slic-02.txt
> which provides
> information to the receiver.
> 
> Roni Even
> 
> > -----Original Message-----
> > From: [e-mail]
> [mailto:[e-mail]]
> On Behalf
> > Of Daniel Petrie
> > Sent: Wednesday, January 13, 2010 7:54 PM
> > To: 'Alexander Chemeris'; Christian Hoene
> > Cc: [e-mail]
> > Subject: Re: [codec] WG Review: Internet Wideband
> Audio Codec (codec)
> > 
> > While we are discussing conferencing, I would like to
> add my wish list
> > of requirements:
> > 
> > I would want the following information included in the
> RTP packet so
> > that I can do speaker selection on the streams without
> having to have
> > the expense of decoding them and run the algorithms to
> calculate these
> > values.  This is useful in all 3 of Christian's
> conferencing scenarios.
> > 
> > 1) Voice activity indication (minimally binary,
> ideally magnitude)
> > 2) gain control either already applied or a multiplier
> to apply to
> > achieve a consistent gain.
> > 3) Energy level
> > 
> > --- On Wed, 1/13/10, Christian Hoene <[e-mail]>
> wrote:
> > 
> > > From: Christian Hoene <[e-mail]>
> > > Subject: Re: [codec] WG Review: Internet Wideband
> Audio Codec (codec)
> > > To: "'Alexander Chemeris'" <[e-mail]>
> > > Cc: [e-mail]
> > > Date: Wednesday, January 13, 2010, 5:55 AM
> > > > This codec should be also useful
> > > in
> > > > conference
> > > > scenarios, where you have to decode it at
> conference
> > > server and encode
> > > > mixed signal again. And if I haven't missed
> something,
> > > this use-case
> > > > was
> > > > explicitly listed in codec requirements.
> > >
> > > The conferencing scenario is not yet well
> described in the
> > > current codec requirements document. Different
> kinds of
> > > systems are possible:
> > >
> > > 1) A central conferencing server that serves all
> clients.
> > > - a) which does a efficient single changing
> mixing - still
> > > a challenge if you have multiple operational
> modes in a
> > > codec.
> > > - b) which does a more intelligent mixing using
> (at least)
> > > two channels to support spatial hearing - this
> increases the
> > > quality of conference call significant. Thus,
> stereo modes
> > > must be supported if the codec shall support
> state of the
> > > art conferencing technologies.
> > > 2) A mesh-like N-to-N transmission conference
> call. Then
> > > you might benefit from layered coding because you
> have at a
> > > client you have to encode only once. But then
> again, how to
> > > support multiple coding modes?
> > > 3) One client acts as conference server (similar
> to 1)
> > >
> > > In total, the support of conferencing calls will
> require:
> > > - Layered coding
> > > - Efficient mixing of streams
> > > - Support of stereo
> > > - Good (self-)transcoding
> > > Is this all achievable?
> > >
> > > Christian
> > >
> > >
> > > _______________________________________________
> > > codec mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/codec
> > >
> > _______________________________________________
> > codec mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/codec
> 
>