Re: [codec] [payload] Padding in draft-ietf-codec-opus-07?

"Christian Hoene" <> Tue, 26 July 2011 11:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AF12D21F8C58 for <>; Tue, 26 Jul 2011 04:35:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.891
X-Spam-Status: No, score=-5.891 tagged_above=-999 required=5 tests=[AWL=0.358, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ee+Hkqc8Crfa for <>; Tue, 26 Jul 2011 04:35:52 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D7BE621F86D8 for <>; Tue, 26 Jul 2011 04:35:51 -0700 (PDT)
Received: from hoeneT60 ( []) (authenticated bits=0) by (8.13.6/8.13.6) with ESMTP id p6QBZdUX003829 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 26 Jul 2011 13:35:47 +0200
From: Christian Hoene <>
To: 'Jean-Marc Valin' <>
References: <014401cc4b13$d8024130$8806c390$> <>
In-Reply-To: <>
Date: Tue, 26 Jul 2011 07:35:39 -0400
Organization: Universitat Tubingen
Message-ID: <00a701cc4b88$2afa6470$80ef2d50$>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHI2mT5Dk41BdmpxajmPTQSZRiv4gMN173ZlOzqI4A=
Content-Language: de
X-AntiVirus: NOT checked by Avira MailGate (version:; host: mx06)
Subject: Re: [codec] [payload] Padding in draft-ietf-codec-opus-07?
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Codec WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 26 Jul 2011 11:35:52 -0000

Good morning Jean-Marc,

> >> Well, it is possible for Opus to be transmitted in real-time over
> >> something other than RTP.
> >
> >  [Christian Hoene] Yes, now I remember the discussion. You are meaning
> > Bluetooth links, don't you?
> I meant anything other than RTP, like plain UDP, websockets, RTMFP and
> whatnot.

[Christian Hoene] In order to bring this issues form the table fast, I would
suggest to look for a compromise.

My first suggestion:

a) Move the Chapter 3 to a non-normative Appendix and explain that is
intended for plain UDP and TCP, websockets, RTMFP, Bluetooth, ...
b) Copy Chapter 3 to the payload specification and let the PAYLOAD WG decide
on further modifications as they are the experts in framing and padding.
c) In order to support transmission over TCP, I would recommend a change of
mode c=3: A length is given to the last frame in the packet of multiple

Is this ok for you?

With best regards,

 Christian Hoene