Subject: Re: [payload] draft-ietf-payload-rtp-opus-05: maxaveragebitrate

From: "Parthasarathi R" <[email-masked]>
Date: Sat, 3 Jan 2015 15:57:33 +0530

Hi all,

I  understand that bandwidth "b" parameter has lot of variants like AS, TIAS
and usage but all those parameters are media level and not codec specific.
The bandwidth allocation is going to be happen in the media level in the
network or end point based on the media level and not on the codec specific
in case the multiple codec is negotiated. In most of the implementation, the
multiple codec (Say Ex: G.711 & Opus) is going to be negotiated rather than
single codec. The codec specific bandwidth implementation complicates these
bandwidth calculation still further which is applicable to maxaveragebitrate
parameter in opus.

I could not understand why the generic parameter should not used or generic
parameter has to be enhanced which meets Opus requirement rather than opus
specific parameter. 

Thanks

Partha

From: payload [mailto:[email-masked]] On Behalf Of Ali C. Begen
(abegen)
Sent: Wednesday, December 31, 2014 4:57 PM
To: Fredrik Bergholtz
Cc: [email-masked]
Subject: Re: [payload] draft-ietf-payload-rtp-opus-05: maxaveragebitrate

Authors 

Please chime in and lets discuss s quick solution for this on the list. Once
agreed we can ship this draft. 

-acbegen

From: Fredrik Bergholtz <[email-masked]>
Sent: Dec 31, 2014 11:42 AM
To: Ali C. Begen (abegen)
Cc: Jean-Marc Valin <[email-masked]>;Fredrik Bergholtz;[email-masked]
Subject: Re: [payload] draft-ietf-payload-rtp-opus-05: maxaveragebitrate

Yes, I do see a strong need for specifying the bitrate. 

In the broadcasting use case we have to make sure that we get the best audio
quality that is possible for the network that is currently used but never
try to send more data than the particular link is capable of. For this
reason, specifying a maximum bit rate is required.

In addition we often have the requirement that the quality is constant
rather than the best possible. To avoid as many audible changes in the audio
as possible over time we will often use constant bit rate and then it
becomes even more important to be able to specify what bit rate should be. 

We will use the Opus codec over various network links with different
capabilities in terms of bit rate, delay variation, absolute delay, etc and
we will typically use the SDP to signal the parameters that best fit both
the current network and the current type of radio production. 

Best regards
Fredrik Bergholtz
Swedish Radio

> On 31 dec 2014, at 05:57, "Ali C. Begen (abegen)" <[email-masked]>
wrote:
> 
> My understanding is that the b= line in the SDP is quite a subjective
parameter. I have seen people use it differently over the past several
years. So, it is a bit difficult to infer much accuracy from that line.
> 
> OTOH, if someone feels like Opus needs to specify some sort of bitrate
variability in the SDP, it can do so in an optional (opus) parameter.
Obviously rules around how to set that value and what to do with that value
need to be clearly specified.
> 
> Fredrik (or anyone else in the WG), do you see a strong need for this? If
so, now is the time to mention that.
> 
> -acbegen
> 
> 
>> On Dec 12, 2014, at 3:07 AM, Jean-Marc Valin <[email-masked]> wrote:
>> 
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> 
>> I have to say this is not something I understand really well. Does
>> anyone else here have an opinion on how to specify bit-rate?
>> 
>>    Jean-Marc
>> 
>>> On 10/12/14 05:11 AM, Fredrik Bergholtz wrote:
>>> Hi.
>>> 
>>> 
>>> 
>>> I read in the latest draft that you have removed the maxaveragebitrate
>>> parameter from the SDP signalling for Opus. I think that this parameter
>>> is useful and that it provides added value over the bandwidth modifiers
>>> added by RFC 3556.
>>> 
>>> 
>>> 
>>> I must admit that I haven't read all of RFC 3556 but as I understand it,
>>> a b= line are not in any way related to an actual format of a media
>>> description. This means that with this mechanism, only one bitrate
>>> specification can be sent with each media description. Different coding
>>> algorithms have different constraints on the allowed bitrate. For
>>> example, I might want to send an SDP offer with both Enhanced apt-X at
>>> 576 kbit/s and Opus at 510kbit/s with cbr. Now, specifying 576kbit/s via
>>> a b= line works for apt-X but makes no sense for Opus and vice versa. I
>>> think that the a=fmtp line is the correct place to specify the desired
>>> bitrate.
>>> 
>>> 
>>> 
>>> For the broadcasting use-case, it is often more important to have a
>>> constant and predictable audio quality and network usage than mere
>>> audibility at any cost.
>>> 
>>> 
>>> 
>>> Best regards,
>>> 
>>> Fredrik Bergholtz
>>> 
>>> Swedish Radio
>>> 
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> payload mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/payload
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1
>> 
>> iQEcBAEBAgAGBQJUij/kAAoJEJ6/8sItn9q9V6EIALgEC6Iv+nZuu2BU8useaV4Z
>> jLRz97vCEdcmj60jMzELC2gSKLpVW3AMcbP7gtPjm0odeLFEMvoweUFytnVt/cd6
>> bCadjHMPAOSNXrPtbmS57JdlcmWHnsrJIVrsV/Ipn6o44FWL2BN5g/LnwlSTKs/N
>> OtrjAdLj8b/GsmVS6VTTjTkygL1bp1Wsry5oAGXIPwPqFgQwuGMAxv/Wf6eEu7c3
>> eoZzBKfBDM0bC8L+RCy6REYKHvSjPbyPAH0bQvkkKHfSc6I5ZLOZspvOHBmHvQFu
>> DNj4DHCShHPnRRknVnXCXX9ddSC4/bLQSyZ9+WI9622N5lkre8+VnUIGx9iAr3I=
>> =ZuN4
>> -----END PGP SIGNATURE-----
>> 
>> _______________________________________________
>> payload mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/payload
>

---

From: Fredrik Bergholtz <[email-masked]>
Date: Sat, 3 Jan 2015 14:32:38 +0000

Hi.

One thought om the general media level bit rate specification is that it can never be anything other than an approximate value. Different codecs define different constraints on the bit rate. I think that the easiest way to specify exact bit rates would be via the fmtp attribute.

This can be compared with the ptime
attribute - as it is defined today, only approximate packet times can be signalled in SDP. For the broadcast use case this is not acceptable and for that reason, the European Broadcasting Union (EBU) has defined an SDP extension that allows signalling of a ptime value for each codec. There is no RFC draft for this extension and it is not yet registered with IANA or IETF but it is starting to be used by manufacturers of broadcasting equipment. The extension is known as "ACIP Profiles" and can be found at the EBU web site. But I digress.

I don't think that forcing encoders to approximate the nearest allowed value for the selected codec is less complicated than interpreting an exact value. In addition, it would add a non-deterministic aspect, thus the resulting bit rate may not be what the user expected.

Best regards
Fredrik Bergholtz
Swedish Radio

On 3 jan 2015, at 11:27, "Parthasarathi R" <[email-masked]<mailto:[email-masked]>> wrote:

Hi all,

I  understand that bandwidth “b” parameter has lot of variants like AS, TIAS and usage but all those parameters are media level and not codec specific. The bandwidth allocation is going to be happen in the media level in the network or end point based on the media level and not on the codec specific  in case the multiple codec is negotiated. In most of the implementation, the multiple codec (Say Ex: G.711 & Opus) is going to be negotiated rather than single codec. The codec specific bandwidth implementation complicates these bandwidth calculation still further which is applicable to maxaveragebitrate parameter in opus.

