Subject: Re: [payload] 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: Mon, 11 Jul 2011 17:24:43 +0300

Hi,
I reviewed the draft and it is a good start. Based on Cullen recommendation
I am posting to both codec and payload mailing lists.

I did not review the storage format since I understand that it will be
removed from this draft and discussed separately.

I have some comments

1. In the introduction "thus, making it the codec of choice for various
applications using the Internet or similar networks" maybe change to "thus,
making it useful for various applications using the Internet or similar
networks". The first sentence have a market share declaration.

2. In section 3.2 when you talk about network bandwidth what does it mean.
Do you calculate it based on the whole IP packet, the RTP packet or just the
opus payload. I assume it is the last one so please define the term network
bandwidth.

3. in section 3.2.1 you talk about "average bit rate". How do you measure
average bit rate, is it average in 3 minutes, in 1 minute?

4. In section 3.4 "The decision to send "in-band" FEC information is
entirely controlled by the encoder ". This is true only if the decoder
signaled support for FEC.

5. In section 3.5 "If a decoder can not take advantage of the benefits of a
stereo  signal this SHOULD  be indicated at the time a session is set up.
In  that case the sending side SHOULD  NOT send stereo signals as it leads
to an inefficient usage of network bandwidth". I think that the SHOULD NOT
need to be MUST NOT. Is there a reason for the sender to ignore the receiver
request?

6. In section 4.1 is there a specific reason for stating "The receiving side
MUST be prepared to receive duplicates of RTP packets.  Only one of those
payloads MUST be provided to the Opus decoder for decoding and others MUST
be discarded" since this is a standard RTP behavior. The duplicate packets
can be reported in RTCP.

7. In section 4.2 "The maximum packet length is limited to the amount of
encoded data representing 120 ms of speech or audio data". I think that is
should also be limted by the MTU size if you do not want to fragment the RTP
packets.

8.In section 6 the whole section talks about what an encoder can do and not
about how to find and report congestion I think that maybe instead of "It is
RECOMMENDED that congestion control is applied during the transmission of
Opus encoded data ." say " that "receivers MUST monitor the packet loss rate
to ensure congestion is not caused, following the guidelines in Section 2 of
RFC 3551." . 

9. In section 7.1 you mention a required parameter "Rate". Is this a
parameter that need to be specified in the SDP. You only need to say in the
mapping to SDP that The RTP clock rate in "a=rtpmap" MUST be  48000. You
example 1 does not have the rate parameter just a=rtpmap:101 opus/48000

10. In section 7.1 maxcodedaudiobandwidth. Is this relay an issue to signal
the sampling rate. Isn't it enough to have the maximum bandwidth which will
affect the sampling rate according to table 1.

11. In section 7.1 I noticed that ptime, maxptime and minptime signaled by
the receiver are just recommendations and not the desired value as in RFC
3264, and the sender can send any size it wishes upto 120. So what is the
benfit for the receiver to signal it. I thought that this is a receive
capability.

12. In section 71. Why define maxaveragebitrate and not use the SDP b=
parameter.

13. In section 7.1 Why need the stereo parameter there is the number of
channels in the rtpmap. It should say a=rtpmap:101 opus/48000/2 instead of
a=rtpmap:101 opus/48000 and stereo=1.

14.In 7.1 the CBR parameter let the decoder specify if to use CBR or VBR.
Yet the CBR does not specify a value making it look a bit like VBR. I think
that there should be an option for the receiver to ask for a specific CBR
rate.

15.About fec and useinbandfec. I did not see if there an overhead for using
fec that should be reflected in the bandwidth considerations.

Some nits

1. In the introduction " The codec has a very low algorithmic delay and is
is"
2. In 4.1 " according to Table 2 to determine the RTP timestamp" maybe "
according to Table 2 to determine the increment in RTP timestamp"

Roni Even as individual

I would like to have two comment as Payload WG co-chair

1. Person & email address to contact for further information:

      SILK  Support [email-masked]
I think IANA will prefer a person and not a general email address

2. The change controller Should be "IETF Payload working group delegated
from the IESG.". I think this was a conclusion on previous discussion

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Julian Spittka
> Sent: Tuesday, July 05, 2011 3:11 AM
> To: [email-masked]
> Cc: 'Koen Vos'; 'Jean-Marc Valin'
> Subject: [payload] RTP Payload Format and File Storage Format for Opus
> Speech and Audio Codec - draft-spittka-payload-rtp-opus-00
> 
> 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/.
> 
> Any feedback, questions, or comments are highly welcome.
> 
> Best Regards,
> 
> Julian.
> 
> ---
> Julian Spittka
> Skype
> 
> see & chat: julian_spittka
> write: [email-masked]
> 
> 
> _______________________________________________
> payload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/payload

---

From: "Benjamin M. Schwartz" <[email-masked]>
Date: Mon, 11 Jul 2011 10:53:44 -0400

> need to be MUST NOT. Is there a reason for the sender to ignore the receiver

