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

[Jean-Marc Valin <[e-mail]>]

Benjamin M. Schwartz wrote:
>> I think you can do better than an encoder VAD.
> 
> I know that CELT makes decoder VAD very efficient, 

Not only CELT. You can do that with an LPC-based codec too.

> but how is decoder VAD
> better than encoder VAD?  Encoder VAD saves even more CPU, saves
> bandwidth, and enables easier jitter buffering.

There's a few reasons why I think decoder-side is better:
- The decision for an encoder-size VAD would take some amount of space in 
the bit-stream
- If we make an encode-size VAD mandatory, then all encoders will have to 
spend the CPU cycles, even when it's not needed. If it's not mandatory, 
then the decoder cannot rely on it, so it still needs to implement a VAD
- A decoder VAD does not need to be specified in an exact way, so 
implementers can choose different implementations depending on that 
information they need.
- You cannot "game" a decode-size VAD.

> Are you thinking about some sort of adaptive thresholding that requires
> knowing all streams' volume levels?

Well, knowing the relative amplitudes of each stream can allow you to take 
more intelligent decisions, e.g. when you have to choose the "most active 
speaker". That's something you can't really get from an encoder VAD.

> Anyway, VAD can run on both encode and decode sides at the same time.

That would just mean nobody would bother implementing the encode side.

	Jean-Marc