I could not understand why the generic parameter should not used or generic parameter has to be enhanced which meets Opus requirement rather than opus specific parameter.

Thanks
Partha

From: payload [mailto:[email-masked]] On Behalf Of Ali C. Begen (abegen)
Sent: Wednesday, December 31, 2014 4:57 PM
To: Fredrik Bergholtz
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [payload] draft-ietf-payload-rtp-opus-05: maxaveragebitrate

Authors

Please chime in and lets discuss s quick solution for this on the list. Once agreed we can ship this draft.
-acbegen

From: Fredrik Bergholtz <[email-masked]<mailto:[email-masked]>>
Sent: Dec 31, 2014 11:42 AM
To: Ali C. Begen (abegen)
Cc: Jean-Marc Valin <[email-masked]<mailto:[email-masked]>>;Fredrik Bergholtz;[email-masked]<mailto:[email-masked]>
Subject: Re: [payload] draft-ietf-payload-rtp-opus-05: maxaveragebitrate

In the broadcasting use case we have to make sure that we get the best audio quality that is possible for the network that is currently used but never try to send more data than the particular link is capable of. For this reason, specifying a maximum bit rate is required.

In addition we often have the requirement that the quality is constant rather than the best possible. To avoid as many audible changes in the audio as possible over time we will often use constant bit rate and then it becomes even more important to be able to specify what bit rate should be.

We will use the Opus codec over various network links with different capabilities in terms of bit rate, delay variation, absolute delay, etc and we will typically use the SDP to signal the parameters that best fit both the current network and the current type of radio production.

Best regards
Fredrik Bergholtz
Swedish Radio

> On 31 dec 2014, at 05:57, "Ali C. Begen (abegen)" <[email-masked]<mailto:[email-masked]>> wrote:
>
> My understanding is that the b= line in the SDP is quite a subjective parameter. I have seen people use it differently over the past several years. So, it is a bit difficult to infer much accuracy from that line.
>
> OTOH, if someone feels like Opus needs to specify some sort of bitrate variability in the SDP, it can do so in an optional (opus) parameter. Obviously rules around how to set that value and what to do with that value need to be clearly specified.
>
> Fredrik (or anyone else in the WG), do you see a strong need for this? If so, now is the time to mention that.
>
> -acbegen
>
>
>> On Dec 12, 2014, at 3:07 AM, Jean-Marc Valin <[email-masked]<mailto:[email-masked]>> wrote:
>>
>>> I must admit that I haven’t read all of RFC 3556 but as I understand it,
>>> [email-masked]<mailto:[email-masked]>
>> [email-masked]<mailto:[email-masked]>

---

From: Jean-Marc Valin <[email-masked]>
Date: Sun, 04 Jan 2015 14:45:28 -0500

Setting the bitrate isn't exactly a new problem here. Opus isn't the
first codec to support more than one rate so how are the other codecs
(audio and video) handling bitrate signaling?

Cheers,

	Jean-Marc

On 03/01/15 09:32 AM, Fredrik Bergholtz wrote:
> Hi.
> 
> One thought om the general media level bit rate specification is
> that it can never be anything other than an approximate value.
> Different codecs define different constraints on the bit rate. I
> think that the easiest way to specify exact bit rates would be via
> the fmtp attribute.
> 
> This can be compared with the ptime attribute - as it is defined
> today, only approximate packet times can be signalled in SDP. For
> the broadcast use case this is not acceptable and for that reason,
> the European Broadcasting Union (EBU) has defined an SDP extension
> that allows signalling of a ptime value for each codec. There is no
> RFC draft for this extension and it is not yet registered with IANA
> or IETF but it is starting to be used by manufacturers of 
> broadcasting equipment. The extension is known as "ACIP Profiles"
> and can be found at the EBU web site. But I digress.
> 
> I don't think that forcing encoders to approximate the nearest
> allowed value for the selected codec is less complicated than
> interpreting an exact value. In addition, it would add a
> non-deterministic aspect, thus the resulting bit rate may not be
> what the user expected.
> 
> Best regards Fredrik Bergholtz Swedish Radio
> 
> On 3 jan 2015, at 11:27, "Parthasarathi R"
> <[email-masked] <mailto:[email-masked]>>
> wrote:
> 
>> Hi all,
>> 
>> 
>> 
>> I  understand that bandwidth “b” parameter has lot of variants
>> like AS, TIAS and usage but all those parameters are media level
>> and not codec specific. The bandwidth allocation is going to be
>> happen in the media level in the network or end point based on
>> the media level and not on the codec specific  in case the
>> multiple codec is negotiated. In most of the implementation, the
>> multiple codec (Say Ex: G.711 & Opus) is going to be negotiated
>> rather than single codec. The codec specific bandwidth
>> implementation complicates these bandwidth calculation still
>> further which is applicable to maxaveragebitrate parameter in
>> opus.
>> 
>> 
>> 
>> I could not understand why the generic parameter should not used
>> or generic parameter has to be enhanced which meets Opus
>> requirement rather than opus specific parameter.
>> 
>> 
>> 
>> Thanks
>> 
>> Partha
>> 
>> 
>> 
>> *From:*payload [mailto:[email-masked]] *On Behalf Of
>> *Ali C. Begen (abegen) *Sent:* Wednesday, December 31, 2014 4:57
>> PM *To:* Fredrik Bergholtz *Cc:* [email-masked]
>> <mailto:[email-masked]> *Subject:* Re: [payload]
>> draft-ietf-payload-rtp-opus-05: maxaveragebitrate
>> 
>> 
>> 
>> Authors
>> 
>> Please chime in and lets discuss s quick solution for this on
>> the list. Once agreed we can ship this draft.
>> 
>> -acbegen
>> 
>> 
>> 
>> *From:*Fredrik Bergholtz <[email-masked] 
>> <mailto:[email-masked]>> *Sent:* Dec 31, 2014
>> 11:42 AM *To:* Ali C. Begen (abegen) *Cc:* Jean-Marc Valin
>> <[email-masked] <mailto:[email-masked]>>;Fredrik
>> Bergholtz;[email-masked] <mailto:[email-masked]> *Subject:*
>> Re: [payload] draft-ietf-payload-rtp-opus-05: maxaveragebitrate
>> 
>> 
>> 
>> In the broadcasting use case we have to make sure that we get the
>> best audio quality that is possible for the network that is
>> currently used but never try to send more data than the
>> particular link is capable of. For this reason, specifying a
>> maximum bit rate is required.
>> 
>> In addition we often have the requirement that the quality is
>> constant rather than the best possible. To avoid as many audible
>> changes in the audio as possible over time we will often use
>> constant bit rate and then it becomes even more important to be
>> able to specify what bit rate should be.
>> 
>> We will use the Opus codec over various network links with
>> different capabilities in terms of bit rate, delay variation,
>> absolute delay, etc and we will typically use the SDP to signal
>> the parameters that best fit both the current network and the
>> current type of radio production.
>> 
>> Best regards Fredrik Bergholtz Swedish Radio
>> 
>> 
>>> On 31 dec 2014, at 05:57, "Ali C. Begen (abegen)"
>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> My understanding is that the b= line in the SDP is quite a
>>> subjective parameter. I have seen people use it differently
>>> over the past several years. So, it is a bit difficult to infer
>>> much accuracy from that line.
>>> 
>>> OTOH, if someone feels like Opus needs to specify some sort of
>>> bitrate variability in the SDP, it can do so in an optional
>>> (opus) parameter. Obviously rules around how to set that value
>>> and what to do with that value need to be clearly specified.
>>> 
>>> Fredrik (or anyone else in the WG), do you see a strong need
>>> for this? If so, now is the time to mention that.
>>> 
>>> -acbegen
>>> 
>>> 
>>>> On Dec 12, 2014, at 3:07 AM, Jean-Marc Valin
>>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>> 
>>>>>> On 10/12/14 05:11 AM, Fredrik Bergholtz wrote: Hi.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> I read in the latest draft that you have removed the
>>>>>> maxaveragebitrate parameter from the SDP signalling for
>>>>>> Opus. I think that this parameter is useful and that it
>>>>>> provides added value over the bandwidth modifiers added
>>>>>> by RFC 3556.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> I must admit that I haven’t read all of RFC 3556 but as I
>>>>>> understand it, a b= line are not in any way related to an
>>>>>> actual format of a media description. This means that
>>>>>> with this mechanism, only one bitrate specification can
>>>>>> be sent with each media description. Different coding 
>>>>>> algorithms have different constraints on the allowed
>>>>>> bitrate. For example, I might want to send an SDP offer
>>>>>> with both Enhanced apt-X at 576 kbit/s and Opus at
>>>>>> 510kbit/s with cbr. Now, specifying 576kbit/s via a b=
>>>>>> line works for apt-X but makes no sense for Opus and vice
>>>>>> versa. I think that the a=fmtp line is the correct place
>>>>>> to specify the desired bitrate.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> For the broadcasting use-case, it is often more important
>>>>>> to have a constant and predictable audio quality and
>>>>>> network usage than mere audibility at any cost.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Best regards,
>>>>>> 
>>>>>> Fredrik Bergholtz
>>>>>> 
>>>>>> Swedish Radio
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________ payload
>>>>>> mailing list [email-masked] <mailto:[email-masked]> 
>>>> _______________________________________________ payload
>>>> mailing list [email-masked] <mailto:[email-masked]> 
> _______________________________________________ payload mailing
> list [email-masked]

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Sun, 4 Jan 2015 22:05:30 +0000

