Re: [codec] RTP Payload Format and File Storage Format for Opus Speech and Audio Codec

Re: [codec] RTP Payload Format and File Storage Format for Opus Speech and Audio Codec - draft-spittka-payload-rtp-opus-00

"Roni Even" <ron.even.tlv@gmail.com> Tue, 05 July 2011 21:17 UTC

From: Roni Even <ron.even.tlv@gmail.com>
To: bens@alum.mit.edu, julian.spittka@skype.net
References: <00f501cc3aa7$551264c0$ff372e40$@spittka@skype.net> <4E133E21.3050001@fas.harvard.edu>
In-Reply-To: <4E133E21.3050001@fas.harvard.edu>
Date: Wed, 06 Jul 2011 00:15:21 +0300
Message-ID: <4e137f74.9545d80a.4f62.65af@mx.google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: Acw7MjMua76S7kZPQoSi4yd0CWWc9wAJXgQQ
Content-Language: en-us
Cc: codec@ietf.org, payload@ietf.org
Subject: Re: [codec] RTP Payload Format and File Storage Format for Opus Speech and Audio Codec - draft-spittka-payload-rtp-opus-00
Precedence: list

Hi,
I find it difficult to address all you comments being in XML patch format.
In general the payload specification should provide enough information that
will enable the reader to create or parse the RTP payload without
understanding the codec payload based on the payload specification. As such
it is useful to provide information that will explain the general concepts
of the codec and the optional parameters. So I find sections 1 and 3 useful
and they should be in the document
Roni Even
   

> -----Original Message-----
> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf
> Of Benjamin M. Schwartz
> Sent: Tuesday, July 05, 2011 7:39 PM
> To: julian.spittka@skype.net
> Cc: codec@ietf.org
> Subject: Re: [codec] RTP Payload Format and File Storage Format for
> Opus Speech and Audio Codec - draft-spittka-payload-rtp-opus-00
> 
> On 07/04/2011 08:06 PM, Julian Spittka wrote:
> > Any feedback, questions, or comments are highly welcome.
> 
> Thank you for doing this work.  I think your proposed RTP and SDP
> formats are very nice and a good step for us.
> 
> I have a few comments.
> 
> 1.  I think the description of Opus should be removed.  There's no need
> to duplicate the contents of the Opus RFC.
> 
> 2.  I think the payload specification should make (almost) no mention
> of Opus frames, modes, etc.  These aspects of Opus are entirely
> internal to the payload, which is a "black box".  As far as the RTP
> specification is concerned, Opus consists of (almost-)arbitrary-
> duration "packets" and that's it.
> 
> 3.  To avoid confusion, I think we should be very careful and clear
> about the distinction between audio bandwidth and samplerate, as their
> relationship in Opus is far from simple.
> 
> I have implemented these ideas, along with a few minor changes, as a
> patch to the draft .xml, attached.  Please feel free to discard this
> patch; I mean it only as a way to communicate my suggestions more
> clearly.
> 
> --Ben

[codec] RTP Payload Format and File Storage Forma… Julian Spittka
Re: [codec] RTP Payload Format and File Storage F… Gregory Maxwell
Re: [codec] RTP Payload Format and File Storage F… Kevin P. Fleming
Re: [codec] RTP Payload Format and File Storage F… Timothy B. Terriberry
Re: [codec] RTP Payload Format and File Storage F… Benjamin M. Schwartz
Re: [codec] RTP Payload Format and File Storage F… Roni Even
Re: [codec] RTP Payload Format and File Storage F… Roni Even
Re: [codec] RTP Payload Format and File Storage F… Cullen Jennings
Re: [codec] RTP Payload Format and File Storage F… Magnus Westerlund
Re: [codec] RTP Payload Format and File Storage F… Cullen Jennings
Re: [codec] RTP Payload Format and File Storage F… Benjamin M. Schwartz
Re: [codec] [payload] RTP Payload Format and File… Benjamin M. Schwartz