[codec] Draft 07: Chapter 3 Editorial comments

["Christian Hoene" <[e-mail]>]

Dear Authors,

beside my fundamental critics on Section 3 of draft-ietf-codec-opus-07 (see
previous email), I have a couple of editorial comments to the chapter.

The text is fine till „A well-formed Opus packet MUST contain at least one
byte with the TOC Information, though the frame(s) within a packet MAY be
zero bytes long“. 

The sentence „It must also obey various additional rules indicated by
"MUST", "MUST NOT", etc., in this section.“  is superfluous and can be
dropped.

I would move „A receiver MUST NOT process packets which violate these rules
as normal Opus packets. They are reserved for future applications, such as
in-band headers (containing metadata, etc.) or multichannel support.“  to an
additional subsection that explains on how to extend the codec format for
future applications. This section could also include a description of how
these extensions might look like.

I would also suggest to introduce subsections for each value of the
parameter c:
•	Section 3.1 “One frame in the packet”
•	Section 3.2. “Two frames in the packet, each with equal compressed
size”
•	Section 3.3. “Two frames in the packet, with different compressed
sizes”
•	Section 3.4 “An arbitrary number of frames in the packet”
Currently, the description for these modes is mixed up a bit.  For example
the text starting at “When a packet contains multiple VBR frames,” till “to
allow for repacketization by gateways, conference bridges, or other
software.” can be moved to Section 3.4.

The sentence “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.” does not
sound well to my German ears. Maybe one can rephrase it to “The last frame
in a VBR packet is not preceded by a length field as the length can be
inferred from the total size of the packet and the size of all other data in
the packet.  The remaining “or any of the frames in a CBR packet” can be
moved to Section 3.2.

Please add “Section 3.1 “One frame in the packet”  in front of “For code 0
packets, …” 

I find the notion “frame” and “packet” quite confusing as “packet” might be
misunderstood as IP or UDP or RTP packet. Other codec standards use
“subframe” and “frame”.

Please add “Section 3.3. Two frames in the packet, with different compressed
sizes”.

Here you can add the text from above describing the format “N1”. For a
better understanding, I would paint two figures. In the first N1 format has
a size of 1 bytes, in the second figure N1 has a size of two bytes.

“The  length of the first frame, N1, MUST be no larger than the size of the
payload remaining after decoding that length for all code 2 packets”. Please
rephrase as I do not understand: The frame must not be larger than the
packet?

Some more technical comments on padding:

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.

Do you have any definition of “compressed frame” or “compressed data”. These
terms are shown in the Figures.

That is enough for now. I need a break…

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 [phone],
www.net.uni-tuebingen.de