Some other codecs have fmtp parameters for maximum bitrate explicitly
(e.g. max-br in H264 / H264-SVC / H265) and/or implicitly (e.g.
profile-level-id in H264 / H264-SVC / H265 / AAC; config in AAC).

Other notable codecs that lack this include VP8 and VP9.

This is a general problem which may become more important with complex
applications that include simulcast and scalable media within the same
media description (m= line). The SDP b= parameter is clearly insufficient
for expressing multiple different maximum bitrates for each payload type,
unless we define a new bandwidth modifier which includes explicit PT
bindings. Payload formats that include fmtp parameters for maximum bitrate
can avoid this problem, so I think it is advisable to add this to Opus,
VP8 and VP9.

Mo

On 1/4/15, 2:45 PM, Jean-Marc Valin <[email-masked]> wrote:

Cheers,

	Jean-Marc

On 03/01/15 09:32 AM, Fredrik Bergholtz wrote:
>> I  understand that bandwidth ³b² parameter has lot of variants
>>>>>> I must admit that I haven¹t read all of RFC 3556 but as I

---

From: Jean-Marc Valin <[email-masked]>
Date: Sun, 04 Jan 2015 18:16:32 -0500

So would everyone be happy if I just revert to using maxaveragebitrate
as in draft 04?

	Jean-Marc

On 04/01/15 05:05 PM, Mo Zanaty (mzanaty) wrote:
> Some other codecs have fmtp parameters for maximum bitrate
> explicitly (e.g. max-br in H264 / H264-SVC / H265) and/or
> implicitly (e.g. profile-level-id in H264 / H264-SVC / H265 / AAC;
> config in AAC).
> 
> This is a general problem which may become more important with
> complex applications that include simulcast and scalable media
> within the same media description (m= line). The SDP b= parameter
> is clearly insufficient for expressing multiple different maximum
> bitrates for each payload type, unless we define a new bandwidth
> modifier which includes explicit PT bindings. Payload formats that
> include fmtp parameters for maximum bitrate can avoid this problem,
> so I think it is advisable to add this to Opus, VP8 and VP9.
> 
> Mo
> 
> Setting the bitrate isn't exactly a new problem here. Opus isn't
> the first codec to support more than one rate so how are the other
> codecs (audio and video) handling bitrate signaling?
> 
> Cheers,
> 
> Jean-Marc
> 
>> think that the easiest way to specify exact bit rates would be
>> via the fmtp attribute.
> 
>> today, only approximate packet times can be signalled in SDP.
>> For the broadcast use case this is not acceptable and for that
>> reason, the European Broadcasting Union (EBU) has defined an SDP
>> extension that allows signalling of a ptime value for each codec.
>> There is no RFC draft for this extension and it is not yet
>> registered with IANA or IETF but it is starting to be used by
>> manufacturers of broadcasting equipment. The extension is known
>> as "ACIP Profiles" and can be found at the EBU web site. But I
>> digress.
> 
>>> like AS, TIAS and usage but all those parameters are media
>>> level and not codec specific. The bandwidth allocation is going
>>> to be happen in the media level in the network or end point
>>> based on the media level and not on the codec specific  in case
>>> the multiple codec is negotiated. In most of the
>>> implementation, the multiple codec (Say Ex: G.711 & Opus) is
>>> going to be negotiated rather than single codec. The codec
>>> specific bandwidth implementation complicates these bandwidth
>>> calculation still further which is applicable to
>>> maxaveragebitrate parameter in opus.
>>> 
>>> 
>>> 
>>> I could not understand why the generic parameter should not
>>> used or generic parameter has to be enhanced which meets Opus 
>>> *Ali C. Begen (abegen) *Sent:* Wednesday, December 31, 2014
>>> 4:57 PM *To:* Fredrik Bergholtz *Cc:* [email-masked] 
>>> <mailto:[email-masked]>> *Sent:* Dec 31,
>>> 2014 11:42 AM *To:* Ali C. Begen (abegen) *Cc:* Jean-Marc
>>> Valin <[email-masked]
>>> <mailto:[email-masked]>>;Fredrik 
>>> Bergholtz;[email-masked] <mailto:[email-masked]>
>>> *Subject:* Re: [payload] draft-ietf-payload-rtp-opus-05:
>>> maxaveragebitrate
>>> 
>>> 
>>> 
>>> In the broadcasting use case we have to make sure that we get
>>> the best audio quality that is possible for the network that
>>> is currently used but never try to send more data than the 
>>> constant rather than the best possible. To avoid as many
>>> audible changes in the audio as possible over time we will
>>> often use constant bit rate and then it becomes even more
>>> important to be able to specify what bit rate should be.
>>> 
>>> absolute delay, etc and we will typically use the SDP to
>>> signal the parameters that best fit both the current network
>>> and the current type of radio production.
>>> 
>>>> over the past several years. So, it is a bit difficult to
>>>> infer much accuracy from that line.
>>>> 
>>>> OTOH, if someone feels like Opus needs to specify some sort
>>>> of bitrate variability in the SDP, it can do so in an
>>>> optional (opus) parameter. Obviously rules around how to set
>>>> that value and what to do with that value need to be clearly
>>>> specified.
>>>> 
>> I have to say this is not something I understand really well.
>> Does anyone else here have an opinion on how to specify
>> bit-rate?
> 
>> Jean-Marc
> 
>>>>>>> maxaveragebitrate parameter from the SDP signalling
>>>>>>> for Opus. I think that this parameter is useful and
>>>>>>> that it provides added value over the bandwidth
>>>>>>> modifiers added by RFC 3556.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> I must admit that I haven¹t read all of RFC 3556 but as
>>>>>>> I understand it, a b= line are not in any way related
>>>>>>> to an actual format of a media description. This means
>>>>>>> that with this mechanism, only one bitrate
>>>>>>> specification can be sent with each media description.
>>>>>>> Different coding algorithms have different constraints
>>>>>>> on the allowed bitrate. For example, I might want to
>>>>>>> send an SDP offer with both Enhanced apt-X at 576
>>>>>>> kbit/s and Opus at 510kbit/s with cbr. Now, specifying
>>>>>>> 576kbit/s via a b= line works for apt-X but makes no
>>>>>>> sense for Opus and vice versa. I think that the a=fmtp
>>>>>>> line is the correct place to specify the desired
>>>>>>> bitrate.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> For the broadcasting use-case, it is often more
>>>>>>> important to have a constant and predictable audio
>>>>>>> quality and network usage than mere audibility at any
>>>>>>> cost.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Best regards,
>>>>>>> 
>>>>>>> Fredrik Bergholtz
>>>>>>> 
>>>>>>> Swedish Radio
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> payload mailing list [email-masked]
>>>>>>> <mailto:[email-masked]>