If a stream is being sent to many recipients, most of whom prefer stereo,
then it may be appropriate to send a single stereo stream to all
recipients, rather than increase the encoder CPU requirements by encoding
multiple versions of the stream.

> that there should be an option for the receiver to ask for a specific CBR

I think the implication was that in CBR mode, "maxaveragebitrate" also
sets a hard ceiling on the size of an individual packet.  I agree that
this is not a perfect solution.  Personally, I would prefer that the
receiver indicate both a hard limit and a soft target (or similar).

--Ben

---

From: Randell Jesup <[email-masked]>
Date: Mon, 11 Jul 2011 16:23:41 -0400

> benfit for the receiver to signal it. I thought that this is a receive

ptime is I think desired but not required.  maxptime and minptime should 
be hard receiver limits.
Per Colin on AVT on 30 Mar 2006, ptime is a "hint", but the encoder can 
vary up to maxptime (and I
assume down to minptime).  (I didn't bother researching further).

-- 
Randell Jesup
[email-masked]

---

From: Stephen Botzko <[email-masked]>
Date: Mon, 11 Jul 2011 16:57:03 -0400

ptime is described in both RFC3264 and RFC4566, which is a bit confusing.
But the normative text for ptime is in RFC3264, I think that should be
referenced in 7.1. (maxptime and minptime only appear in RFC4566).

ptime, maxptime, and minptime are media attributes, so they apply to all
codecs on the m= line.  This is not that clear in this text, as it seems to
mandate specific values for this OPUS.  For instance:

>>> maxptime

Possible values are 3, 5,
      10, 20, 40, and 60 or an arbitrary multiple of Opus frame sizes
      rounded up to the next full integer value up to a maximum value of
      120 as defined in Section 4 and Section 5 of this document.  If no
      value is specified, 120 is assumed as default.

The signaled maxptime certainly might exceed 120 ms, since the offerer might
be quite willing to receive some other codec on the m-line at that interval.

Regards,
Stephen Botzko

On Mon, Jul 11, 2011 at 4:23 PM, Randell Jesup <[email-masked]>wrote:

> ptime is I think desired but not required.  maxptime and minptime should be
> hard receiver limits.
> ______________________________**_________________
> payload mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/payload<https://www.ietf.org/mailman/listinfo/payload>
>

---

From: Randell Jesup <[email-masked]>
Date: Mon, 11 Jul 2011 17:57:33 -0400

On 7/11/2011 4:57 PM, Stephen Botzko wrote:
> ptime is described in both RFC3264 and RFC4566, which is a bit 
> confusing.  But the normative text for ptime is in RFC3264, I think 
> that should be referenced in 7.1. (maxptime and minptime only appear 
> in RFC4566).
>
> ptime, maxptime, and minptime are media attributes, so they apply to 
> all codecs on the m= line.  This is not that clear in this text, as it 
> seems to mandate specific values for this OPUS.  For instance:
>
> >>> maxptime
> The signaled maxptime certainly might exceed 120 ms, since the offerer 
> might be quite willing to receive some other codec on the m-line at 
> that interval.

Right.  You could define a fmtp parameter of maxptime (or equivalent) 
that give the maximum for that
codec/payload.  iLBC uses fmtp to negotiate between 20 and 30ms frame 
sizes, though that's not
exactly the same as the ptime issues here.

ptime and maxptime are a bit problematic due to the global nature (and 
that's part of why ptime is a hint).
Also, they can be any arbitrary value (due to the shared nature), not 
just multiples of your codec's frame size.

-- 
Randell Jesup
[email-masked]

---

From: Koen Vos <[email-masked]>
Date: Tue, 12 Jul 2011 00:00:37 +0200 (CEST)

> ptime is I think desired but not required.  maxptime and minptime should 

The goal has always been that every Opus decoder is able to decode any valid Opus bitstream.  Advantages are:
- In a multi-party call you can send the same bitstream to all end points.  If maxptime and minptime were hard limits, then two end points may not have any overlap in their ranges of allowed ptime, making it impossible to share bitstreams.
- Less reliance on parameter negotiation.  Keep in mind that bitstreams may be saved to file and played out later.

Note that the cost in storage requirements of maxptime being a soft limit is modest: payloads are stored in compressed format, and payloads with ptime > 20 ms can always be decoded in chunks of 20 ms (or less).

If Opus' use of minptime and maxptime differs from what is generally accepted, then perhaps we should use different names for these parameters?

Roni Even wrote:
> So what is the benfit for the receiver to signal it.

See section 7.2.1: performance (e.g. quality) may be better for some ptime values than for others.

best,
koen.

----- Original Message -----
From: "Randell Jesup" <[email-masked]>
To: [email-masked]
Sent: Monday, July 11, 2011 1:23:41 PM
Subject: Re: [payload] RTP Payload Format and File Storage Format for	Opus Speech and Audio Codec - draft-spittka-payload-rtp-opus-00

-- 
Randell Jesup
[email-masked]