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

From: "Christian Hoene" <[email-masked]>
Date: Mon, 25 Jul 2011 13:18:33 -0400

Hi,

I am reading "draft-ietf-codec-opus-07", chapter 3 page 11:

   No length is transmitted for the last frame in a VBR packet, or any
   of the frames in a CBR packet, as it can be inferred from the total
   size of the packet and the size of all other data in the packet.
   However, it MUST NOT exceed 1275 bytes, to allow for repacketization
   by gateways, conference bridges, or other software.

I do not understand:

1) What must not exceed 1275 bytes, the total length of the payload or the
length of the last VBR frame?

2) What are the calculations behind 1275?

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.

Thanks for explaining me.

 Christian

----------------------------------------------------------------------------
-----
Dr.-Ing. Christian Hoene, University of Tübingen, Computer Science, Chair of
Communication Networks, Research Group Interactive Communication Systems
(ICS)
Sand 13, 72076 Tübingen, Germany, Tel +49 7071 2970532,
www.net.uni-tuebingen.de

---

From: "Benjamin M. Schwartz" <[email-masked]>
Date: Mon, 25 Jul 2011 13:27:09 -0400

> length of the last VBR frame?

The latter.  No Opus frame may ever exceed 1275 bytes.

> 2) What are the calculations behind 1275?

"The maximum representable size is 255*4+255=1275 bytes."

Because the first N-1 frames in a packet cannot have a size greater than
1275, it would be very strange if this were permitted for the final frame.
 An unbounded frame size would also unreasonably increase the minimum
computational performance required of a conformant decoder.

> other software." is not listed in the requirements draft.

Indeed, but the codec has a great deal of useful functionality beyond what
is required in that draft.

> As I still believe
> requirement.

Opus is intended for use beyond the internet.

 Why do you need an Opus-to-Opus gateway if have can have
> end-to-end or if you can use a TURN server? 

An Opus-to-Opus gateway is appropriate when an Opus stream is being moved
between different networks, including non-IP-based networks, with
different limits and overheads related to packet size and rate.

--Ben

---

From: Gregory Maxwell <[email-masked]>
Date: Mon, 25 Jul 2011 11:21:29 -0700

> 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?

---

From: Gregory Maxwell <[email-masked]>
Date: Mon, 25 Jul 2011 11:39:37 -0700

> computational performance required of a conformant decoder.

As Ben and the draft point out, the actual limit comes from the
scheme used to encoded lengths in the multiple packed frames
case.

It's also worth pointing out that 1275 is high enough that the codec is 
at the point where it is often _unable_ to use more rate (and would just
be coding zeros) due to a multitude of internal complications and tradeoffs. 

It's also low enough that the frames will by supportable on common networks
even with a fair amount of higher layer overhead without needing
fragmentation.

In the CELT modes the maximum precision used is limited by the codebook
size (memory trade-off) and band splitting depth (computation trade-off), so
higher rates couldn't be usefully supported without non-trivial worst case
complexity/memory increases for implementations.

And at 510kbit/sec we're at nearly twice the highest ABXable
bitrate for any killer sample I'm currently aware of... leaving plenty of
just-in-case headroom for VBR encoders to throw lots of bits at
challenging sections.

---

From: "Christian Hoene" <[email-masked]>
Date: Mon, 25 Jul 2011 14:46:12 -0400

Hi Gergory,

> modes based on its coding analysis.

[Christian Hoene] Uuh, be careful, there is a Fraunhofer claim on switching
frame sizes depending on signal information. 
The algorithm that you describe is not part of the reference implementation,
isn't it?

> What cost do you perceive this feature to have, and what benefit would

[Christian Hoene] It is the cost of complexity. I am just following the
saying "Everything should be made as simple as possible, but not simpler."

Currently, the Opus draft has a couple of features that do not belong in the
Codec WG nor in the Opus spec. 

Christian

---

From: Gregory Maxwell <[email-masked]>
Date: Mon, 25 Jul 2011 14:59:53 -0700

> The algorithm that you describe is not part of the reference implementation,

The reference implementation does not— though the format allows
for an encoder to choose do this.  (And could not prohibit it without
also breaking switching for other purposes) 

The reasons the reference implementation does are primarily for
encoder complexity  and latency (it's a decision better made with
more look-ahead) not IPR. 

And, to avoid sounding like I agree with your blanket statement should
someone cite this post later for other reasons:

Frame size switching is something which _can_ be done without IP
encumbrance as demonstrated by the established codecs which do this,
(e.g. Vorbis, though there was substantial care taken to do it in a manner
which prevented risk) and the fact that the most commonly
cited patent in this area, though not the one you're talking about,
 is now expired (and, thus, arguably provides strong prior art for some
 implementation approaches).