---

From: "Roni Even" <[email-masked]>
Date: Mon, 5 Jan 2015 01:35:04 +0200

Hi,
For audio/voice there are RFC5577 and RFC4749 that has a bitrate parameter
while RFC5404 uses the b= parameter

Roni Even
As individual

> -----Original Message-----
> From: payload [mailto:[email-masked]] On Behalf Of Mo Zanaty
> (mzanaty)
> Sent: 05 January, 2015 12:06 AM
> To: Jean-Marc Valin; Fredrik Bergholtz; Parthasarathi R
> Cc: [email-masked]
(e.g.
> max-br in H264 / H264-SVC / H265) and/or implicitly (e.g.
media
> description (m= line). The SDP b= parameter is clearly insufficient for
> expressing multiple different maximum bitrates for each payload type,
unless
> we define a new bandwidth modifier which includes explicit PT bindings.
> Payload formats that include fmtp parameters for maximum bitrate can avoid
> this problem, so I think it is advisable to add this to Opus,
> VP8 and VP9.
> 
> Mo
> 
> Setting the bitrate isn't exactly a new problem here. Opus isn't the first
codec
> to support more than one rate so how are the other codecs (audio and
video)
> handling bitrate signaling?
> 
> Cheers,
> 
> 	Jean-Marc
> 
> > One thought om the general media level bit rate specification is that
> > it can never be anything other than an approximate value.
> > Different codecs define different constraints on the bit rate. I think
> > that the easiest way to specify exact bit rates would be via the fmtp
> > attribute.
> >
> > today, only approximate packet times can be signalled in SDP. For the
> > broadcast use case this is not acceptable and for that reason, the
> > European Broadcasting Union (EBU) has defined an SDP extension that
> > allows signalling of a ptime value for each codec. There is no RFC
> > draft for this extension and it is not yet registered with IANA or
> > IETF but it is starting to be used by manufacturers of broadcasting
> > equipment. The extension is known as "ACIP Profiles"
> > I don't think that forcing encoders to approximate the nearest allowed
> > value for the selected codec is less complicated than interpreting an
> > exact value. In addition, it would add a non-deterministic aspect,
> > thus the resulting bit rate may not be what the user expected.
> >
> >> I  understand that bandwidth ³b² parameter has lot of variants like
> >> AS, TIAS and usage but all those parameters are media level and not
> >> codec specific. The bandwidth allocation is going to be happen in the
> >> media level in the network or end point based on the media level and
> >> not on the codec specific  in case the multiple codec is negotiated.
> >> In most of the implementation, the multiple codec (Say Ex: G.711 &
> >> Opus) is going to be negotiated rather than single codec. The codec
> >> calculation still further which is applicable to maxaveragebitrate
> >> parameter in opus.
> >>
> >>
> >>
> >> I could not understand why the generic parameter should not used or
> >> generic parameter has to be enhanced which meets Opus requirement
> >> rather than opus specific parameter.
> >>
> >>
> >>
> >> Thanks
> >>
> >> Partha
> >>
> >>
> >>
> >> *From:*payload [mailto:[email-masked]] *On Behalf Of *Ali
> >> C. Begen (abegen) *Sent:* Wednesday, December 31, 2014 4:57 PM *To:*
> >> Fredrik Bergholtz *Cc:* [email-masked] <mailto:[email-masked]>
> >> *Subject:* Re: [payload]
> >> Please chime in and lets discuss s quick solution for this on the
> >> list. Once agreed we can ship this draft.
> >>
> >> -acbegen
> >>
> >>
> >>
> >> best audio quality that is possible for the network that is currently
> >> used but never try to send more data than the particular link is
> >> capable of. For this reason, specifying a maximum bit rate is
> >> required.
> >>
> >> changes in the audio as possible over time we will often use constant
> >> bit rate and then it becomes even more important to be able to
> >> specify what bit rate should be.
> >>
> >> capabilities in terms of bit rate, delay variation, absolute delay,
> >> etc and we will typically use the SDP to signal the parameters that
> >> best fit both the current network and the current type of radio
> >> production.
> >>
> >>> subjective parameter. I have seen people use it differently over the
> >>> past several years. So, it is a bit difficult to infer much accuracy
> >>> from that line.
> >>>
> >>> (opus) parameter. Obviously rules around how to set that value and
> >>> what to do with that value need to be clearly specified.
> >>>
> >>> Fredrik (or anyone else in the WG), do you see a strong need for
> >>> this? If so, now is the time to mention that.
> >>>
> >>> -acbegen
> >>>
> >>>
> >>>>>> maxaveragebitrate parameter from the SDP signalling for Opus. I
> >>>>>> think that this parameter is useful and that it provides added
> >>>>>> value over the bandwidth modifiers added by RFC 3556.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> understand it, a b= line are not in any way related to an actual
> >>>>>> format of a media description. This means that with this
> >>>>>> mechanism, only one bitrate specification can be sent with each
> >>>>>> media description. Different coding algorithms have different
> >>>>>> constraints on the allowed bitrate. For example, I might want to
> >>>>>> send an SDP offer with both Enhanced apt-X at 576 kbit/s and Opus
> >>>>>> at 510kbit/s with cbr. Now, specifying 576kbit/s via a b= line
> >>>>>> works for apt-X but makes no sense for Opus and vice versa. I
> >>>>>> think that the a=fmtp line is the correct place to specify the
> >>>>>> desired bitrate.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> For the broadcasting use-case, it is often more important to have
> >>>>>> a constant and predictable audio quality and network usage than
> >>>>>> mere audibility at any cost.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Best regards,
> >>>>>>
> >>>>>> Fredrik Bergholtz
> >>>>>>
> >>>>>> Swedish Radio
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> mailing
> >>>>>> list [email-masked] <mailto:[email-masked]>
> mailing
> >>>> list [email-masked] <mailto:[email-masked]>
> > _______________________________________________ payload mailing list
> > [email-masked] https://www.ietf.org/mailman/listinfo/payload
> >
> iQEcBAEBAgAGBQJUqZhTAAoJEJ6/8sItn9q9NaAH/jTELxrPUMSmhWHIODeGOrJ
> X
> 67evbcn5cIsZY/8+yyofMNbaFq7DCqdR3BKX9uJ/dUJ+4yR/nbyxvw/msjd65dkv
> YS3HVibycnMOnZkFENr7by6vvMaZn7mIjbOWukxdBePDKHhQq7ZPec++j8gWVp
> bR
> 6qy7BSMJle9TTH3nt/kzV8YbnP7Pt0iVUorMYH/JFUzHfwcPRROKlqmdgf8yAcIZ
> 3Dv659NuWqoUtUx7gm+DtLIZciR2io0rKElhWf9Y7pvnPw9ZjP/ztlWMaj+zlVeU
> WE9fjpEtBxWCqH2KooYAhKeS2wTbvNBXvMzIRojYDcFp50gYHhgih+heQ9yVdYg=
> =ADn2

---

From: Fredrik Bergholtz <[email-masked]>
Date: Mon, 5 Jan 2015 10:32:42 +0000

I think that re-instating maxaveragebitrate would do it for me. 

/Fredrik

> On 5 jan 2015, at 00:16, "Jean-Marc Valin" <[email-masked]> wrote:
> 
> iQEcBAEBAgAGBQJUqcnLAAoJEJ6/8sItn9q9c5MIALwwSsXAUeJwGhbQiyV8plkT
> R0cNeuqV1+8rMBK/XYZORBPWqrAVvhNh6fs1eh0fn8e5aNioHGUyCY/d63u1g1qh
> PkL/vloGt6F30QBlsZShL9AkPtWLWPwuSE5H9kczcOR6uoRA1wj7adchjCaPRdl1
> 4Y1yx71qNbonxKowA1i1ekVCYQiaTOScyvWtuga23DHuMH8ib6n7aFB4vj2qHZyq
> TaJ23Turl8uEgSBoHW/6FnXfOcDRv1U028b10US0EaNRKyfad/U9OU7MPaMd5Lzk
> PBT4XMU5ZBprQ2UzEBtER5XpwLXWqvVETK2HyRlTEhg2fJUXKL6Y2v3QV4qjg+4=
> =rNBB

---

From: "Victor Demjanenko, Ph.D." <[email-masked]>
Date: Mon, 5 Jan 2015 09:00:08 -0500

Hi,

The set of permitted/preferred bit rate is also of interest for the MELP RTP
payload.  There are three permitted rates and some devices may only support
a specific subset.  (I know one device would only handle 2400 and 600
because the tables for 1200bps are huge.)

We currently suggested the following for MELP SDP:

    m=audio 49120 RTP/AVP 97 
    a=rtpmap:97 MELP/8000 
    a=fmtp:97 rate=2400,600,1200

Should we be considering a different way to express the permitted/preferred
rates?  We are not trying to invent something new and unique.  I believe I
had seen this with one other recent speech coder.  

As an FYI, we have had a few reviewers external to the IETF process provide
comments.  Unfortunately they have been out-of-band but they have been
useful and supportive.  We would like to have our proposal move forward
towards an RFC in the next few months if possible.

Regards,

Victor Demjanenko

-----Original Message-----
From: payload [mailto:[email-masked]] On Behalf Of Roni Even
Sent: Sunday, January 04, 2015 6:35 PM
To: 'Mo Zanaty (mzanaty)'; 'Jean-Marc Valin'; 'Fredrik Bergholtz';
'Parthasarathi R'
Cc: [email-masked]

Hi,

Roni Even
As individual

(e.g.
media
> description (m= line). The SDP b= parameter is clearly insufficient 
unless
> Payload formats that include fmtp parameters for maximum bitrate can 
> avoid this problem, so I think it is advisable to add this to Opus,
> VP8 and VP9.
> 
> Mo
> 
> first
codec
video)
> > non-deterministic aspect, thus the resulting bit rate may not be what
the user expected.
> >> codec specific. The bandwidth allocation is going to be happen in 
> >> the media level in the network or end point based on the media 
> >> level and not on the codec specific  in case the multiple codec is
negotiated.
> >> C. Begen (abegen) *Sent:* Wednesday, December 31, 2014 4:57 PM 
> >> *To:* Fredrik Bergholtz *Cc:* [email-masked] 
> >> currently used but never try to send more data than the particular 
> >> link is capable of. For this reason, specifying a maximum bit rate 
> >> is required.
> >>
> >> absolute delay, etc and we will typically use the SDP to signal the 
> >> parameters that best fit both the current network and the current 
> >> type of radio production.
> >>
> >>> subjective parameter. I have seen people use it differently over 
> >>> the past several years. So, it is a bit difficult to infer much 
> >>> accuracy from that line.
> >>>
> >>>>>> actual format of a media description. This means that with this 
> >>>>>> constraints on the allowed bitrate. For example, I might want 
> >>>>>> to send an SDP offer with both Enhanced apt-X at 576 kbit/s and 
> >>>>>> Opus at 510kbit/s with cbr. Now, specifying 576kbit/s via a b= 
> >>>>>> versa. I think that the a=fmtp line is the correct place to 
> >>>>>> specify the desired bitrate.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> For the broadcasting use-case, it is often more important to 
> >>>>>> have a constant and predictable audio quality and network usage 
> >>>>>> than mere audibility at any cost.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Best regards,
> >>>>>>
> >>>>>> Fredrik Bergholtz
> >>>>>>
> >>>>>> Swedish Radio
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>

---

From: Fredrik Bergholtz <[email-masked]>
Date: Mon, 5 Jan 2015 14:33:29 +0000

I may be off base here but if multiple bit-rates of the same codec are to be specified, couldn't one simply put them as multiple formats in the m-line, all mapped to the same codec in the rtpmap-lines but having different fmtp-lines?

Best regards
Fredrik Bergholtz
Swedish Radio

> On 5 jan 2015, at 15:00, "Victor Demjanenko, Ph.D." <[email-masked]> wrote:
> 
> Hi,
>

---

From: "Victor Demjanenko, Ph.D." <[email-masked]>
Date: Mon, 5 Jan 2015 09:54:46 -0500

I agree that this is viable (and may be preferred for some applications),
however, it does require distinct payload numbers for each rate.
Furthermore, it does not convey the preferred rate or permitted rates for
switching well.  A "rate" parameter with one, two or three rates shows both
the permitted rates and the preferred order.  Implied is also the permission
to switch rates on the fly without doing a REINVITE.

Victor

-----Original Message-----
From: Fredrik Bergholtz [mailto:[email-masked]] 
Sent: Monday, January 05, 2015 9:33 AM
To: Victor Demjanenko, Ph.D.
Cc: Roni Even; Mo Zanaty (mzanaty); Jean-Marc Valin; Fredrik Bergholtz;
Parthasarathi R; [email-masked]; Victor Demjanenko, Ph.D.
Subject: Re: [payload] draft-ietf-payload-rtp-opus-05: maxaveragebitrate

I may be off base here but if multiple bit-rates of the same codec are to be
specified, couldn't one simply put them as multiple formats in the m-line,
all mapped to the same codec in the rtpmap-lines but having different
fmtp-lines?

Best regards
Fredrik Bergholtz
Swedish Radio

> The set of permitted/preferred bit rate is also of interest for the 
> MELP RTP payload.  There are three permitted rates and some devices 
> may only support a specific subset.  (I know one device would only 
> handle 2400 and 600 because the tables for 1200bps are huge.)
> 
> Should we be considering a different way to express the 
> permitted/preferred rates?  We are not trying to invent something new 
> and unique.  I believe I had seen this with one other recent speech coder.
> 
> As an FYI, we have had a few reviewers external to the IETF process 
> provide comments.  Unfortunately they have been out-of-band but they 
> have been useful and supportive.  We would like to have our proposal 
> move forward towards an RFC in the next few months if possible.
> 
> Regards,
> 
> Victor Demjanenko
> 
> 
> For audio/voice there are RFC5577 and RFC4749 that has a bitrate 
> parameter while RFC5404 uses the b= parameter
> 
> 
> 
> Roni Even
> As individual
> 
>> complex applications that include simulcast and scalable media within 
>> the same
> media
>>> what

---

From: Jean-Marc Valin <[email-masked]>
Date: Mon, 05 Jan 2015 12:47:49 -0500

Listing multiple rates might make sense when the codec only supports a
handful of rates. In the case of Opus, it's a continuous scale so I
believe a max bitrate makes more sense.

	Jean-Marc

On 05/01/15 09:54 AM, Victor Demjanenko, Ph.D. wrote:
> I agree that this is viable (and may be preferred for some
> applications), however, it does require distinct payload numbers
> for each rate. Furthermore, it does not convey the preferred rate
> or permitted rates for switching well.  A "rate" parameter with
> one, two or three rates shows both the permitted rates and the
> preferred order.  Implied is also the permission to switch rates on
> the fly without doing a REINVITE.
> 
> Victor
> 
> -----Original Message----- From: Fredrik Bergholtz
> [mailto:[email-masked]] Sent: Monday, January
> 05, 2015 9:33 AM To: Victor Demjanenko, Ph.D. Cc: Roni Even; Mo
> Zanaty (mzanaty); Jean-Marc Valin; Fredrik Bergholtz; Parthasarathi
> R; [email-masked]; Victor Demjanenko, Ph.D. Subject: Re:
> [payload] draft-ietf-payload-rtp-opus-05: maxaveragebitrate
> 
> I may be off base here but if multiple bit-rates of the same codec
> are to be specified, couldn't one simply put them as multiple
> formats in the m-line, all mapped to the same codec in the
> rtpmap-lines but having different fmtp-lines?
> 
>> The set of permitted/preferred bit rate is also of interest for
>> the MELP RTP payload.  There are three permitted rates and some
>> devices may only support a specific subset.  (I know one device
>> would only handle 2400 and 600 because the tables for 1200bps are
>> huge.)
>> 
>> m=audio 49120 RTP/AVP 97 a=rtpmap:97 MELP/8000 a=fmtp:97
>> rate=2400,600,1200
>> 
>> permitted/preferred rates?  We are not trying to invent something
>> new and unique.  I believe I had seen this with one other recent
>> speech coder.
>> 
>> As an FYI, we have had a few reviewers external to the IETF
>> process provide comments.  Unfortunately they have been
>> out-of-band but they have been useful and supportive.  We would
>> like to have our proposal move forward towards an RFC in the next
>> few months if possible.
>> 
>> Regards,
>> 
>> Victor Demjanenko
>> 
>> 
>> -----Original Message----- From: payload
>> [mailto:[email-masked]] On Behalf Of Roni Even Sent:
>> Sunday, January 04, 2015 6:35 PM To: 'Mo Zanaty (mzanaty)';
>> 'Jean-Marc Valin'; 'Fredrik Bergholtz'; 'Parthasarathi R' Cc:
>> [email-masked] Subject: Re: [payload]
>> Hi, For audio/voice there are RFC5577 and RFC4749 that has a
>> bitrate parameter while RFC5404 uses the b= parameter
>> 
>> 
>> 
>> Roni Even As individual
>> 
>>> -----Original Message----- From: payload
>>> [mailto:[email-masked]] On Behalf Of Mo Zanaty 
>>> (mzanaty) Sent: 05 January, 2015 12:06 AM To: Jean-Marc Valin;
>>> Fredrik Bergholtz; Parthasarathi R Cc: [email-masked] 
>>> explicitly
>>> within the same
>>> description (m= line). The SDP b= parameter is clearly
>>> insufficient for expressing multiple different maximum bitrates
>>> for each payload type,
>> unless
>>> we define a new bandwidth modifier which includes explicit PT
>>> bindings. Payload formats that include fmtp parameters for
>>> maximum bitrate can avoid this problem, so I think it is
>>> advisable to add this to Opus, VP8 and VP9.
>>> 
>>> Mo
>>> 
> the first
>>>>> On 03/01/15 09:32 AM, Fredrik Bergholtz wrote: Hi.
>>>>> 
>>>>> One thought om the general media level bit rate
>>>>> specification is that it can never be anything other than
>>>>> an approximate value. Different codecs define different
>>>>> constraints on the bit rate. I think that the easiest way
>>>>> to specify exact bit rates would be via the fmtp
>>>>> attribute.
>>>>> 
>>>>> This can be compared with the ptime attribute - as it is
>>>>> defined today, only approximate packet times can be
>>>>> signalled in SDP. For the broadcast use case this is not
>>>>> acceptable and for that reason, the European Broadcasting
>>>>> Union (EBU) has defined an SDP extension that allows
>>>>> signalling of a ptime value for each codec. There is no RFC
>>>>> draft for this extension and it is not yet registered with
>>>>> IANA or IETF but it is starting to be used by manufacturers
>>>>> of broadcasting equipment. The extension is known as "ACIP
>>>>> Profiles" and can be found at the EBU web site. But I
>>>>> digress.
>>>>> 
>>>>> I don't think that forcing encoders to approximate the
>>>>> nearest allowed value for the selected codec is less
>>>>> complicated than interpreting an exact value. In addition,
>>>>> it would add a non-deterministic aspect, thus the resulting
>>>>> bit rate may not be what
>>> the user expected.
>>>>> 
>>>>> <[email-masked]
>>>>> <mailto:[email-masked]>> wrote:
>>>>> 
>>>>>> Hi all,
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> I  understand that bandwidth ³b² parameter has lot of
>>>>>> variants like AS, TIAS and usage but all those parameters
>>>>>> are media level and not codec specific. The bandwidth
>>>>>> allocation is going to be happen in the media level in
>>>>>> the network or end point based on the media level and not
>>>>>> on the codec specific  in case the multiple codec is
>>> negotiated.
>>>>>> In most of the implementation, the multiple codec (Say
>>>>>> Ex: G.711 & Opus) is going to be negotiated rather than
>>>>>> single codec. The codec specific bandwidth implementation
>>>>>> complicates these bandwidth calculation still further
>>>>>> which is applicable to maxaveragebitrate parameter in
>>>>>> opus.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> I could not understand why the generic parameter should
>>>>>> not used or generic parameter has to be enhanced which
>>>>>> meets Opus requirement rather than opus specific
>>>>>> parameter.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Thanks
>>>>>> 
>>>>>> Partha
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> *From:*payload [mailto:[email-masked]] *On
>>>>>> Behalf Of *Ali C. Begen (abegen) *Sent:* Wednesday,
>>>>>> December 31, 2014 4:57 PM *To:* Fredrik Bergholtz *Cc:*
>>>>>> [email-masked] <mailto:[email-masked]> *Subject:* Re:
>>>>>> [payload] draft-ietf-payload-rtp-opus-05:
>>>>>> maxaveragebitrate
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Authors
>>>>>> 
>>>>>> Please chime in and lets discuss s quick solution for
>>>>>> this on the list. Once agreed we can ship this draft.
>>>>>> 
>>>>>> -acbegen
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> *From:*Fredrik Bergholtz
>>>>>> <mailto:[email-masked]>> *Sent:* Dec
>>>>>> 31, 2014 11:42 AM *To:* Ali C. Begen (abegen) *Cc:*
>>>>>> Jean-Marc Valin <[email-masked]
>>>>>> In the broadcasting use case we have to make sure that we
>>>>>> get the best audio quality that is possible for the
>>>>>> network that is currently used but never try to send more
>>>>>> data than the particular link is capable of. For this
>>>>>> In addition we often have the requirement that the
>>>>>> quality is constant rather than the best possible. To
>>>>>> avoid as many audible changes in the audio as possible
>>>>>> over time we will often use constant bit rate and then it
>>>>>> We will use the Opus codec over various network links
>>>>>> with different capabilities in terms of bit rate, delay
>>>>>> variation, absolute delay, etc and we will typically use
>>>>>> the SDP to signal the parameters that best fit both the
>>>>>> current network and the current type of radio
>>>>>> production.
>>>>>> 
>>>>>>> My understanding is that the b= line in the SDP is
>>>>>>> quite a subjective parameter. I have seen people use it
>>>>>>> differently over the past several years. So, it is a
>>>>>>> bit difficult to infer much accuracy from that line.
>>>>>>> 
>>>>>>> OTOH, if someone feels like Opus needs to specify some
>>>>>>> sort of bitrate variability in the SDP, it can do so in
>>>>>>> an optional (opus) parameter. Obviously rules around
>>>>>>> how to set that value and what to do with that value
>>>>>>> Fredrik (or anyone else in the WG), do you see a strong
>>>>>>> need for this? If so, now is the time to mention that.
>>>>>>> 
>>>>>>> -acbegen
>>>>>>> 
>>>>>>> 
>>>>> I have to say this is not something I understand really
>>>>> well. Does anyone else here have an opinion on how to
>>>>> specify bit-rate?
>>>>> 
>>>>> Jean-Marc
>>>>> 
>>>>>>>>>> I read in the latest draft that you have removed
>>>>>>>>>> the maxaveragebitrate parameter from the SDP
>>>>>>>>>> signalling for Opus. I think that this parameter
>>>>>>>>>> is useful and that it provides added value over
>>>>>>>>>> the bandwidth modifiers added by RFC 3556.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> I must admit that I haven¹t read all of RFC 3556
>>>>>>>>>> but as I understand it, a b= line are not in any
>>>>>>>>>> way related to an actual format of a media
>>>>>>>>>> description. This means that with this mechanism,
>>>>>>>>>> only one bitrate specification can be sent with
>>>>>>>>>> each media description. Different coding
>>>>>>>>>> algorithms have different constraints on the
>>>>>>>>>> allowed bitrate. For example, I might want to
>>>>>>>>>> kbit/s and Opus at 510kbit/s with cbr. Now,
>>>>>>>>>> specifying 576kbit/s via a b= line works for
>>>>>>>>>> apt-X but makes no sense for Opus and vice versa.
>>>>>>>>>> I think that the a=fmtp line is the correct place
>>>>>>>>>> important to have a constant and predictable
>>>>>>>>>> audio quality and network usage than mere
>>>>>>>>>> audibility at any cost.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Best regards,
>>>>>>>>>> 
>>>>>>>>>> Fredrik Bergholtz
>>>>>>>>>> 
>>>>>>>>>> Swedish Radio
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> payload
>>>>>>>> payload
>>>>> mailing list [email-masked]

---

From: Jean-Marc Valin <[email-masked]>
Date: Tue, 06 Jan 2015 02:38:34 -0500

Just posted a new version that brings back maxaveragebitrate exactly
as it was before.

Cheers,

	Jean-Marc

On 05/01/15 05:32 AM, Fredrik Bergholtz wrote:
> So would everyone be happy if I just revert to using
> maxaveragebitrate as in draft 04?
> 
> Jean-Marc
> 
> 
>>>> On 04/01/15 05:05 PM, Mo Zanaty (mzanaty) wrote: Some other
>>>> codecs have fmtp parameters for maximum bitrate explicitly
>>>> (e.g. max-br in H264 / H264-SVC / H265) and/or implicitly
>>>> (e.g. profile-level-id in H264 / H264-SVC / H265 / AAC; 
>>>> config in AAC).
>>>> 
>>>> This is a general problem which may become more important
>>>> with complex applications that include simulcast and scalable
>>>> media within the same media description (m= line). The SDP b=
>>>> parameter is clearly insufficient for expressing multiple
>>>> different maximum bitrates for each payload type, unless we
>>>> define a new bandwidth modifier which includes explicit PT
>>>> Setting the bitrate isn't exactly a new problem here. Opus
>>>> isn't the first codec to support more than one rate so how
>>>> are the other codecs (audio and video) handling bitrate
>>>> signaling?
>>>> 
>>>> Cheers,
>>>> 
>>>> Jean-Marc
>>>> 
>>>>> bit rate may not be what the user expected.
>>>> 
>>>>>> negotiated. In most of the implementation, the multiple
>>>>>> codec (Say Ex: G.711 & Opus) is going to be negotiated
>>>>>> implementation complicates these bandwidth calculation
>>>>>> still further which is applicable to maxaveragebitrate
>>>>>> parameter in opus.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>>>>> send an SDP offer with both Enhanced apt-X at
>>>>>>>>>> 576 kbit/s and Opus at 510kbit/s with cbr. Now,

---

From: Fredrik Bergholtz <[email-masked]>
Date: Tue, 6 Jan 2015 09:38:00 +0000

Excellent. Thanks!

/Fredrik

> On 6 jan 2015, at 08:38, "Jean-Marc Valin" <[email-masked]> wrote:
> 
> iQEcBAEBAgAGBQJUq5D3AAoJEJ6/8sItn9q9+XkH/27U71MfStYlp2WXoaiW9SmP
> YSpGdAbDipfnJ+7RZQ0bDf0GCRtxGxyVcAqsj9oYTFQAyMd67eRp88fzY0pRODVf
> VjgWm4VLzP7jbfemzxaZXMzO/MqoiMssIvmnDB2FCirZl03aZ0vcskRAqi/OXlCm
> hVJUWkf8MqxMJ1TKqbLn+WGlWHRk89wsyxYQkbfKTfQHVPmnno8eXGvDt71Gewi1
> NYyycLisXOAAtvifE+OSGvE0PPw9GcxUgysV/fTRyzEsZV9KVzVQTa4Jj1x6ff8W
> 74ylYwYko5t93sRaEsQACVGjGYyXN/FfhpYZJNQ5S6j8gVrPc3Y5ZeFegx2jTEg=
> =fe42

---

From: "Parthasarathi R" <[email-masked]>
Date: Tue, 6 Jan 2015 23:18:26 +0530

Hi Jean-Marc/Fredrik/all,

I understand that there is a need for the parameter in the codec level and
it is followed as fmtp parameter specific to the given codec 

1) max-br (RFC 6185)  - H.264
2) maxbitrate (RFC 4749) - G.729.1
3) bitrate (RFC 5577) - G.722.1
3) maxaveragebitrate - Opus?

