Subject: Re: [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: Tue, 5 Jul 2011 23:59:00 +0300

Hi,
I noticed the discussion that started on the codec mailing list. 
Since this work will be handled in the payload WG please send the comments
to [email-masked] 
Thanks
Roni Even
Payload co-chair

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Julian Spittka
> Sent: Tuesday, July 05, 2011 3:06 AM
> To: [email-masked]
> Subject: [codec] 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]
> 
> 
> _______________________________________________
> codec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/codec

---

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

On 07/11/2011 10:24 AM, Roni Even wrote:
> 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?

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.

> 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.

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