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

"Christian Hoene" <hoene@uni-tuebingen.de> Tue, 26 July 2011 11:35 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 AF12D21F8C58 for <codec@ietfa.amsl.com>; Tue, 26 Jul 2011 04:35:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.891
X-Spam-Level:
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 mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ee+Hkqc8Crfa for <codec@ietfa.amsl.com>; Tue, 26 Jul 2011 04:35:52 -0700 (PDT)
Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by ietfa.amsl.com (Postfix) with ESMTP id D7BE621F86D8 for <codec@ietf.org>; Tue, 26 Jul 2011 04:35:51 -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 p6QBZdUX003829 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 26 Jul 2011 13:35:47 +0200
From: "Christian Hoene" <hoene@uni-tuebingen.de>
To: "'Jean-Marc Valin'" <jmvalin@jmvalin.ca>
References: <014401cc4b13$d8024130$8806c390$@uni-tuebingen.de> <4E2DE4EE.5080905@jmvalin.ca>
In-Reply-To: <4E2DE4EE.5080905@jmvalin.ca>
Date: Tue, 26 Jul 2011 07:35:39 -0400
Organization: =?us-ascii?Q?Universitat_Tubingen?=
Message-ID: <00a701cc4b88$2afa6470$80ef2d50$@uni-tuebingen.de>
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: 3.2.1.23; host: mx06)
Cc: codec@ietf.org
Subject: Re: [codec] [payload] Padding in draft-ietf-codec-opus-07?
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: 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
frames. 

Is this ok for you?

With best regards,

 Christian Hoene