As per the below mail, this parameter is an open item for VP8 & VP9 and
those codecs will take their own naming convention for their maximum bit
rate. 

My concern is that it is better to have some standard naming convention for
maximum bit rate for the given codec as

1) It is simple to implement in the generic fashion in case of multiple
codec handling in the given SDP. This is the common implementation. 
2) Offer/answer behavior will be common across multiple codec.
3) Interaction with bandwidth ("b") parameter in the SDP level and these
codec specific max bit rate parameter will be clear in case both exists in
the same SDP media line.

Please let me know your opinion on the same.

Thanks
Partha

> From: payload [mailto:[email-masked]] On Behalf Of Jean-Marc
> Valin
> Sent: Tuesday, January 06, 2015 1:09 PM
> To: Fredrik Bergholtz
> Cc: [email-masked]

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 7 Jan 2015 12:55:18 +0000

I think it would have been nice if b= attribute or something similar was used for all codecs in the same fashion, but that did not really work. I agree that a common payload parameter would seem ideal, however, I dont think it would have been a lot easier to implement it. Most codecs may have exceptions here and there and dealing with such complexities would likely be tough. So if someone wants to implement codecs a and b, he needs to understand the payload parameters for both. Eliminating only one such parameter would not make much difference IMO.

> On Jan 6, 2015, at 7:48 PM, Parthasarathi R <[email-masked]> wrote:
>

