Re: [codec] it MUST NOT exceed 1275 bytes?

[Gregory Maxwell <[e-mail]>]

Christian Hoene [[e-mail]] wrote:
> 3) The requirement "Repacketization by gateways, conference bridges, or
> other software." is not listed in the requirements draft. As I still believe
> in the end-to-end principle, I also do not see the need for this
> requirement. Why do you need an Opus-to-Opus gateway if have can have
> end-to-end or if you can use a TURN server?
> BTW conference bridges mix audio streams.

Unfortunate as it may be, connectivity is not always end to end.  People may
deploy gateways for useful purposes as applying repackaization to make
better use of low capacity networks even if the far end is not cooperating.

While the gateway applications did not end up enumerated as requirements
they certainly were discussed here.

The ability to pack multiple frames is also requirement for the ability to
produce constant duration packets even if the underlying transform block
size is changing due to changing signal characteristics.  As such this
is deeply a codec layer issue, as it allows the codec to be able to meet
a reasonable requirement (constant duration frames) while changing
modes based on its coding analysis.

I don't think it's enough to say that something could be removed—
there are many things that could be removed: Shall we remove the
codec's effectiveness for encoding speech in Pig Latin because
that was never mandated in the requirements?

Removing the ability to encode multiple frames would not even
save one byte per packet in the case where it is not used. So
what would be the benefit?


> Padding is support because of security reasons as VBR frame size might leaks
> information. But in the draft, you support padding mainly for VBR having
> multiple frames? Multiple VBR frames concatenated in one packet do leak even
>less information than single frames….
> I just want to note again that “padding” has not been listed in the
> requirement draft and thus can be dropped.

Any frame can be encoded with the the N frames of VBR header type, it just
takes more channel capacity in those cases. The fact that padding is
limited to this one header type means that the padding signaling
costs zero bits in general.

If not for padding— which could not be supported with zero overhead if done
externally (you'd probably have to shim another bit, or more likely byte, on every
packet to indicate its presence)— what else would you define the remaining
bit in that particular header type to be?

What cost do you perceive this feature to have, and what benefit would
we enjoy by removing it?