Re: [codec] #15: Efficiently combine pre-encoded audio

[Roman Shpount <[e-mail]>]

I would like to remind that this issue is not about efficient VAD, but
about efficiently combining pre-encoded streams. There are two use
cases that I can think of:

a. Conference servers, where the active speaker was determined by
either receiver or decoder side VAD. As it was mentioned before, it is
possible to implement an efficient decoder side VAD without
implementing a complete decoder. If we can combine pre-encoded audio
we can combine multiple streams on the conference server without going
through decoder/encoder cycle greatly decreasing both CPU requirements
and mixer delay.

b. Announcement and IVR servers, where a small set of pre-encoded
announcements are played to the user. Standard network or IVR
announcements can be encoded once and efficiently inserted or combined
into audio stream. If pre-encoded audio is supported and the client
supports AVT tones, it is trivial to develop a very efficient IVR
server  which does not require any CODEC encoding or decoding.
_____________
Roman Shpount



On Mon, May 24, 2010 at 10:22 AM, codec issue tracker
<[e-mail]> wrote:
> #15: Efficiently combine pre-encoded audio
> ------------------------------------+---------------------------------------
>  Reporter:  hoene@…                 |       Owner:
>     Type:  enhancement             |      Status:  new
>  Priority:  minor                   |   Milestone:
> Component:  requirements            |     Version:
>  Severity:  Active WG Document      |    Keywords:
> ------------------------------------+---------------------------------------
>
> Comment(by hoene@…):
>
>  [Cullen]:
>  For conference bridges, it's probably more important to be able to decide
>  who the active speakers are with low CPU complexity than the actually act
>  of mixing the the selected speakers. Consider a typical call with 7 people
>  who might be speakers and  the 3 most active are selected and mixed. In
>  many systems today, most the MIPS goes to decoding all 7 streams to do
>  speaker detection before the resulting 4 streams are formed and encoded.
>  If there was a cheap way to figure out who the active speakers were
>  without doing a full decode of all 7 streams, that would be sort of nice
>  the for conferences bridges.
>
>  [Brian]: Excellent idea.  Been there, never really did it.  It's complex.
>  Effectively, you need a distributed adaptive threshold mechanism.
>  However, if you had it, user experience in multispeaker environments gets
>  a win.
>
>  [Benjamin]:  The cheapest solution, of course, is transmit-side activity
>  detection.
>  Maybe we need to specify a way for a receiver to request that the
>  transmitter employ (or not employ) VAD.
>
>  [JM]:
>  I think you can do better than an encoder VAD. All you need to do is make
>  sure that the relevant information you need for a VAD can easily be
>  decoded from the bit-stream without having to do a full decoding. For
>  example, if you're able to easily extract the gain and spectral envelope,
>  you can do a VAD based on that without even having to look at the other
>  parameters in the bit-stream.
>
>  [Brian]:
>  The adaptive threshold doesn't have to be distributed, as the conference
>  bridge is selecting the highest scores.
>  You do need a consistent way to compute the scores in the endpoints,
>  ideally using a method which is not simply energy.
>  I realize the bridge can alternatively generate scores from bitstream
>  information; I am thinking that is equivalent to including a metric in the
>  RTP payload.
>
> --
> Ticket URL: <http://trac.tools.ietf.org/wg/codec/trac/ticket/15#comment:2>
> codec <http://tools.ietf.org/codec/>
>
> _______________________________________________
> codec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/codec
>