---

From: "Parthasarathi R" <[email-masked]>
Date: Thu, 8 Jan 2015 06:12:02 +0530

Hi Ali,

I'm fine in case it is considered as implementers issue.

These bitrate related parameters are optional parameters for the given codec
and each implementor has its his own choice to implement or ignore.

Thanks
Partha

> From: Ali C. Begen (abegen) [mailto:[email-masked]]
> Sent: Wednesday, January 07, 2015 6:25 PM
> To: Parthasarathi R
> Cc: Jean-Marc Valin; Fredrik Bergholtz; [email-masked]
> I think it would have been nice if b= attribute or something similar
> was used for all codecs in the same fashion, but that did not really
> work. I agree that a common payload parameter would seem ideal,
> however, I dont think it would have been a lot easier to implement it.
> Most codecs may have exceptions here and there and dealing with such
> complexities would likely be tough. So if someone wants to implement
> codecs a and b, he needs to understand the payload parameters for both.
> Eliminating only one such parameter would not make much difference IMO.
> 
>

---

From: IKRAM UDDIN <[email-masked]>
Date: Sun, 11 Jan 2015 08:12:50 +0000 (UTC)

Hi,
Check RFC5577 and RFC4749 for bitrate parameter (for voice) 
Regards,
Ikram Ud Din
InterNetworks Research Laboratory,Universiti Utara Malaysia.

