Re: [codec] requirements #8 (new): Sample rates?

[Gregory Maxwell <[e-mail]>]

Butrus Damaskus [[e-mail]] wrote:
> On Thu, Jan 27, 2011 at 4:12 AM, Pascal Pochol <[e-mail]> wrote:
>> in our case I don't even think that we need a per packet signal to tell the
>> decoder. Unless the Opus-custom encoder does something that varies per
>> packet we usually set the parameters up front and never change them when
>> encoding a stream. We could have a little header packet to set things up or
>> since we're in total control simply set the parameter in the initialization
>> of the decoder with a few api calls. Not sure if that would work for others
>> but in our case I think it would without adding extra information to the
>> packets.
>
>Well, but you probably need at least one bit to signal header/data packets, no?

No— the codec itself doesn't carry quite a bit of information which is important
to applications already. E.g. it doesn't carry timing.  These things are left
to upper level protocols to handle.

The same can, and should, be done for configuration negotiation. The reason for
this is that the transport can be well adapted to the environment.   If there were
a 'header packet' that the codec generated only once and sent as part of
the bitstream, if that packet were lost the all the rest of the audio would be
undecodable.   So the only real options are: send it every packet or leave it
for another mechanism to handle.

Even if you wanted to reinvent a whole two way negotiation machine inside the
codec— you couldn't really, because you can't depend on the usage being
duplex.

For modes which can be reasonably switched on the fly sending it in every
packet provides some value.  For ones which can't be— sending it in every
packet is overhead, and worse— a possible opening for a malicious
transmitter to trigger poorly tested corner-cases.

A complete selection of modes that CELT can operate in (when restrictions to
simplify implementation are not imposed) takes about 4 bytes, more if you 
want to add some length coding in order to support packing multiple codec
frames in one packet.   Thats a pretty high overhead for a 64 sample/frame 
mode which is sending 700pps, especially in the case of a lossless
transport for which the configuration would only ever have to be sent once.

So, I think that in packet signaling should generally be limited only
to signalling switches that the codec can actually do on the fly, and
I think for the opus-custom modes it's probably better to not signal in
the packets at all.  If an application needs switching for opus-custom,
it could define a new encapsulation for its transport which provides for it.