[codec] Draft 07: Chapter 3 Editorial comments

"Christian Hoene" <hoene@uni-tuebingen.de> Mon, 25 July 2011 17:41 UTC

Return-Path: <hoene@uni-tuebingen.de>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41F6321F8BF5 for <codec@ietfa.amsl.com>; Mon, 25 Jul 2011 10:41:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.677
X-Spam-Level:
X-Spam-Status: No, score=-5.677 tagged_above=-999 required=5 tests=[AWL=0.572, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R4WMZBi8Yvlt for <codec@ietfa.amsl.com>; Mon, 25 Jul 2011 10:41:55 -0700 (PDT)
Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by ietfa.amsl.com (Postfix) with ESMTP id A1B0A21F8BED for <codec@ietf.org>; Mon, 25 Jul 2011 10:41:54 -0700 (PDT)
Received: from hoeneT60 (modemcable004.100-203-24.mc.videotron.ca [24.203.100.4]) (authenticated bits=0) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id p6PHfhIN030132 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <codec@ietf.org>; Mon, 25 Jul 2011 19:41:52 +0200
From: "Christian Hoene" <hoene@uni-tuebingen.de>
To: <codec@ietf.org>
Date: Mon, 25 Jul 2011 13:41:43 -0400
Organization: =?iso-8859-1?Q?Universit=E4t_T=FCbingen?=
Message-ID: <008901cc4af2$23361630$69a24290$@uni-tuebingen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AcxK8hqvcStoyq9aRR2/GK2+xScpMg==
Content-Language: de
X-AntiVirus: NOT checked by Avira MailGate (version: 3.2.1.23; host: mx06)
Subject: [codec] Draft 07: Chapter 3 Editorial comments
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Jul 2011 17:41:56 -0000

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 +49 7071 2970532,
www.net.uni-tuebingen.de