Thanks
Partha

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 12 Jan 2015 10:42:15 +0000

Here goes my chair review on version 06:

Section 3.1.2:
1) "network capacity” is not the term you are looking for. You need to say something like “available bandwidth”.

Section 4.2:
1) I suppose in table 2, “x” means not supported or N/A, which should be mentioned in the document. What do the empty slots mean?

Section 6.1:
1) For "Published specification:", you should not say "none", rather say "RFC [XXXX]" with an editor note the RFC editor to fix the number upon publication.
2) According to the template in rfc 6838, you are missing "Fragment identifier considerations", which I believe simply say "N/A."

3) Change controller should be "IETF Payload Working Group delegated from the IESG.”

We should be ready to ship this draft once the above is addressed.
-acbegen

On Jan 6, 2015, at 9:38 AM, Jean-Marc Valin <[email-masked]<mailto:[email-masked]>> wrote:

Cheers,

Jean-Marc

---

From: Jean-Marc Valin <[email-masked]>
Date: Tue, 13 Jan 2015 00:14:09 -0500

Hi Ali,

On 12/01/15 05:42 AM, Ali C. Begen (abegen) wrote:
> Section 3.1.2: 1) "network capacity” is not the term you are 
> looking for. You need to say something like “available bandwidth”.

How about "available network bandwidth" since we use "bandwidth"
mainly for audio frequencies in this draft?

