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

From: "Roni Even" <[email-masked]>
Date: Wed, 6 Jul 2011 00:15:21 +0300

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: [email-masked] [mailto:[email-masked]] On Behalf
> Of Benjamin M. Schwartz
> Sent: Tuesday, July 05, 2011 7:39 PM
> To: [email-masked]
> Cc: [email-masked]
> 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

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 6 Jul 2011 10:43:45 -0600

I would prefer to see the file format separated into a separate draft for two reason. One, it allows an implementation to say they do RFC XXXX and have that be clear if the mean the RTP payload or the file format. Two, I suspect the file format conversation might take longer to resolve. 

Cullen

PS - this discussion and draft needs to happen in the payloads WG, feel free to CC the [email-masked] mailing list.

On Jul 4, 2011, at 6:06 PM, Julian Spittka wrote:

> All,
> 
> Please find a first draft "draft-spittka-payload-rtp-opus-00" for the "RTP
> Payload Format and File Storage Format for Opus Speech and Audio Codec"
> uploaded at
> https://datatracker.ietf.org/doc/draft-spittka-payload-rtp-opus/. 
> 
> Best Regards,
> Julian.
> ---
> Julian Spittka
> Skype
> see & chat: julian_spittka
> write: [email-masked]
> 
> 
> _______________________________________________
> codec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/codec

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 7 Jul 2011 12:53:30 +0200

> PS - this discussion and draft needs to happen in the payloads WG, feel free to CC the [email-masked] mailing list.

Cullen, I assume you mean CODEC WG rather than the RTCWEB WG.

Cheer

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 7 Jul 2011 08:29:17 -0600

> Cullen, I assume you mean CODEC WG rather than the RTCWEB WG.

yes - thank you. too much RTCweb on my mind and was just typing while on a call. Always bad to do

---

From: "Benjamin M. Schwartz" <[email-masked]>
Date: Sat, 09 Jul 2011 00:30:16 -0400

> and they should be in the document

Despite having removed Section 3 in my suggested edit, I agree.  The
payload document should present relevant information about Opus, such as
the available frame sizes and the significance of the low-bitrate
redundancy feature.  However, it should not discuss non-normative
behaviors of the reference coder, or internal details such as subsampling
and coding modes.

The most important thing to understand about Opus coding modes is that the
encoder can, and does, dynamically switch among them on a packet-by-packet
basis in order to optimize quality.  The draft seems to have been written
under the assumption that a stream, once started in a particular mode, may
not be able to switch to other modes.   This is no longer true, as
explained in the latest Opus draft.

--Ben