> Section 4.2: 1) I suppose in table 2, “x” means not supported or 
> N/A, which should be mentioned in the document. What do the empty 
> slots mean?

Actually "x" means supported and the ones without an "x" aren't
supported. I guess that wasn't clear. Maybe "o" for supported and "x"
for not supported? Or do you have other suggestions?

> Section 6.1: 1) For "Published specification:", you should not say 
> "none", rather say "RFC [XXXX]" with an editor note the RFC editor 
> to fix the number upon publication.

Not sure what you mean here.

> 2) According to the template in rfc 6838, you are missing "Fragment
> identifier considerations", which I believe simply say "N/A."

Will do.

> delegated from the IESG.”

Will do.

	Jean-Marc

>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>> Just posted a new version that brings back maxaveragebitrate 
>> exactly as it was before.
>> 
>> Cheers,
>> 
>> Jean-Marc
> 
> 
>

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 13 Jan 2015 08:59:46 +0000

Hi JM,

-----Original Message-----
From: Jean-Marc Valin <[email-masked]>
Date: Tuesday, January 13, 2015 at 7:04 AM
To: "Ali C. Begen" <[email-masked]>, Jean-Marc Valin <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [payload] draft-ietf-payload-rtp-opus-05: maxaveragebitrate

>mainly for audio frequencies in this draft?

Yes, better.

>for not supported? Or do you have other suggestions?

Yeah, that is what I meant. I dont care much about the x vs o as long as
they are explained in the text. But I’d prefer “x” to denote “no support”.

>Not sure what you mean here.

Just replace the text with:

Published specification: RFC [XXXX]
Note to the RFC Editor: Replace [XXXX] with the number of the published
RFC.

>
>> 2) According to the template in rfc 6838, you are missing
>> "Fragment identifier considerations", which I believe simply say
>> "N/A."
>
>Will do.
>

Just make these changes and I will ask our AD to process this.

Thanks.

>iQEcBAEBAgAGBQJUtKdBAAoJEJ6/8sItn9q9C8YH/iXi99AnRebxMsTjA7wdtRVF
>o5Vk1Cmjw55Uw2amjLBy3G+5yYMZ1uQFnDIQkI+2WwDcZIPcxWotAUF3PajyMW0f
>yisdeKxi3t+BMabrQmJVg3MuM6bAxN9hYtV3o4G6+PCWM6/1r0EH1LPsj3EKAJ8Y
>Xqxra95HMTe4ndp7RENJXaMnSJePDLwMoXi0eKYSuV79jShPY6SvguVmSHxe3Fx1
>fZMmf/kTpSxMhO7f1rY3Kej/xe1zSF7LfiKQBEs7o4FhlumEQl1hW+BBO6lrzD/y
>JjjsM/h0HrY/KBQ7K15wJOiMoTvqnytyIe4SNAb7c9A2zNGz4Qjo9eJk6Z0dfHU=
>=ZUIp

---

From: Jean-Marc Valin <[email-masked]>
Date: Tue, 13 Jan 2015 09:22:30 -0500

Hi Ali,

Just updated the draft with all the changes you requested.

Cheers,

	Jean-Marc

On 12/01/15 05:42 AM, Ali C. Begen (abegen) wrote:
> to fix the number upon publication. 2) According to the template in
> rfc 6838, you are missing "Fragment identifier considerations",
> which I believe simply say "N/A."
>