From nobody Sat Jan 3 02:27:56 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79FEB1A89EB for ; Sat, 3 Jan 2015 02:27:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.08 X-Spam-Level: ** X-Spam-Status: No, score=2.08 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbvqBgaxVDZw for ; Sat, 3 Jan 2015 02:27:51 -0800 (PST) Received: from outbound.mailhostbox.com (outbound.mailhostbox.com [162.222.225.21]) by ietfa.amsl.com (Postfix) with ESMTP id 32F961A89C5 for ; Sat, 3 Jan 2015 02:27:50 -0800 (PST) Received: from userPC (unknown [122.178.249.70]) (Authenticated sender: partha@parthasarathi.co.in) by outbound.mailhostbox.com (Postfix) with ESMTPA id D6E57648262; Sat, 3 Jan 2015 10:27:45 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1420280870; bh=eujVTrM830flqDeRtbNlQ+nEHmel/kO4iIEEgE5swfM=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=OWi1mzl3/JTuB1xdtJC6IBiPmVk2lIEV9C4RXiA6I+NdG1KuqFmS6F5stBRuo0T3F OwPUCbt1ErZe1tjWIkWoK32Ny4mLP3dc3lUOyeSVB70AR9/+rD/MV7Ci4Kc6VaB2VP qBZA5uS26t5+iJlGgeX7VTDXCHNRZoIZPkQRvywE= From: "Parthasarathi R" To: "'Ali C. Begen \(abegen\)'" , "'Fredrik Bergholtz'" References: <548A3FEA.2070400@mozilla.com>, , <7E6F2FBF-3E29-4608-A9AE-2C5124BCE261@sverigesradio.se> <26b91d07-8e22-4790-b06e-564ee30b071d@cisco.com> In-Reply-To: <26b91d07-8e22-4790-b06e-564ee30b071d@cisco.com> Date: Sat, 3 Jan 2015 15:57:33 +0530 Message-ID: <006201d0273f$e708a230$b519e690$@co.in> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0063_01D0276E.00C0DE30" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdATp89X++FTuPj7QpWp8hHcyPj53ACMooEAA8OQx4AACfM1gP//uHjz//tbzbA= Content-Language: en-us x-cr-hashedpuzzle: ADNz FiWW H1uy KXFK LgY7 MNnt PIQ/ RYd2 RZn7 TQAR UGyK Xjw/ YUpP aj7q a8tb jv1k; 3; YQBiAGUAZwBlAG4AQABjAGkAcwBjAG8ALgBjAG8AbQA7AGYAcgBlAGQAcgBpAGsALgBiAGUAcgBnAGgAbwBsAHQAegBAAHMAdgBlAHIAaQBnAGUAcwByAGEAZABpAG8ALgBzAGUAOwBwAGEAeQBsAG8AYQBkAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {81554711-01BE-4BF4-9206-33CE4165CB93}; cABhAHIAdABoAGEAQABwAGEAcgB0AGgAYQBzAGEAcgBhAHQAaABpAC4AYwBvAC4AaQBuAA==; Sat, 03 Jan 2015 10:27:27 GMT; UgBFADoAIABbAHAAYQB5AGwAbwBhAGQAXQAgAGQAcgBhAGYAdAAtAGkAZQB0AGYALQBwAGEAeQBsAG8AYQBkAC0AcgB0AHAALQBvAHAAdQBzAC0AMAA1ADoAIABtAGEAeABhAHYAZQByAGEAZwBlAGIAaQB0AHIAYQB0AGUA x-cr-puzzleid: {81554711-01BE-4BF4-9206-33CE4165CB93} X-CTCH-RefID: str=0001.0A020205.54A7C42C.0144, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/7hn7VtvySHxseu9rM8XsmcpCrRU Cc: payload@ietf.org Subject: Re: [payload] draft-ietf-payload-rtp-opus-05: maxaveragebitrate X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2015 10:27:55 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0063_01D0276E.00C0DE30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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:payload-bounces@ietf.org] On Behalf Of Ali C. Begen (abegen) Sent: Wednesday, December 31, 2014 4:57 PM To: Fredrik Bergholtz Cc: payload@ietf.org 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 Sent: Dec 31, 2014 11:42 AM To: Ali C. Begen (abegen) Cc: Jean-Marc Valin ;Fredrik Bergholtz;payload@ietf.org 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)" 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 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 >>> payload@ietf.org >>> 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 >> payload@ietf.org >> https://www.ietf.org/mailman/listinfo/payload > ------=_NextPart_000_0063_01D0276E.00C0DE30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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:payload-bounces@ietf.org] On Behalf Of Ali C. Begen = (abegen)
Sent: Wednesday, December 31, 2014 4:57 PM
To: Fredrik Bergholtz
Cc: payload@ietf.org
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 <fredrik.bergholtz@sverigesradio.se>
Sent: Dec 31, 2014 11:42 AM
To: Ali C. Begen (abegen)
Cc: Jean-Marc Valin <jmvalin@mozilla.com>;Fredrik Bergholtz;payload@ietf.org
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)" <abegen@cisco.com> wrote:
>
> My understanding is that the b=3D 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 <jmvalin@mozilla.com> 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=3D 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=3D line works for apt-X but makes no sense for Opus and = vice versa. I
>>> think that the a=3Dfmtp 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
>>> payload@ietf.org
>>> https://www.ietf.o= rg/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=3D
>> =3DZuN4
>> -----END PGP SIGNATURE-----
>>
>> _______________________________________________
>> payload mailing list
>> payload@ietf.org
>> https://www.ietf.o= rg/mailman/listinfo/payload
>

------=_NextPart_000_0063_01D0276E.00C0DE30-- From nobody Sat Jan 3 06:33:11 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1DD1A8A0F for ; Sat, 3 Jan 2015 06:32:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.849 X-Spam-Level: X-Spam-Status: No, score=0.849 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L34Z2YvrXsCS for ; Sat, 3 Jan 2015 06:32:47 -0800 (PST) Received: from mail-1.sr.se (mail-1.sr.se [IPv6:2001:67c:d8:ed80::87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24E6D1A8A0D for ; Sat, 3 Jan 2015 06:32:46 -0800 (PST) X-Halon-ID: 5f4955b2-9355-11e4-b286-000c299c41b4 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sverigesradio.se; s=sverigesradio; h=x-halon-id:received:received:received:from:to:cc:subject:thread-topic: thread-index:date:message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator:x-c2processedorg: content-type:mime-version; bh=orsq4Sj9vThfcKR4kTlr1ywqKwPMTdG7PrHImgaO+Q0=; b=XdYEk4pEO1GpW+pU4b2v3KjczbE/LYRU9+vuiYKupzxLcESC7259fDRGaKFVd7Qs9Lzxfo0sVgsGV j4qa3UYDKqOHG1D/nXB2Smn3oTV5Occ7+pkNjECHqEzfhWdcwlg/E5/VC6RSMKtVBkZKjQVcgT+kIo MPbbDu1FBgQcf9CA= Received: from RDCEX22.sr.se (unknown [134.25.170.83]) by mail-1.sr.se (Halon Mail Gateway) with ESMTPS; Sat, 3 Jan 2015 15:32:40 +0100 (CET) Received: from RDCEX21.sr.se (134.25.170.82) by RDCEX22.sr.se (134.25.170.83) with Microsoft SMTP Server (TLS) id 15.0.995.29; Sat, 3 Jan 2015 15:32:39 +0100 Received: from RDCEX21.sr.se ([fe80::cc2e:f081:5e77:d52e]) by RDCEX21.sr.se ([fe80::cc2e:f081:5e77:d52e%21]) with mapi id 15.00.0995.028; Sat, 3 Jan 2015 15:32:39 +0100 From: Fredrik Bergholtz To: Parthasarathi R Thread-Topic: [payload] draft-ietf-payload-rtp-opus-05: maxaveragebitrate Thread-Index: AdATp89X++FTuPj7QpWp8hHcyPj53AB992kAA8ORFIAADAt6MQABiR0AAJTPRIAACqfAww== Date: Sat, 3 Jan 2015 14:32:38 +0000 Message-ID: <1CDC64C8-B130-4FB7-B73A-6F894CB729F0@sverigesradio.se> References: <548A3FEA.2070400@mozilla.com>, , <7E6F2FBF-3E29-4608-A9AE-2C5124BCE261@sverigesradio.se> <26b91d07-8e22-4790-b06e-564ee30b071d@cisco.com>, <006201d0273f$e708a230$b519e690$@co.in> In-Reply-To: <006201d0273f$e708a230$b519e690$@co.in> Accept-Language: en-GB, sv-SE, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-c2processedorg: 17a716aa-7169-4253-8985-281a7037fe2e Content-Type: multipart/alternative; boundary="_000_1CDC64C8B1304FB7B73A6F894CB729F0sverigesradiose_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/hPMzjjmW0fMeDbpawX_DxZWOEDY Cc: "payload@ietf.org" Subject: Re: [payload] draft-ietf-payload-rtp-opus-05: maxaveragebitrate X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2015 14:32:51 -0000 --_000_1CDC64C8B1304FB7B73A6F894CB729F0sverigesradiose_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi. One thought om the general media level bit rate specification is that it ca= n never be anything other than an approximate value. Different codecs defin= e different constraints on the bit rate. I think that the easiest way to sp= ecify 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 si= gnalled in SDP. For the broadcast use case this is not acceptable and for t= hat reason, the European Broadcasting Union (EBU) has defined an SDP extens= ion 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 bu= t 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 valu= e for the selected codec is less complicated than interpreting an exact val= ue. In addition, it would add a non-deterministic aspect, thus the resultin= g bit rate may not be what the user expected. Best regards Fredrik Bergholtz Swedish Radio On 3 jan 2015, at 11:27, "Parthasarathi R" > wrote: Hi all, I understand that bandwidth =93b=94 parameter has lot of variants like AS,= TIAS and usage but all those parameters are media level and not codec spec= ific. 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 spec= ific in case the multiple codec is negotiated. In most of the implementati= on, the multiple codec (Say Ex: G.711 & Opus) is going to be negotiated rat= her than single codec. The codec specific bandwidth implementation complica= tes these bandwidth calculation still further which is applicable to maxave= ragebitrate 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:payload-bounces@ietf.org] On Behalf Of Ali C. Begen (= abegen) Sent: Wednesday, December 31, 2014 4:57 PM To: Fredrik Bergholtz Cc: payload@ietf.org 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. Onc= e agreed we can ship this draft. -acbegen From: Fredrik Bergholtz > Sent: Dec 31, 2014 11:42 AM To: Ali C. Begen (abegen) Cc: Jean-Marc Valin >;Fredr= ik Bergholtz;payload@ietf.org 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 audi= o 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 rea= son, specifying a maximum bit rate is required. In addition we often have the requirement that the quality is constant rath= er 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 capabi= lities in terms of bit rate, delay variation, absolute delay, etc and we wi= ll typically use the SDP to signal the parameters that best fit both the cu= rrent 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)" > wrote: > > My understanding is that the b=3D line in the SDP is quite a subjective p= arameter. 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 va= riability in the SDP, it can do so in an optional (opus) parameter. Obvious= ly rules around how to set that value and what to do with that value need t= o 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 > 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=92t read all of RFC 3556 but as I understand = it, >>> a b=3D 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 vi= a >>> a b=3D line works for apt-X but makes no sense for Opus and vice versa.= I >>> think that the a=3Dfmtp line is the correct place to specify the desire= d >>> 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 >>> payload@ietf.org >>> 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=3D >> =3DZuN4 >> -----END PGP SIGNATURE----- >> >> _______________________________________________ >> payload mailing list >> payload@ietf.org >> https://www.ietf.org/mailman/listinfo/payload > --_000_1CDC64C8B1304FB7B73A6F894CB729F0sverigesradiose_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
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 si= gnalled in SDP. For the broadcast use case this is not acceptable and for t= hat reason, the European Broadcasting Union (EBU) has defined an SDP extens= ion that allows signalling of a ptime value for each codec. There is no RFC draft for this extension and i= t 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 "AC= IP 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 exac= t value. In addition, it would add a non-deterministic aspect, thus the res= ulting bit rate may not be what the user expected. 

Best regards
Fredrik Bergholtz
Swedish Radio

On 3 jan 2015, at 11:27, "Parthasarathi R" <partha@parthasarathi.co.in> wrote:

Hi all,

 

I  understand that bandwidth =93b=94 parameter has lot = of variants like AS, TIAS and usage but all those parameters are media leve= l and not codec specific. The bandwidth allocation is going to be happen in the media level in the netwo= rk 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 ban= dwidth 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 r= ather than opus specific parameter.

 

Thanks

Partha

 

From: payload = [mailto:payload-bounces@ietf.or= g] On Behalf Of Ali C. Begen (abegen)
Sent: Wednesday, December 31, 2014 4:57 PM
To: Fredrik Bergholtz
Cc: payload@ietf.org
Subject: Re: [payload] draft-ietf-payload-rtp-opus-05: maxaveragebit= rate

 

A= uthors

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

-acbegen

 

From: Fredri= k Bergholtz <fredr= ik.bergholtz@sverigesradio.se>
Sent: Dec 31, 2014 11:42 AM
To: Ali C. Begen (abegen)
Cc: Jean-Marc Valin <jmval= in@mozilla.com>;Fredrik Bergholtz;payload@ietf.org
Subject: Re: [payload] draft-ietf-payload-rtp-opus-05: maxaveragebit= rate

 

Yes, I do see a str= ong need for specifying the bitrate.

In the broadcasting use case we have to make sure that we get the best audi= o 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 rea= son, specifying a maximum bit rate is required.

In addition we often have the requirement that the quality is constant rath= er 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 capabi= lities in terms of bit rate, delay variation, absolute delay, etc and we wi= ll typically use the SDP to signal the parameters that best fit both the cu= rrent 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)" <abegen@cisco.com> wrote:
>
> My understanding is that the b=3D line in the SDP is quite a subjectiv= e parameter. I have seen people use it differently over the past several ye= ars. 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. Obvi= ously rules around how to set that value and what to do with that value nee= d 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 <jmvalin@mozilla.com> 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 maxaverag= ebitrate
>>> 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=92t read all of RFC 3556 but as I un= derstand it,
>>> a b=3D line are not in any way related to an actual format of = a media
>>> description. This means that with this mechanism, only one bit= rate
>>> specification can be sent with each media description. Differe= nt 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 576= kbit/s via
>>> a b=3D line works for apt-X but makes no sense for Opus and vi= ce versa. I
>>> think that the a=3Dfmtp line is the correct place to specify t= he desired
>>> bitrate.
>>>
>>>
>>>
>>> For the broadcasting use-case, it is often more important to h= ave a
>>> constant and predictable audio quality and network usage than = mere
>>> audibility at any cost.
>>>
>>>
>>>
>>> Best regards,
>>>
>>> Fredrik Bergholtz
>>>
>>> Swedish Radio
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> payload mailing list
>>> payload@ietf.org
>>> http= s://www.ietf.org/mailman/listinfo/payload
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1
>>
>> iQEcBAEBAgAGBQJUij/kAAoJEJ6/8sItn9q9V6EIALgEC6Iv+nZuu2BU8useaV= 4Z
>> jLRz97vCEdcmj60jMzELC2gSKLpVW3AMcbP7gtPjm0odeLFEMvoweUFytnVt/cd6 >> bCadjHMPAOSNXrPtbmS57JdlcmWHnsrJIVrsV/Ipn6o44FWL2BN5g/LnwlSTKs/N >> OtrjAdLj8b/GsmVS6VTTjTkygL1bp1Wsry5oAGXIPwPqFgQwuGMAxv/Wf6eEu7c3 >> eoZzBKfBDM0bC8L+RCy6REYKHvSjPbyPAH0bQvkkKHfSc6I5ZLOZspvOHBmHvQ= Fu
>> DNj4DHCShHPnRRknVnXCXX9ddSC4/bLQSyZ9+WI9622N5lkre8+VnUIGx9= iAr3I=3D
>> =3DZuN4
>> -----END PGP SIGNATURE-----
>>
>> _______________________________________________
>> payload mailing list
>> payload@ietf.org
>> https://= www.ietf.org/mailman/listinfo/payload
>

--_000_1CDC64C8B1304FB7B73A6F894CB729F0sverigesradiose_-- From nobody Sun Jan 4 11:45:34 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC95B1A8AE3 for ; Sun, 4 Jan 2015 11:45:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oM6G3z1bQQju for ; Sun, 4 Jan 2015 11:45:30 -0800 (PST) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADAD71A8AE1 for ; Sun, 4 Jan 2015 11:45:30 -0800 (PST) Received: by mail-qa0-f54.google.com with SMTP id i13so12031757qae.41 for ; Sun, 04 Jan 2015 11:45:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=hMne5nRlGxbBTyalE8ixaTRqoWVLOZkVK5c+tD/NBlM=; b=dawYyPNvH3C+CuepSmtXchgLiQhmltjAbTnkCRNLNhVskYR4Hxud9olm/qHYv0VSHO LDNRmX+ocVpPx09TF/P4oW8zQsyFDg754wqQjF3Oi21U4J/aDHk4PKyUOm21Vrg5If+H Zj5RyBNW4Mg31H9Q4WIavIThJvsURnDwS+5xBAV1NtC3MReZUuk7wYYxo+5XilJWhdXo L8WS9YmT67zF5XlE8rG2GI9M0XwREhpH1Ic5+j9mNAH1+yYxP+48KppkNlxs8BqsdHd7 ni7zbvaOAWgdQD9uJWFeXbIxYH1g9b85IqhsZvjXDveUL6GRum6NIkvL5RZQhindBCQs VO1Q== X-Gm-Message-State: ALoCoQnxwAZKKfaiKIFGV4ZnfMKMhRhf/edXvrAqaFu2oafeRsWE2Wsv5XjyPRnjb/HLrzkA2T5r X-Received: by 10.140.40.70 with SMTP id w64mr93469609qgw.32.1420400729877; Sun, 04 Jan 2015 11:45:29 -0800 (PST) Received: from panoramix.jmvalin.ca (modemcable074.170-201-24.mc.videotron.ca. [24.201.170.74]) by mx.google.com with ESMTPSA id k102sm28502425qgd.7.2015.01.04.11.45.29 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 04 Jan 2015 11:45:29 -0800 (PST) From: Jean-Marc Valin X-Google-Original-From: Jean-Marc Valin Message-ID: <54A99858.1030102@mozilla.com> Date: Sun, 04 Jan 2015 14:45:28 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Fredrik Bergholtz , Parthasarathi R References: <548A3FEA.2070400@mozilla.com>, , <7E6F2FBF-3E29-4608-A9AE-2C5124BCE261@sverigesradio.se> <26b91d07-8e22-4790-b06e-564ee30b071d@cisco.com>, <006201d0273f$e708a230$b519e690$@co.in> <1CDC64C8-B130-4FB7-B73A-6F894CB729F0@sverigesradio.se> In-Reply-To: <1CDC64C8-B130-4FB7-B73A-6F894CB729F0@sverigesradio.se> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/payload/KYjZ5waySMk9vA2RtZSih0HHpCs Cc: "payload@ietf.org" Subject: Re: [payload] draft-ietf-payload-rtp-opus-05: maxaveragebitrate X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2015 19:45:34 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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" > > > 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:payload-bounces@ietf.org] *On Behalf Of >> *Ali C. Begen (abegen) *Sent:* Wednesday, December 31, 2014 4:57 >> PM *To:* Fredrik Bergholtz *Cc:* payload@ietf.org >> *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 > > *Sent:* Dec 31, 2014 >> 11:42 AM *To:* Ali C. Begen (abegen) *Cc:* Jean-Marc Valin >> >;Fredrik >> Bergholtz;payload@ietf.org *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)" >>> > 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 >>>> > wrote: >>>> > 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 payload@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/payload >>>> >>>> _______________________________________________ payload >>>> mailing list payload@ietf.org >>>> https://www.ietf.org/mailman/listinfo/payload >>> >> > > > _______________________________________________ payload mailing > list payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUqZhTAAoJEJ6/8sItn9q9NaAH/jTELxrPUMSmhWHIODeGOrJX 67evbcn5cIsZY/8+yyofMNbaFq7DCqdR3BKX9uJ/dUJ+4yR/nbyxvw/msjd65dkv YS3HVibycnMOnZkFENr7by6vvMaZn7mIjbOWukxdBePDKHhQq7ZPec++j8gWVpbR 6qy7BSMJle9TTH3nt/kzV8YbnP7Pt0iVUorMYH/JFUzHfwcPRROKlqmdgf8yAcIZ 3Dv659NuWqoUtUx7gm+DtLIZciR2io0rKElhWf9Y7pvnPw9ZjP/ztlWMaj+zlVeU WE9fjpEtBxWCqH2KooYAhKeS2wTbvNBXvMzIRojYDcFp50gYHhgih+heQ9yVdYg= =ADn2 -----END PGP SIGNATURE----- From nobody Sun Jan 4 14:06:28 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DACF01A0174 for ; Sun, 4 Jan 2015 14:06:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KNkdoaZ8makS for ; Sun, 4 Jan 2015 14:05:36 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A03831A0178 for ; Sun, 4 Jan 2015 14:05:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9331; q=dns/txt; s=iport; t=1420409134; x=1421618734; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=iw50L46npJWvs6VnhDDH4UZz+83NnvFATqZOmo9Emto=; b=iJZUREVYjYOPy/R9wQzTXTyDd8J3V1Ft1zIJMiXRM3VS8c6E2+f5mP8M Exb3n27qTgXD0mxG+i12dI1kkLNvKZ7CemJSgaXxU5ri58cMFm42NJebR w4DuIO3w9SL59UGlJ4k1SeixffHekEL1KMYVK1+2xDeEju77+g6IYyEGP A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoFACW4qVStJV2a/2dsb2JhbABcgwZSWATGDwqFJ0oCgQQWAQEBAQF9hAwBAQEDAQEBAQliCxACAQgRBAEBAScHJwsUCQgCBAENBRuICQgNuxoBAQEBAQEBAQEBAQEBAQEBAQEBAQETBI9EMwcGhCMFiSGEdIhzgQ2CZYIziysiggEdgVBvgUV+AQEB X-IronPort-AV: E=Sophos;i="5.07,695,1413244800"; d="scan'208";a="381148624" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 04 Jan 2015 22:05:32 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t04M5VN3001895 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 4 Jan 2015 22:05:31 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.147]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0195.001; Sun, 4 Jan 2015 16:05:31 -0600 From: "Mo Zanaty (mzanaty)" To: Jean-Marc Valin , Fredrik Bergholtz , Parthasarathi R Thread-Topic: [payload] draft-ietf-payload-rtp-opus-05: maxaveragebitrate Thread-Index: AQHQKGqNv4mJR5Y3z0aZ39M0UJJI1Q== Date: Sun, 4 Jan 2015 22:05:30 +0000 Message-ID: References: <548A3FEA.2070400@mozilla.com> <7E6F2FBF-3E29-4608-A9AE-2C5124BCE261@sverigesradio.se> <26b91d07-8e22-4790-b06e-564ee30b071d@cisco.com> <006201d0273f$e708a230$b519e690$@co.in> <1CDC64C8-B130-4FB7-B73A-6F894CB729F0@sverigesradio.se> <54A99858.1030102@mozilla.com> In-Reply-To: <54A99858.1030102@mozilla.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [64.100.32.216] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <38A9357E0B975B4CA3C903BD9BD13049@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/V83igTGjeP9lWjNAWzFWk3twvPY Cc: "payload@ietf.org" Subject: Re: [payload] draft-ietf-payload-rtp-opus-05: maxaveragebitrate X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2015 22:06:25 -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=3D line). The SDP b=3D parameter is clearly insufficie= nt 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 wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > Best regards Fredrik Bergholtz Swedish Radio >=20 > On 3 jan 2015, at 11:27, "Parthasarathi R" > > > wrote: >=20 >> Hi all, >>=20 >>=20 >>=20 >> I understand that bandwidth =B3b=B2 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. >>=20 >>=20 >>=20 >> 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. >>=20 >>=20 >>=20 >> Thanks >>=20 >> Partha >>=20 >>=20 >>=20 >> *From:*payload [mailto:payload-bounces@ietf.org] *On Behalf Of >> *Ali C. Begen (abegen) *Sent:* Wednesday, December 31, 2014 4:57 >> PM *To:* Fredrik Bergholtz *Cc:* payload@ietf.org >> *Subject:* Re: [payload] >> draft-ietf-payload-rtp-opus-05: maxaveragebitrate >>=20 >>=20 >>=20 >> Authors >>=20 >> Please chime in and lets discuss s quick solution for this on >> the list. Once agreed we can ship this draft. >>=20 >> -acbegen >>=20 >>=20 >>=20 >> *From:*Fredrik Bergholtz > > *Sent:* Dec 31, 2014 >> 11:42 AM *To:* Ali C. Begen (abegen) *Cc:* Jean-Marc Valin >> >;Fredrik >> Bergholtz;payload@ietf.org *Subject:* >> Re: [payload] draft-ietf-payload-rtp-opus-05: maxaveragebitrate >>=20 >>=20 >>=20 >> Yes, I do see a strong need for specifying the bitrate. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> Best regards Fredrik Bergholtz Swedish Radio >>=20 >>=20 >>> On 31 dec 2014, at 05:57, "Ali C. Begen (abegen)" >>> > wrote: >>>=20 >>> My understanding is that the b=3D 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. >>>=20 >>> 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. >>>=20 >>> Fredrik (or anyone else in the WG), do you see a strong need >>> for this? If so, now is the time to mention that. >>>=20 >>> -acbegen >>>=20 >>>=20 >>>> On Dec 12, 2014, at 3:07 AM, Jean-Marc Valin >>>> > wrote: >>>>=20 > 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? >=20 > Jean-Marc >=20 >>>>>> On 10/12/14 05:11 AM, Fredrik Bergholtz wrote: Hi. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> I must admit that I haven=B9t read all of RFC 3556 but as I >>>>>> understand it, a b=3D 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=3D >>>>>> line works for apt-X but makes no sense for Opus and vice >>>>>> versa. I think that the a=3Dfmtp line is the correct place >>>>>> to specify the desired bitrate. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Best regards, >>>>>>=20 >>>>>> Fredrik Bergholtz >>>>>>=20 >>>>>> Swedish Radio >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ payload >>>>>> mailing list payload@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/payload >>>>=20 >>>> _______________________________________________ payload >>>> mailing list payload@ietf.org >>>> https://www.ietf.org/mailman/listinfo/payload >>>=20 >>=20 >=20 >=20 > _______________________________________________ payload mailing > list payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload >=20 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUqZhTAAoJEJ6/8sItn9q9NaAH/jTELxrPUMSmhWHIODeGOrJX 67evbcn5cIsZY/8+yyofMNbaFq7DCqdR3BKX9uJ/dUJ+4yR/nbyxvw/msjd65dkv YS3HVibycnMOnZkFENr7by6vvMaZn7mIjbOWukxdBePDKHhQq7ZPec++j8gWVpbR 6qy7BSMJle9TTH3nt/kzV8YbnP7Pt0iVUorMYH/JFUzHfwcPRROKlqmdgf8yAcIZ 3Dv659NuWqoUtUx7gm+DtLIZciR2io0rKElhWf9Y7pvnPw9ZjP/ztlWMaj+zlVeU WE9fjpEtBxWCqH2KooYAhKeS2wTbvNBXvMzIRojYDcFp50gYHhgih+heQ9yVdYg=3D =3DADn2 -----END PGP SIGNATURE----- _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload From nobody Sun Jan 4 15:16:39 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61C2E1A02F1 for ; Sun, 4 Jan 2015 15:16:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k9sy6g4IsIi7 for ; Sun, 4 Jan 2015 15:16:35 -0800 (PST) Received: from mail-qg0-f54.google.com (mail-qg0-f54.google.com [209.85.192.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1012F1A028A for ; Sun, 4 Jan 2015 15:16:34 -0800 (PST) Received: by mail-qg0-f54.google.com with SMTP id l89so14457523qgf.41 for ; Sun, 04 Jan 2015 15:16:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=G2gkEXMz6Fo1NA4IUgXJ6ptyx+j83QZ8ANUoTdvmefc=; b=YMjpYS0/KvF+J2MRjPZNZUTys2dUM5WEyTJdolqq8gNnmmTTV70x0vkZ9CenNNXnmJ UyPzTB64V3EWxaYc4qnZF/ZjQs4xf6zADt4hyZQXCkq2AmCjrJFwvmIxizE1cCA7MUOQ ww21GOXC2za+Gdz2NsKMyNUo1XHT1lu1G43gXOHSe5V8MkBDA6wgiEYqCmw75uibXUtI 3hX3FFLD/rozEvE/2gyswYj9c769vNTOWu8VCDhjHjIiF+dvj0zWWlI0yUf8qTZDz0Uu /ZgjIZIR6um0hjRpXs42Gdz13+fSeoRzDxTpAUW/EBx+wvy0hnejdI0Dpj0yh2B+F9N/ z2lg== X-Gm-Message-State: ALoCoQmPSngPXDo8ZcHffwJ3uYg5Db37neCTrfmXL9NZk9bhDIUy9hQp8KMf0E+CEk7A8uAK/Y7E X-Received: by 10.224.37.5 with SMTP id v5mr143384198qad.25.1420413393923; Sun, 04 Jan 2015 15:16:33 -0800 (PST) Received: from panoramix.jmvalin.ca (modemcable074.170-201-24.mc.videotron.ca. [24.201.170.74]) by mx.google.com with ESMTPSA id g12sm49188788qay.44.2015.01.04.15.16.32 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 04 Jan 2015 15:16:33 -0800 (PST) From: Jean-Marc Valin X-Google-Original-From: Jean-Marc Valin Message-ID: <54A9C9D0.8050002@mozilla.com> Date: Sun, 04 Jan 2015 18:16:32 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Mo Zanaty (mzanaty)" , Jean-Marc Valin , Fredrik Bergholtz , Parthasarathi R References: <548A3FEA.2070400@mozilla.com> <7E6F2FBF-3E29-4608-A9AE-2C5124BCE261@sverigesradio.se> <26b91d07-8e22-4790-b06e-564ee30b071d@cisco.com> <006201d0273f$e708a230$b519e690$@co.in> <1CDC64C8-B130-4FB7-B73A-6F894CB729F0@sverigesradio.se> <54A99858.1030102@mozilla.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/payload/96q40qtiS-Hk4YiQHmapTPNOX-M Cc: "payload@ietf.org" Subject: Re: [payload] draft-ietf-payload-rtp-opus-05: maxaveragebitrate X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2015 23:16:38 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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). > > 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 wrote: > > 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" >> > >> 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:payload-bounces@ietf.org] *On Behalf Of >>> *Ali C. Begen (abegen) *Sent:* Wednesday, December 31, 2014 >>> 4:57 PM *To:* Fredrik Bergholtz *Cc:* payload@ietf.org >>> *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 >> > *Sent:* Dec 31, >>> 2014 11:42 AM *To:* Ali C. Begen (abegen) *Cc:* Jean-Marc >>> Valin >> >;Fredrik >>> Bergholtz;payload@ietf.org >>> *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)" >>>> > 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 >>>>> > wrote: >>>>> >> 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 payload@ietf.org >>>>>>> >>>>>>> https://www.ietf.org/mailman/listinfo/payload >>>>> >>>>> _______________________________________________ payload >>>>> mailing list payload@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/payload >>>> >>> > > >> _______________________________________________ payload mailing >> list payload@ietf.org >> https://www.ietf.org/mailman/listinfo/payload > > > _______________________________________________ payload mailing > list payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload > > _______________________________________________ payload mailing > list payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUqcnLAAoJEJ6/8sItn9q9c5MIALwwSsXAUeJwGhbQiyV8plkT R0cNeuqV1+8rMBK/XYZORBPWqrAVvhNh6fs1eh0fn8e5aNioHGUyCY/d63u1g1qh PkL/vloGt6F30QBlsZShL9AkPtWLWPwuSE5H9kczcOR6uoRA1wj7adchjCaPRdl1 4Y1yx71qNbonxKowA1i1ekVCYQiaTOScyvWtuga23DHuMH8ib6n7aFB4vj2qHZyq TaJ23Turl8uEgSBoHW/6FnXfOcDRv1U028b10US0EaNRKyfad/U9OU7MPaMd5Lzk PBT4XMU5ZBprQ2UzEBtER5XpwLXWqvVETK2HyRlTEhg2fJUXKL6Y2v3QV4qjg+4= =rNBB -----END PGP SIGNATURE----- From nobody Sun Jan 4 15:35:24 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91E161A0273 for ; Sun, 4 Jan 2015 15:35:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_14=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zk7oDCIWB-2I for ; Sun, 4 Jan 2015 15:35:19 -0800 (PST) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AAC51A014E for ; Sun, 4 Jan 2015 15:35:18 -0800 (PST) Received: by mail-wg0-f42.google.com with SMTP id k14so26660067wgh.1 for ; Sun, 04 Jan 2015 15:35:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=ZlYtdxmA5OLFa52Gg6xvbt3pJdUb3tg3WHmsH7C+KiI=; b=jqmHCvT3elSyNBHUb6PmeEUwtBKbUglweyhJv7k3nvvInpo3DsqKhVj4HaV1ruKn9I Zyebzatmpwh4AtoAlLE5WIjmSxC1/kohLrY1S+dvOS5a/M2DdhHd5GutjNGPyIJyvh4d xRSBzxo0/SJa9cFGAPiVPqvyYtR7NVZLxb8yaBgwRIkcetUi/w3eA41ptUpSymGeuX3J yH//D8DlhwtCU5K3+h5+ZUIUhvDbFtF4gm9itLfE6sssLtAKA+FTrLqbaWr33CnB1BlY nu/i9bssJy5mR0JOcjTCrPRMelmS9rXIxTSNtLfofEKhtHDFtoNddvasCAH+xQnH7E35 T2jA== X-Received: by 10.180.80.163 with SMTP id s3mr19506960wix.59.1420414517250; Sun, 04 Jan 2015 15:35:17 -0800 (PST) Received: from RoniE (bzq-79-179-153-238.red.bezeqint.net. [79.179.153.238]) by mx.google.com with ESMTPSA id bj3sm7800956wib.3.2015.01.04.15.35.14 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 04 Jan 2015 15:35:16 -0800 (PST) From: "Roni Even" To: "'Mo Zanaty \(mzanaty\)'" , "'Jean-Marc Valin'" , "'Fredrik Bergholtz'" , "'Parthasarathi R'" References: <548A3FEA.2070400@mozilla.com> <7E6F2FBF-3E29-4608-A9AE-2C5124BCE261@sverigesradio.se> <26b91d07-8e22-4790-b06e-564ee30b071d@cisco.com> <006201d0273f$e708a230$b519e690$@co.in> <1CDC64C8-B130-4FB7-B73A-6F894CB729F0@sverigesradio.se> <54A99858.1030102@mozilla.com> In-Reply-To: Date: Mon, 5 Jan 2015 01:35:04 +0200 Message-ID: <017401d02877$172e8b90$458ba2b0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKXCp6wkWrVobm7b2iVqZ3ev2WZtwKhKMVuAY1FNxYB1Bk7KgIHlCMJApuH5qYBrrS3AwJzvk/eAeJmsNCanX5RMA== Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/payload/J0JUpgUP9YbfYfCtKl1ujNFJQHE Cc: payload@ietf.org Subject: Re: [payload] draft-ietf-payload-rtp-opus-05: maxaveragebitrate X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2015 23:35:21 -0000 Hi, For audio/voice there are RFC5577 and RFC4749 that has a bitrate = parameter while RFC5404 uses the b=3D parameter Roni Even As individual > -----Original Message----- > From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Mo Zanaty > (mzanaty) > Sent: 05 January, 2015 12:06 AM > To: Jean-Marc Valin; Fredrik Bergholtz; Parthasarathi R > Cc: payload@ietf.org > Subject: Re: [payload] draft-ietf-payload-rtp-opus-05: = maxaveragebitrate >=20 > 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). >=20 > Other notable codecs that lack this include VP8 and VP9. >=20 > 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=3D line). The SDP b=3D 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. >=20 > Mo >=20 > On 1/4/15, 2:45 PM, Jean-Marc Valin wrote: >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > 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? >=20 > Cheers, >=20 > Jean-Marc >=20 > 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" > > > > > wrote: > > > >> Hi all, > >> > >> > >> > >> I understand that bandwidth =B3b=B2 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:payload-bounces@ietf.org] *On Behalf Of *Ali > >> C. Begen (abegen) *Sent:* Wednesday, December 31, 2014 4:57 PM = *To:* > >> Fredrik Bergholtz *Cc:* payload@ietf.org > >> *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 >> > *Sent:* Dec 31, 2014 > >> 11:42 AM *To:* Ali C. Begen (abegen) *Cc:* Jean-Marc Valin > >> >;Fredrik > >> Bergholtz;payload@ietf.org *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)" > >>> > wrote: > >>> > >>> My understanding is that the b=3D 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 >>>> > wrote: > >>>> > > 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=B9t read all of RFC 3556 but as I > >>>>>> understand it, a b=3D 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=3D = line > >>>>>> works for apt-X but makes no sense for Opus and vice versa. I > >>>>>> think that the a=3Dfmtp 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 payload@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/payload > >>>> > >>>> _______________________________________________ payload > mailing > >>>> list payload@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/payload > >>> > >> > > > > > > _______________________________________________ payload mailing list > > payload@ietf.org https://www.ietf.org/mailman/listinfo/payload > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 >=20 > iQEcBAEBAgAGBQJUqZhTAAoJEJ6/8sItn9q9NaAH/jTELxrPUMSmhWHIODeGOrJ > X > 67evbcn5cIsZY/8+yyofMNbaFq7DCqdR3BKX9uJ/dUJ+4yR/nbyxvw/msjd65dkv > YS3HVibycnMOnZkFENr7by6vvMaZn7mIjbOWukxdBePDKHhQq7ZPec++j8gWVp > bR > 6qy7BSMJle9TTH3nt/kzV8YbnP7Pt0iVUorMYH/JFUzHfwcPRROKlqmdgf8yAcIZ > 3Dv659NuWqoUtUx7gm+DtLIZciR2io0rKElhWf9Y7pvnPw9ZjP/ztlWMaj+zlVeU > WE9fjpEtBxWCqH2KooYAhKeS2wTbvNBXvMzIRojYDcFp50gYHhgih+heQ9yVdYg=3D > =3DADn2 > -----END PGP SIGNATURE----- >=20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload >=20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload From nobody Mon Jan 5 02:32:55 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B73201A3BA0 for ; Mon, 5 Jan 2015 02:32:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.051 X-Spam-Level: X-Spam-Status: No, score=-1.051 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, J_CHICKENPOX_14=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4SUGDc9Di2Yd for ; Mon, 5 Jan 2015 02:32:50 -0800 (PST) Received: from mail-1.sr.se (mail-1.sr.se [IPv6:2001:67c:d8:ed80::87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E70C01A1B8A for ; Mon, 5 Jan 2015 02:32:49 -0800 (PST) X-Halon-ID: 2f09c8f3-94c6-11e4-b286-000c299c41b4 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sverigesradio.se; s=sverigesradio; h=x-halon-id:received:received:received:from:to:cc:subject:thread-topic: thread-index:date:message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator:x-c2processedorg: content-type:content-transfer-encoding:mime-version; bh=nujddt8JFQIBWRF6JG+X4Ov1dcGqe0eQGLGE4YTYZa4=; b=JX2B1EPszGfKHZgV/Zz2GXvRFYs1GqMEugv83pX7WRTMvYFFeh5uMZLT2RedFM/I+1FBms+pbTu2G pdyN2ptSegJN673qsk1X7OyGgPbzQg0G/qBtekuCamjvkYtRrBb67QO3zEp7PnJl4vFgX8wZ5z7Ani OP34z7OUGBpF7vyE= Received: from RDCEX22.sr.se (unknown [134.25.170.83]) by mail-1.sr.se (Halon Mail Gateway) with ESMTPS; Mon, 5 Jan 2015 11:32:44 +0100 (CET) Received: from RDCEX21.sr.se (134.25.170.82) by RDCEX22.sr.se (134.25.170.83) with Microsoft SMTP Server (TLS) id 15.0.995.29; Mon, 5 Jan 2015 11:32:43 +0100 Received: from RDCEX21.sr.se ([fe80::cc2e:f081:5e77:d52e]) by RDCEX21.sr.se ([fe80::cc2e:f081:5e77:d52e%21]) with mapi id 15.00.0995.028; Mon, 5 Jan 2015 11:32:43 +0100 From: Fredrik Bergholtz To: Jean-Marc Valin Thread-Topic: [payload] draft-ietf-payload-rtp-opus-05: maxaveragebitrate Thread-Index: AdATp89X++FTuPj7QpWp8hHcyPj53AB992kAA8ORFIAADAt6MQABiR0AAJTPRIAACqfAwwA7HwQAAATj/wAAAnsWAAAZtePN Date: Mon, 5 Jan 2015 10:32:42 +0000 Message-ID: <06DA8517-E9D8-4726-8FAE-EB7D4B110674@sverigesradio.se> References: <548A3FEA.2070400@mozilla.com> <7E6F2FBF-3E29-4608-A9AE-2C5124BCE261@sverigesradio.se> <26b91d07-8e22-4790-b06e-564ee30b071d@cisco.com> <006201d0273f$e708a230$b519e690$@co.in> <1CDC64C8-B130-4FB7-B73A-6F894CB729F0@sverigesradio.se> <54A99858.1030102@mozilla.com> ,<54A9C9D0.8050002@mozilla.com> In-Reply-To: <54A9C9D0.8050002@mozilla.com> Accept-Language: en-GB, sv-SE, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-c2processedorg: 17a716aa-7169-4253-8985-281a7037fe2e Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/bzr7X6HqbJrG51p2ffg6wKEoVmY Cc: Jean-Marc Valin , "payload@ietf.org" Subject: Re: [payload] draft-ietf-payload-rtp-opus-05: maxaveragebitrate X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 10:32:53 -0000 I think that re-instating maxaveragebitrate would do it for me.=20 /Fredrik > On 5 jan 2015, at 00:16, "Jean-Marc Valin" wrote: >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > So would everyone be happy if I just revert to using maxaveragebitrate > as in draft 04? >=20 > Jean-Marc >=20 >=20 >> 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). >>=20 >> Other notable codecs that lack this include VP8 and VP9. >>=20 >> 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=3D line). The SDP b=3D 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. >>=20 >> Mo >>=20 >> On 1/4/15, 2:45 PM, Jean-Marc Valin wrote: >>=20 >> 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? >>=20 >> Cheers, >>=20 >> Jean-Marc >>=20 >>> On 03/01/15 09:32 AM, Fredrik Bergholtz wrote: >>> Hi. >>=20 >>> One thought om the general media level bit rate specification is=20 >>> that it can never be anything other than an approximate value.=20 >>> Different codecs define different constraints on the bit rate. I=20 >>> think that the easiest way to specify exact bit rates would be >>> via the fmtp attribute. >>=20 >>> This can be compared with the ptime attribute - as it is defined=20 >>> 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. >>=20 >>> I don't think that forcing encoders to approximate the nearest=20 >>> allowed value for the selected codec is less complicated than=20 >>> interpreting an exact value. In addition, it would add a=20 >>> non-deterministic aspect, thus the resulting bit rate may not be=20 >>> what the user expected. >>=20 >>> Best regards Fredrik Bergholtz Swedish Radio >>=20 >>> On 3 jan 2015, at 11:27, "Parthasarathi R"=20 >>> >=20 >>> wrote: >>=20 >>>> Hi all, >>>>=20 >>>>=20 >>>>=20 >>>> I understand that bandwidth =B3b=B2 parameter has lot of variants=20 >>>> 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. >>>>=20 >>>>=20 >>>>=20 >>>> I could not understand why the generic parameter should not >>>> used or generic parameter has to be enhanced which meets Opus=20 >>>> requirement rather than opus specific parameter. >>>>=20 >>>>=20 >>>>=20 >>>> Thanks >>>>=20 >>>> Partha >>>>=20 >>>>=20 >>>>=20 >>>> *From:*payload [mailto:payload-bounces@ietf.org] *On Behalf Of=20 >>>> *Ali C. Begen (abegen) *Sent:* Wednesday, December 31, 2014 >>>> 4:57 PM *To:* Fredrik Bergholtz *Cc:* payload@ietf.org=20 >>>> *Subject:* Re: [payload]=20 >>>> draft-ietf-payload-rtp-opus-05: maxaveragebitrate >>>>=20 >>>>=20 >>>>=20 >>>> Authors >>>>=20 >>>> Please chime in and lets discuss s quick solution for this on=20 >>>> the list. Once agreed we can ship this draft. >>>>=20 >>>> -acbegen >>>>=20 >>>>=20 >>>>=20 >>>> *From:*Fredrik Bergholtz >>> > *Sent:* Dec 31, >>>> 2014 11:42 AM *To:* Ali C. Begen (abegen) *Cc:* Jean-Marc >>>> Valin >>> >;Fredrik=20 >>>> Bergholtz;payload@ietf.org >>>> *Subject:* Re: [payload] draft-ietf-payload-rtp-opus-05: >>>> maxaveragebitrate >>>>=20 >>>>=20 >>>>=20 >>>> Yes, I do see a strong need for specifying the bitrate. >>>>=20 >>>> 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=20 >>>> particular link is capable of. For this reason, specifying a=20 >>>> maximum bit rate is required. >>>>=20 >>>> In addition we often have the requirement that the quality is=20 >>>> 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. >>>>=20 >>>> We will use the Opus codec over various network links with=20 >>>> different capabilities in terms of bit rate, delay variation,=20 >>>> 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. >>>>=20 >>>> Best regards Fredrik Bergholtz Swedish Radio >>>>=20 >>>>=20 >>>>> On 31 dec 2014, at 05:57, "Ali C. Begen (abegen)"=20 >>>>> > wrote: >>>>>=20 >>>>> My understanding is that the b=3D line in the SDP is quite a=20 >>>>> subjective parameter. I have seen people use it differently=20 >>>>> over the past several years. So, it is a bit difficult to >>>>> infer much accuracy from that line. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> Fredrik (or anyone else in the WG), do you see a strong need=20 >>>>> for this? If so, now is the time to mention that. >>>>>=20 >>>>> -acbegen >>>>>=20 >>>>>=20 >>>>>> On Dec 12, 2014, at 3:07 AM, Jean-Marc Valin=20 >>>>>> > wrote: >>> 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? >>=20 >>> Jean-Marc >>=20 >>>>>>>> On 10/12/14 05:11 AM, Fredrik Bergholtz wrote: Hi. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> I read in the latest draft that you have removed the=20 >>>>>>>> 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. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> I must admit that I haven=B9t read all of RFC 3556 but as >>>>>>>> I understand it, a b=3D 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=3D line works for apt-X but makes no >>>>>>>> sense for Opus and vice versa. I think that the a=3Dfmtp >>>>>>>> line is the correct place to specify the desired >>>>>>>> bitrate. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> 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. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Best regards, >>>>>>>>=20 >>>>>>>> Fredrik Bergholtz >>>>>>>>=20 >>>>>>>> Swedish Radio >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> payload mailing list payload@ietf.org >>>>>>>> =20 >>>>>>>> https://www.ietf.org/mailman/listinfo/payload >>>>>>=20 >>>>>> _______________________________________________ payload=20 >>>>>> mailing list payload@ietf.org =20 >>>>>> https://www.ietf.org/mailman/listinfo/payload >>=20 >>=20 >>> _______________________________________________ payload mailing=20 >>> list payload@ietf.org=20 >>> https://www.ietf.org/mailman/listinfo/payload >>=20 >>=20 >> _______________________________________________ payload mailing >> list payload@ietf.org=20 >> https://www.ietf.org/mailman/listinfo/payload >>=20 >> _______________________________________________ payload mailing >> list payload@ietf.org=20 >> https://www.ietf.org/mailman/listinfo/payload > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 >=20 > iQEcBAEBAgAGBQJUqcnLAAoJEJ6/8sItn9q9c5MIALwwSsXAUeJwGhbQiyV8plkT > R0cNeuqV1+8rMBK/XYZORBPWqrAVvhNh6fs1eh0fn8e5aNioHGUyCY/d63u1g1qh > PkL/vloGt6F30QBlsZShL9AkPtWLWPwuSE5H9kczcOR6uoRA1wj7adchjCaPRdl1 > 4Y1yx71qNbonxKowA1i1ekVCYQiaTOScyvWtuga23DHuMH8ib6n7aFB4vj2qHZyq > TaJ23Turl8uEgSBoHW/6FnXfOcDRv1U028b10US0EaNRKyfad/U9OU7MPaMd5Lzk > PBT4XMU5ZBprQ2UzEBtER5XpwLXWqvVETK2HyRlTEhg2fJUXKL6Y2v3QV4qjg+4=3D > =3DrNBB > -----END PGP SIGNATURE----- From nobody Mon Jan 5 06:00:15 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00FED1A87E8 for ; Mon, 5 Jan 2015 06:00:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.3 X-Spam-Level: X-Spam-Status: No, score=0.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, MSGID_MULTIPLE_AT=1] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2G8TyDLBt1F for ; Mon, 5 Jan 2015 06:00:11 -0800 (PST) Received: from cuda.olm1.com (cuda.olm1.com [72.236.255.32]) by ietfa.amsl.com (Postfix) with ESMTP id 091DE1A87D2 for ; Mon, 5 Jan 2015 06:00:10 -0800 (PST) X-ASG-Debug-ID: 1420466408-03d2503d471c550001-U2jSCT Received: from host101.olm1.com (host101.olm1.com [72.236.255.11]) by cuda.olm1.com with ESMTP id ADjgpIWQOgANt0t1; Mon, 05 Jan 2015 09:00:08 -0500 (EST) X-Barracuda-Envelope-From: Victor.Demjanenko@vocal.com X-Barracuda-Apparent-Source-IP: 72.236.255.11 Received: from host101.olm1.com (unknown [127.0.0.1]) by host101.olm1.com (Postfix) with ESMTP id 8A2CE697075E; Mon, 5 Jan 2015 09:00:08 -0500 (EST) Received: from dev1PC (unknown [72.43.202.98]) by host101.olm1.com (Postfix) with ESMTP; Mon, 5 Jan 2015 09:00:08 -0500 (EST) From: "Victor Demjanenko, Ph.D." To: "'Roni Even'" , "'Mo Zanaty \(mzanaty\)'" , "'Jean-Marc Valin'" , "'Fredrik Bergholtz'" , "'Parthasarathi R'" References: <548A3FEA.2070400@mozilla.com> <7E6F2FBF-3E29-4608-A9AE-2C5124BCE261@sverigesradio.se> <26b91d07-8e22-4790-b06e-564ee30b071d@cisco.com> <006201d0273f$e708a230$b519e690$@co.in> <1CDC64C8-B130-4FB7-B73A-6F894CB729F0@sverigesradio.se> <54A99858.1030102@mozilla.com> <017401d02877$172e8b90$458ba2b0$@gmail.com> In-Reply-To: <017401d02877$172e8b90$458ba2b0$@gmail.com> Date: Mon, 5 Jan 2015 09:00:08 -0500 X-ASG-Orig-Subj: RE: [payload] draft-ietf-payload-rtp-opus-05: maxaveragebitrate Message-ID: <184801d028ef$eacb9650$c062c2f0$@Demjanenko@vocal.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQKXCp6wkWrVobm7b2iVqZ3ev2WZtwKhKMVuAY1FNxYB1Bk7KgIHlCMJApuH5qYBrrS3AwJzvk/eAeJmsNCanX5RMIAA9jJg Content-Language: en-us X-Barracuda-Connect: host101.olm1.com[72.236.255.11] X-Barracuda-Start-Time: 1420466408 X-Barracuda-URL: http://72.236.255.32:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at olm1.com X-Barracuda-Bayes: SPAM GLOBAL 0.9498 1.0000 3.7702 X-Barracuda-Spam-Score: 3.78 X-Barracuda-Spam-Status: No, SCORE=3.78 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=5.0 tests=BSF_SC0_MISMATCH_TO, MSGID_MULTIPLE_AT X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.13951 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 MSGID_MULTIPLE_AT Message-ID contains multiple '@' characters 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header Archived-At: http://mailarchive.ietf.org/arch/msg/payload/Nf-ux0D5t8vhf31kkvunPh32fZM Cc: payload@ietf.org Subject: Re: [payload] draft-ietf-payload-rtp-opus-05: maxaveragebitrate X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 14:00:14 -0000 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=3Daudio 49120 RTP/AVP 97=20 a=3Drtpmap:97 MELP/8000=20 a=3Dfmtp:97 rate=3D2400,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. =20 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:payload-bounces@ietf.org] 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: payload@ietf.org Subject: Re: [payload] draft-ietf-payload-rtp-opus-05: maxaveragebitrate Hi, For audio/voice there are RFC5577 and RFC4749 that has a bitrate = parameter while RFC5404 uses the b=3D parameter Roni Even As individual > -----Original Message----- > From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Mo Zanaty > (mzanaty) > Sent: 05 January, 2015 12:06 AM > To: Jean-Marc Valin; Fredrik Bergholtz; Parthasarathi R > Cc: payload@ietf.org > Subject: Re: [payload] draft-ietf-payload-rtp-opus-05:=20 > maxaveragebitrate >=20 > 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). >=20 > Other notable codecs that lack this include VP8 and VP9. >=20 > 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=3D line). The SDP b=3D parameter is clearly = insufficient=20 > for expressing multiple different maximum bitrates for each payload=20 > type, unless > we define a new bandwidth modifier which includes explicit PT = bindings. > Payload formats that include fmtp parameters for maximum bitrate can=20 > avoid this problem, so I think it is advisable to add this to Opus, > VP8 and VP9. >=20 > Mo >=20 > On 1/4/15, 2:45 PM, Jean-Marc Valin wrote: >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Setting the bitrate isn't exactly a new problem here. Opus isn't the=20 > first codec > to support more than one rate so how are the other codecs (audio and video) > handling bitrate signaling? >=20 > Cheers, >=20 > Jean-Marc >=20 > On 03/01/15 09:32 AM, Fredrik Bergholtz wrote: > > Hi. > > > > One thought om the general media level bit rate specification is=20 > > that it can never be anything other than an approximate value. > > Different codecs define different constraints on the bit rate. I=20 > > think that the easiest way to specify exact bit rates would be via=20 > > the fmtp attribute. > > > > This can be compared with the ptime attribute - as it is defined=20 > > today, only approximate packet times can be signalled in SDP. For=20 > > the broadcast use case this is not acceptable and for that reason,=20 > > the European Broadcasting Union (EBU) has defined an SDP extension=20 > > that allows signalling of a ptime value for each codec. There is no=20 > > RFC draft for this extension and it is not yet registered with IANA=20 > > or IETF but it is starting to be used by manufacturers of=20 > > 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=20 > > allowed value for the selected codec is less complicated than=20 > > interpreting an exact value. In addition, it would add a=20 > > 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" > > > > > wrote: > > > >> Hi all, > >> > >> > >> > >> I understand that bandwidth =B3b=B2 parameter has lot of variants = like=20 > >> AS, TIAS and usage but all those parameters are media level and not = > >> codec specific. The bandwidth allocation is going to be happen in=20 > >> the media level in the network or end point based on the media=20 > >> 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=20 > >> calculation still further which is applicable to maxaveragebitrate=20 > >> 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=20 > >> rather than opus specific parameter. > >> > >> > >> > >> Thanks > >> > >> Partha > >> > >> > >> > >> *From:*payload [mailto:payload-bounces@ietf.org] *On Behalf Of *Ali = > >> C. Begen (abegen) *Sent:* Wednesday, December 31, 2014 4:57 PM=20 > >> *To:* Fredrik Bergholtz *Cc:* payload@ietf.org=20 > >> > >> *Subject:* Re: [payload] > >> draft-ietf-payload-rtp-opus-05: maxaveragebitrate > >> > >> > >> > >> Authors > >> > >> Please chime in and lets discuss s quick solution for this on the=20 > >> list. Once agreed we can ship this draft. > >> > >> -acbegen > >> > >> > >> > >> *From:*Fredrik Bergholtz >> > *Sent:* Dec 31, 2014 > >> 11:42 AM *To:* Ali C. Begen (abegen) *Cc:* Jean-Marc Valin=20 > >> >;Fredrik > >> Bergholtz;payload@ietf.org *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=20 > >> best audio quality that is possible for the network that is=20 > >> currently used but never try to send more data than the particular=20 > >> link is capable of. For this reason, specifying a maximum bit rate=20 > >> is required. > >> > >> In addition we often have the requirement that the quality is=20 > >> constant rather than the best possible. To avoid as many audible=20 > >> changes in the audio as possible over time we will often use=20 > >> constant bit rate and then it becomes even more important to be=20 > >> able to specify what bit rate should be. > >> > >> We will use the Opus codec over various network links with=20 > >> different capabilities in terms of bit rate, delay variation,=20 > >> absolute delay, etc and we will typically use the SDP to signal the = > >> parameters that best fit both the current network and the current=20 > >> type of radio production. > >> > >> Best regards Fredrik Bergholtz Swedish Radio > >> > >> > >>> On 31 dec 2014, at 05:57, "Ali C. Begen (abegen)" > >>> > wrote: > >>> > >>> My understanding is that the b=3D line in the SDP is quite a=20 > >>> subjective parameter. I have seen people use it differently over=20 > >>> the past several years. So, it is a bit difficult to infer much=20 > >>> accuracy from that line. > >>> > >>> OTOH, if someone feels like Opus needs to specify some sort of=20 > >>> 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=20 > >>> this? If so, now is the time to mention that. > >>> > >>> -acbegen > >>> > >>> > >>>> On Dec 12, 2014, at 3:07 AM, Jean-Marc Valin >>>> > wrote: > >>>> > > I have to say this is not something I understand really well. Does=20 > > 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=20 > >>>>>> maxaveragebitrate parameter from the SDP signalling for Opus. I = > >>>>>> think that this parameter is useful and that it provides added=20 > >>>>>> value over the bandwidth modifiers added by RFC 3556. > >>>>>> > >>>>>> > >>>>>> > >>>>>> I must admit that I haven=B9t read all of RFC 3556 but as I=20 > >>>>>> understand it, a b=3D line are not in any way related to an=20 > >>>>>> 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=20 > >>>>>> constraints on the allowed bitrate. For example, I might want=20 > >>>>>> 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=3D=20 > >>>>>> line works for apt-X but makes no sense for Opus and vice=20 > >>>>>> versa. I think that the a=3Dfmtp line is the correct place to=20 > >>>>>> specify the desired bitrate. > >>>>>> > >>>>>> > >>>>>> > >>>>>> For the broadcasting use-case, it is often more important to=20 > >>>>>> 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 payload@ietf.org =20 > >>>>>> https://www.ietf.org/mailman/listinfo/payload > >>>> > >>>> _______________________________________________ payload > mailing > >>>> list payload@ietf.org =20 > >>>> https://www.ietf.org/mailman/listinfo/payload > >>> > >> > > > > > > _______________________________________________ payload mailing list = > > payload@ietf.org https://www.ietf.org/mailman/listinfo/payload > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 >=20 > iQEcBAEBAgAGBQJUqZhTAAoJEJ6/8sItn9q9NaAH/jTELxrPUMSmhWHIODeGOrJ > X > 67evbcn5cIsZY/8+yyofMNbaFq7DCqdR3BKX9uJ/dUJ+4yR/nbyxvw/msjd65dkv > YS3HVibycnMOnZkFENr7by6vvMaZn7mIjbOWukxdBePDKHhQq7ZPec++j8gWVp > bR > 6qy7BSMJle9TTH3nt/kzV8YbnP7Pt0iVUorMYH/JFUzHfwcPRROKlqmdgf8yAcIZ > 3Dv659NuWqoUtUx7gm+DtLIZciR2io0rKElhWf9Y7pvnPw9ZjP/ztlWMaj+zlVeU > WE9fjpEtBxWCqH2KooYAhKeS2wTbvNBXvMzIRojYDcFp50gYHhgih+heQ9yVdYg=3D > =3DADn2 > -----END PGP SIGNATURE----- >=20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload >=20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload From nobody Mon Jan 5 06:33:50 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 725411A8870 for ; Mon, 5 Jan 2015 06:33:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.451 X-Spam-Level: X-Spam-Status: No, score=-0.451 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id At319ZLWX6UN for ; Mon, 5 Jan 2015 06:33:36 -0800 (PST) Received: from mail-1.sr.se (mail-1.sr.se [IPv6:2001:67c:d8:ed80::87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 187EE1A8868 for ; Mon, 5 Jan 2015 06:33:35 -0800 (PST) X-Halon-ID: d1ff165a-94e7-11e4-b286-000c299c41b4 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sverigesradio.se; s=sverigesradio; h=x-halon-id:received:received:received:from:to:cc:subject:thread-topic: thread-index:date:message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator:x-c2processedorg: content-type:content-transfer-encoding:mime-version; bh=yuZzn62X1i6+S9JziuA32/CV+9Swc3Hua2oUY/GwF5I=; b=hWC3ZYySSFuzk9vOQchZRn04+k77iIJ2DJ+HGAdl+oIVFqAkjs8Ob4yI0SBKy4UfRzjuzQram3GzT 1nuEeI3AT2awkHZiOwQVhHsEJtlJnMCEJNeAenq4TFnwtsayz/hCP2Ub2jKAwsNc3hltD+AJeqkmUY EV671TzRk8HY2EUI= Received: from RDCEX21.sr.se (unknown [134.25.170.82]) by mail-1.sr.se (Halon Mail Gateway) with ESMTPS; Mon, 5 Jan 2015 15:33:30 +0100 (CET) Received: from RDCEX21.sr.se (134.25.170.82) by RDCEX21.sr.se (134.25.170.82) with Microsoft SMTP Server (TLS) id 15.0.995.29; Mon, 5 Jan 2015 15:33:30 +0100 Received: from RDCEX21.sr.se ([fe80::cc2e:f081:5e77:d52e]) by RDCEX21.sr.se ([fe80::cc2e:f081:5e77:d52e%21]) with mapi id 15.00.0995.028; Mon, 5 Jan 2015 15:33:30 +0100 From: Fredrik Bergholtz To: "Victor Demjanenko, Ph.D." Thread-Topic: [payload] draft-ietf-payload-rtp-opus-05: maxaveragebitrate Thread-Index: AdATp89X++FTuPj7QpWp8hHcyPj53AB992kAA8ORFIAADAt6MQABiR0AAJTPRIAACqfAwwA7HwQAAATj/wAAAyDKAAAeNkwAAANCuC4= Date: Mon, 5 Jan 2015 14:33:29 +0000 Message-ID: References: <548A3FEA.2070400@mozilla.com> <7E6F2FBF-3E29-4608-A9AE-2C5124BCE261@sverigesradio.se> <26b91d07-8e22-4790-b06e-564ee30b071d@cisco.com> <006201d0273f$e708a230$b519e690$@co.in> <1CDC64C8-B130-4FB7-B73A-6F894CB729F0@sverigesradio.se> <54A99858.1030102@mozilla.com> <017401d02877$172e8b90$458ba2b0$@gmail.com>, <184801d028ef$eacb9650$c062c2f0$@Demjanenko@vocal.com> In-Reply-To: <184801d028ef$eacb9650$c062c2f0$@Demjanenko@vocal.com> Accept-Language: en-GB, sv-SE, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-c2processedorg: 17a716aa-7169-4253-8985-281a7037fe2e Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/MFtjxOSs3qe-6SE0AKQbiY9hNiM Cc: "payload@ietf.org" , Jean-Marc Valin Subject: Re: [payload] draft-ietf-payload-rtp-opus-05: maxaveragebitrate X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 14:33:42 -0000 I may be off base here but if multiple bit-rates of the same codec are to b= e 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 fmt= p-lines? Best regards Fredrik Bergholtz Swedish Radio > On 5 jan 2015, at 15:00, "Victor Demjanenko, Ph.D." wrote: >=20 > Hi, >=20 > 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 suppo= rt > a specific subset. (I know one device would only handle 2400 and 600 > because the tables for 1200bps are huge.) >=20 > We currently suggested the following for MELP SDP: >=20 > m=3Daudio 49120 RTP/AVP 97=20 > a=3Drtpmap:97 MELP/8000=20 > a=3Dfmtp:97 rate=3D2400,600,1200 >=20 > Should we be considering a different way to express the permitted/preferr= ed > rates? We are not trying to invent something new and unique. I believe = I > had seen this with one other recent speech coder. =20 >=20 > As an FYI, we have had a few reviewers external to the IETF process provi= de > 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. >=20 > Regards, >=20 > Victor Demjanenko >=20 >=20 > -----Original Message----- > From: payload [mailto:payload-bounces@ietf.org] 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: payload@ietf.org > Subject: Re: [payload] draft-ietf-payload-rtp-opus-05: maxaveragebitrate >=20 > Hi, > For audio/voice there are RFC5577 and RFC4749 that has a bitrate paramete= r > while RFC5404 uses the b=3D parameter >=20 >=20 >=20 > Roni Even > As individual >=20 >> -----Original Message----- >> From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Mo Zanaty >> (mzanaty) >> Sent: 05 January, 2015 12:06 AM >> To: Jean-Marc Valin; Fredrik Bergholtz; Parthasarathi R >> Cc: payload@ietf.org >> Subject: Re: [payload] draft-ietf-payload-rtp-opus-05:=20 >> maxaveragebitrate >>=20 >> 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). >>=20 >> Other notable codecs that lack this include VP8 and VP9. >>=20 >> This is a general problem which may become more important with complex=20 >> applications that include simulcast and scalable media within the same > media >> description (m=3D line). The SDP b=3D parameter is clearly insufficient= =20 >> for expressing multiple different maximum bitrates for each payload=20 >> type, > unless >> we define a new bandwidth modifier which includes explicit PT bindings. >> Payload formats that include fmtp parameters for maximum bitrate can=20 >> avoid this problem, so I think it is advisable to add this to Opus, >> VP8 and VP9. >>=20 >> Mo >>=20 >> On 1/4/15, 2:45 PM, Jean-Marc Valin wrote: >>=20 >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >>=20 >> Setting the bitrate isn't exactly a new problem here. Opus isn't the=20 >> first > codec >> to support more than one rate so how are the other codecs (audio and > video) >> handling bitrate signaling? >>=20 >> Cheers, >>=20 >> Jean-Marc >>=20 >>> On 03/01/15 09:32 AM, Fredrik Bergholtz wrote: >>> Hi. >>>=20 >>> One thought om the general media level bit rate specification is=20 >>> that it can never be anything other than an approximate value. >>> Different codecs define different constraints on the bit rate. I=20 >>> think that the easiest way to specify exact bit rates would be via=20 >>> the fmtp attribute. >>>=20 >>> This can be compared with the ptime attribute - as it is defined=20 >>> today, only approximate packet times can be signalled in SDP. For=20 >>> the broadcast use case this is not acceptable and for that reason,=20 >>> the European Broadcasting Union (EBU) has defined an SDP extension=20 >>> that allows signalling of a ptime value for each codec. There is no=20 >>> RFC draft for this extension and it is not yet registered with IANA=20 >>> or IETF but it is starting to be used by manufacturers of=20 >>> broadcasting equipment. The extension is known as "ACIP Profiles" >>> and can be found at the EBU web site. But I digress. >>>=20 >>> I don't think that forcing encoders to approximate the nearest=20 >>> allowed value for the selected codec is less complicated than=20 >>> interpreting an exact value. In addition, it would add a=20 >>> non-deterministic aspect, thus the resulting bit rate may not be what > the user expected. >>>=20 >>> Best regards Fredrik Bergholtz Swedish Radio >>>=20 >>> On 3 jan 2015, at 11:27, "Parthasarathi R" >>> > >>> wrote: >>>=20 >>>> Hi all, >>>>=20 >>>>=20 >>>>=20 >>>> I understand that bandwidth =B3b=B2 parameter has lot of variants lik= e=20 >>>> AS, TIAS and usage but all those parameters are media level and not=20 >>>> codec specific. The bandwidth allocation is going to be happen in=20 >>>> the media level in the network or end point based on the media=20 >>>> 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=20 >>>> specific bandwidth implementation complicates these bandwidth=20 >>>> calculation still further which is applicable to maxaveragebitrate=20 >>>> parameter in opus. >>>>=20 >>>>=20 >>>>=20 >>>> I could not understand why the generic parameter should not used or=20 >>>> generic parameter has to be enhanced which meets Opus requirement=20 >>>> rather than opus specific parameter. >>>>=20 >>>>=20 >>>>=20 >>>> Thanks >>>>=20 >>>> Partha >>>>=20 >>>>=20 >>>>=20 >>>> *From:*payload [mailto:payload-bounces@ietf.org] *On Behalf Of *Ali=20 >>>> C. Begen (abegen) *Sent:* Wednesday, December 31, 2014 4:57 PM=20 >>>> *To:* Fredrik Bergholtz *Cc:* payload@ietf.org=20 >>>> >>>> *Subject:* Re: [payload] >>>> draft-ietf-payload-rtp-opus-05: maxaveragebitrate >>>>=20 >>>>=20 >>>>=20 >>>> Authors >>>>=20 >>>> Please chime in and lets discuss s quick solution for this on the=20 >>>> list. Once agreed we can ship this draft. >>>>=20 >>>> -acbegen >>>>=20 >>>>=20 >>>>=20 >>>> *From:*Fredrik Bergholtz >>> > *Sent:* Dec 31, 2014 >>>> 11:42 AM *To:* Ali C. Begen (abegen) *Cc:* Jean-Marc Valin=20 >>>> >;Fredrik >>>> Bergholtz;payload@ietf.org *Subject:* >>>> Re: [payload] draft-ietf-payload-rtp-opus-05: maxaveragebitrate >>>>=20 >>>>=20 >>>>=20 >>>> Yes, I do see a strong need for specifying the bitrate. >>>>=20 >>>> In the broadcasting use case we have to make sure that we get the=20 >>>> best audio quality that is possible for the network that is=20 >>>> currently used but never try to send more data than the particular=20 >>>> link is capable of. For this reason, specifying a maximum bit rate=20 >>>> is required. >>>>=20 >>>> In addition we often have the requirement that the quality is=20 >>>> constant rather than the best possible. To avoid as many audible=20 >>>> changes in the audio as possible over time we will often use=20 >>>> constant bit rate and then it becomes even more important to be=20 >>>> able to specify what bit rate should be. >>>>=20 >>>> We will use the Opus codec over various network links with=20 >>>> different capabilities in terms of bit rate, delay variation,=20 >>>> absolute delay, etc and we will typically use the SDP to signal the=20 >>>> parameters that best fit both the current network and the current=20 >>>> type of radio production. >>>>=20 >>>> Best regards Fredrik Bergholtz Swedish Radio >>>>=20 >>>>=20 >>>>> On 31 dec 2014, at 05:57, "Ali C. Begen (abegen)" >>>>> > wrote: >>>>>=20 >>>>> My understanding is that the b=3D line in the SDP is quite a=20 >>>>> subjective parameter. I have seen people use it differently over=20 >>>>> the past several years. So, it is a bit difficult to infer much=20 >>>>> accuracy from that line. >>>>>=20 >>>>> OTOH, if someone feels like Opus needs to specify some sort of=20 >>>>> bitrate variability in the SDP, it can do so in an optional >>>>> (opus) parameter. Obviously rules around how to set that value and=20 >>>>> what to do with that value need to be clearly specified. >>>>>=20 >>>>> Fredrik (or anyone else in the WG), do you see a strong need for=20 >>>>> this? If so, now is the time to mention that. >>>>>=20 >>>>> -acbegen >>>>>=20 >>>>>=20 >>>>>> On Dec 12, 2014, at 3:07 AM, Jean-Marc Valin >>>>> > wrote: >>> I have to say this is not something I understand really well. Does=20 >>> anyone else here have an opinion on how to specify bit-rate? >>>=20 >>> Jean-Marc >>>=20 >>>>>>>> On 10/12/14 05:11 AM, Fredrik Bergholtz wrote: Hi. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> I read in the latest draft that you have removed the=20 >>>>>>>> maxaveragebitrate parameter from the SDP signalling for Opus. I=20 >>>>>>>> think that this parameter is useful and that it provides added=20 >>>>>>>> value over the bandwidth modifiers added by RFC 3556. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> I must admit that I haven=B9t read all of RFC 3556 but as I=20 >>>>>>>> understand it, a b=3D line are not in any way related to an=20 >>>>>>>> actual format of a media description. This means that with this=20 >>>>>>>> mechanism, only one bitrate specification can be sent with each=20 >>>>>>>> media description. Different coding algorithms have different=20 >>>>>>>> constraints on the allowed bitrate. For example, I might want=20 >>>>>>>> to send an SDP offer with both Enhanced apt-X at 576 kbit/s and=20 >>>>>>>> Opus at 510kbit/s with cbr. Now, specifying 576kbit/s via a b=3D=20 >>>>>>>> line works for apt-X but makes no sense for Opus and vice=20 >>>>>>>> versa. I think that the a=3Dfmtp line is the correct place to=20 >>>>>>>> specify the desired bitrate. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> For the broadcasting use-case, it is often more important to=20 >>>>>>>> have a constant and predictable audio quality and network usage=20 >>>>>>>> than mere audibility at any cost. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Best regards, >>>>>>>>=20 >>>>>>>> Fredrik Bergholtz >>>>>>>>=20 >>>>>>>> Swedish Radio >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ payload >> mailing >>>>>>>> list payload@ietf.org =20 >>>>>>>> https://www.ietf.org/mailman/listinfo/payload >>>>>>=20 >>>>>> _______________________________________________ payload >> mailing >>>>>> list payload@ietf.org =20 >>>>>> https://www.ietf.org/mailman/listinfo/payload >>>=20 >>>=20 >>> _______________________________________________ payload mailing list=20 >>> payload@ietf.org https://www.ietf.org/mailman/listinfo/payload >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1 >>=20 >> iQEcBAEBAgAGBQJUqZhTAAoJEJ6/8sItn9q9NaAH/jTELxrPUMSmhWHIODeGOrJ >> X >> 67evbcn5cIsZY/8+yyofMNbaFq7DCqdR3BKX9uJ/dUJ+4yR/nbyxvw/msjd65dkv >> YS3HVibycnMOnZkFENr7by6vvMaZn7mIjbOWukxdBePDKHhQq7ZPec++j8gWVp >> bR >> 6qy7BSMJle9TTH3nt/kzV8YbnP7Pt0iVUorMYH/JFUzHfwcPRROKlqmdgf8yAcIZ >> 3Dv659NuWqoUtUx7gm+DtLIZciR2io0rKElhWf9Y7pvnPw9ZjP/ztlWMaj+zlVeU >> WE9fjpEtBxWCqH2KooYAhKeS2wTbvNBXvMzIRojYDcFp50gYHhgih+heQ9yVdYg=3D >> =3DADn2 >> -----END PGP SIGNATURE----- >>=20 >> _______________________________________________ >> payload mailing list >> payload@ietf.org >> https://www.ietf.org/mailman/listinfo/payload >>=20 >> _______________________________________________ >> payload mailing list >> payload@ietf.org >> https://www.ietf.org/mailman/listinfo/payload >=20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload >=20 From nobody Mon Jan 5 06:54:54 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDD9E1A88D6 for ; Mon, 5 Jan 2015 06:54:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.3 X-Spam-Level: X-Spam-Status: No, score=0.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, MSGID_MULTIPLE_AT=1] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5J3EBTcFy8U for ; Mon, 5 Jan 2015 06:54:50 -0800 (PST) Received: from cuda.olm1.com (cuda.olm1.com [72.236.255.32]) by ietfa.amsl.com (Postfix) with ESMTP id 112201A88CA for ; Mon, 5 Jan 2015 06:54:50 -0800 (PST) X-ASG-Debug-ID: 1420469686-03d2503d4726a00001-U2jSCT Received: from host101.olm1.com (host101.olm1.com [72.236.255.11]) by cuda.olm1.com with ESMTP id QP0RyrvbGnn8FeE2; Mon, 05 Jan 2015 09:54:46 -0500 (EST) X-Barracuda-Envelope-From: Victor.Demjanenko@vocal.com X-Barracuda-Apparent-Source-IP: 72.236.255.11 Received: from host101.olm1.com (unknown [127.0.0.1]) by host101.olm1.com (Postfix) with ESMTP id 70A01697054D; Mon, 5 Jan 2015 09:54:46 -0500 (EST) Received: from dev1PC (unknown [72.43.202.98]) by host101.olm1.com (Postfix) with ESMTP; Mon, 5 Jan 2015 09:54:46 -0500 (EST) From: "Victor Demjanenko, Ph.D." To: "'Fredrik Bergholtz'" References: <548A3FEA.2070400@mozilla.com> <7E6F2FBF-3E29-4608-A9AE-2C5124BCE261@sverigesradio.se> <26b91d07-8e22-4790-b06e-564ee30b071d@cisco.com> <006201d0273f$e708a230$b519e690$@co.in> <1CDC64C8-B130-4FB7-B73A-6F894CB729F0@sverigesradio.se> <54A99858.1030102@mozilla.com> <017401d02877$172e8b90$458ba2b0$@gmail.com>, <184801d028ef$eacb9650$c062c2f0$@Demjanenko@vocal.com> In-Reply-To: Date: Mon, 5 Jan 2015 09:54:46 -0500 X-ASG-Orig-Subj: RE: [payload] draft-ietf-payload-rtp-opus-05: maxaveragebitrate Message-ID: <185201d028f7$8c8e17e0$a5aa47a0$@Demjanenko@vocal.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdATp89X++FTuPj7QpWp8hHcyPj53AB992kAA8ORFIAADAt6MQABiR0AAJTPRIAACqfAwwA7HwQAAATj/wAAAyDKAAAeNkwAAANCuC4AAJw0AA== Content-Language: en-us X-Barracuda-Connect: host101.olm1.com[72.236.255.11] X-Barracuda-Start-Time: 1420469686 X-Barracuda-URL: http://72.236.255.32:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at olm1.com X-Barracuda-Bayes: SPAM GLOBAL 0.9530 1.0000 3.8060 X-Barracuda-Spam-Score: 3.82 X-Barracuda-Spam-Status: No, SCORE=3.82 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=5.0 tests=BSF_SC0_MISMATCH_TO, MSGID_MULTIPLE_AT X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.13953 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 MSGID_MULTIPLE_AT Message-ID contains multiple '@' characters 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header Archived-At: http://mailarchive.ietf.org/arch/msg/payload/8t58R39I6LmCXeR5ED-cXmp3LMU Cc: payload@ietf.org, 'Jean-Marc Valin' Subject: Re: [payload] draft-ietf-payload-rtp-opus-05: maxaveragebitrate X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 14:54:53 -0000 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:fredrik.bergholtz@sverigesradio.se]=20 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; payload@ietf.org; 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 > On 5 jan 2015, at 15:00, "Victor Demjanenko, Ph.D." wrote: >=20 > Hi, >=20 > The set of permitted/preferred bit rate is also of interest for the=20 > MELP RTP payload. There are three permitted rates and some devices=20 > may only support a specific subset. (I know one device would only=20 > handle 2400 and 600 because the tables for 1200bps are huge.) >=20 > We currently suggested the following for MELP SDP: >=20 > m=3Daudio 49120 RTP/AVP 97=20 > a=3Drtpmap:97 MELP/8000=20 > a=3Dfmtp:97 rate=3D2400,600,1200 >=20 > Should we be considering a different way to express the=20 > permitted/preferred rates? We are not trying to invent something new=20 > and unique. I believe I had seen this with one other recent speech = coder. >=20 > As an FYI, we have had a few reviewers external to the IETF process=20 > provide comments. Unfortunately they have been out-of-band but they=20 > have been useful and supportive. We would like to have our proposal=20 > move forward towards an RFC in the next few months if possible. >=20 > Regards, >=20 > Victor Demjanenko >=20 >=20 > -----Original Message----- > From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Roni Even > Sent: Sunday, January 04, 2015 6:35 PM > To: 'Mo Zanaty (mzanaty)'; 'Jean-Marc Valin'; 'Fredrik Bergholtz';=20 > 'Parthasarathi R' > Cc: payload@ietf.org > Subject: Re: [payload] draft-ietf-payload-rtp-opus-05:=20 > maxaveragebitrate >=20 > Hi, > For audio/voice there are RFC5577 and RFC4749 that has a bitrate=20 > parameter while RFC5404 uses the b=3D parameter >=20 >=20 >=20 > Roni Even > As individual >=20 >> -----Original Message----- >> From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Mo=20 >> Zanaty >> (mzanaty) >> Sent: 05 January, 2015 12:06 AM >> To: Jean-Marc Valin; Fredrik Bergholtz; Parthasarathi R >> Cc: payload@ietf.org >> Subject: Re: [payload] draft-ietf-payload-rtp-opus-05:=20 >> maxaveragebitrate >>=20 >> 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). >>=20 >> Other notable codecs that lack this include VP8 and VP9. >>=20 >> This is a general problem which may become more important with=20 >> complex applications that include simulcast and scalable media within = >> the same > media >> description (m=3D line). The SDP b=3D parameter is clearly = insufficient=20 >> for expressing multiple different maximum bitrates for each payload=20 >> type, > unless >> we define a new bandwidth modifier which includes explicit PT = bindings. >> Payload formats that include fmtp parameters for maximum bitrate can=20 >> avoid this problem, so I think it is advisable to add this to Opus, >> VP8 and VP9. >>=20 >> Mo >>=20 >> On 1/4/15, 2:45 PM, Jean-Marc Valin wrote: >>=20 >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >>=20 >> Setting the bitrate isn't exactly a new problem here. Opus isn't the=20 >> first > codec >> to support more than one rate so how are the other codecs (audio and > video) >> handling bitrate signaling? >>=20 >> Cheers, >>=20 >> Jean-Marc >>=20 >>> On 03/01/15 09:32 AM, Fredrik Bergholtz wrote: >>> Hi. >>>=20 >>> One thought om the general media level bit rate specification is=20 >>> that it can never be anything other than an approximate value. >>> Different codecs define different constraints on the bit rate. I=20 >>> think that the easiest way to specify exact bit rates would be via=20 >>> the fmtp attribute. >>>=20 >>> This can be compared with the ptime attribute - as it is defined=20 >>> today, only approximate packet times can be signalled in SDP. For=20 >>> the broadcast use case this is not acceptable and for that reason,=20 >>> the European Broadcasting Union (EBU) has defined an SDP extension=20 >>> that allows signalling of a ptime value for each codec. There is no=20 >>> RFC draft for this extension and it is not yet registered with IANA=20 >>> or IETF but it is starting to be used by manufacturers of=20 >>> broadcasting equipment. The extension is known as "ACIP Profiles" >>> and can be found at the EBU web site. But I digress. >>>=20 >>> I don't think that forcing encoders to approximate the nearest=20 >>> allowed value for the selected codec is less complicated than=20 >>> interpreting an exact value. In addition, it would add a=20 >>> non-deterministic aspect, thus the resulting bit rate may not be=20 >>> what > the user expected. >>>=20 >>> Best regards Fredrik Bergholtz Swedish Radio >>>=20 >>> On 3 jan 2015, at 11:27, "Parthasarathi R" >>> > >>> wrote: >>>=20 >>>> Hi all, >>>>=20 >>>>=20 >>>>=20 >>>> I understand that bandwidth =B3b=B2 parameter has lot of variants = like=20 >>>> AS, TIAS and usage but all those parameters are media level and not = >>>> codec specific. The bandwidth allocation is going to be happen in=20 >>>> the media level in the network or end point based on the media=20 >>>> 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=20 >>>> calculation still further which is applicable to maxaveragebitrate=20 >>>> parameter in opus. >>>>=20 >>>>=20 >>>>=20 >>>> I could not understand why the generic parameter should not used or = >>>> generic parameter has to be enhanced which meets Opus requirement=20 >>>> rather than opus specific parameter. >>>>=20 >>>>=20 >>>>=20 >>>> Thanks >>>>=20 >>>> Partha >>>>=20 >>>>=20 >>>>=20 >>>> *From:*payload [mailto:payload-bounces@ietf.org] *On Behalf Of *Ali = >>>> C. Begen (abegen) *Sent:* Wednesday, December 31, 2014 4:57 PM >>>> *To:* Fredrik Bergholtz *Cc:* payload@ietf.org=20 >>>> >>>> *Subject:* Re: [payload] >>>> draft-ietf-payload-rtp-opus-05: maxaveragebitrate >>>>=20 >>>>=20 >>>>=20 >>>> Authors >>>>=20 >>>> Please chime in and lets discuss s quick solution for this on the=20 >>>> list. Once agreed we can ship this draft. >>>>=20 >>>> -acbegen >>>>=20 >>>>=20 >>>>=20 >>>> *From:*Fredrik Bergholtz >>> > *Sent:* Dec 31, 2014 >>>> 11:42 AM *To:* Ali C. Begen (abegen) *Cc:* Jean-Marc Valin=20 >>>> >;Fredrik >>>> Bergholtz;payload@ietf.org *Subject:* >>>> Re: [payload] draft-ietf-payload-rtp-opus-05: maxaveragebitrate >>>>=20 >>>>=20 >>>>=20 >>>> Yes, I do see a strong need for specifying the bitrate. >>>>=20 >>>> In the broadcasting use case we have to make sure that we get the=20 >>>> best audio quality that is possible for the network that is=20 >>>> currently used but never try to send more data than the particular=20 >>>> link is capable of. For this reason, specifying a maximum bit rate=20 >>>> is required. >>>>=20 >>>> In addition we often have the requirement that the quality is=20 >>>> constant rather than the best possible. To avoid as many audible=20 >>>> changes in the audio as possible over time we will often use=20 >>>> constant bit rate and then it becomes even more important to be=20 >>>> able to specify what bit rate should be. >>>>=20 >>>> We will use the Opus codec over various network links with=20 >>>> different capabilities in terms of bit rate, delay variation,=20 >>>> absolute delay, etc and we will typically use the SDP to signal the = >>>> parameters that best fit both the current network and the current=20 >>>> type of radio production. >>>>=20 >>>> Best regards Fredrik Bergholtz Swedish Radio >>>>=20 >>>>=20 >>>>> On 31 dec 2014, at 05:57, "Ali C. Begen (abegen)" >>>>> > wrote: >>>>>=20 >>>>> My understanding is that the b=3D line in the SDP is quite a=20 >>>>> subjective parameter. I have seen people use it differently over=20 >>>>> the past several years. So, it is a bit difficult to infer much=20 >>>>> accuracy from that line. >>>>>=20 >>>>> OTOH, if someone feels like Opus needs to specify some sort of=20 >>>>> 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. >>>>>=20 >>>>> Fredrik (or anyone else in the WG), do you see a strong need for=20 >>>>> this? If so, now is the time to mention that. >>>>>=20 >>>>> -acbegen >>>>>=20 >>>>>=20 >>>>>> On Dec 12, 2014, at 3:07 AM, Jean-Marc Valin >>>>> > wrote: >>> I have to say this is not something I understand really well. Does=20 >>> anyone else here have an opinion on how to specify bit-rate? >>>=20 >>> Jean-Marc >>>=20 >>>>>>>> On 10/12/14 05:11 AM, Fredrik Bergholtz wrote: Hi. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> I read in the latest draft that you have removed the=20 >>>>>>>> maxaveragebitrate parameter from the SDP signalling for Opus. I = >>>>>>>> think that this parameter is useful and that it provides added=20 >>>>>>>> value over the bandwidth modifiers added by RFC 3556. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> I must admit that I haven=B9t read all of RFC 3556 but as I=20 >>>>>>>> understand it, a b=3D line are not in any way related to an=20 >>>>>>>> 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=20 >>>>>>>> constraints on the allowed bitrate. For example, I might want=20 >>>>>>>> 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=3D=20 >>>>>>>> line works for apt-X but makes no sense for Opus and vice=20 >>>>>>>> versa. I think that the a=3Dfmtp line is the correct place to=20 >>>>>>>> specify the desired bitrate. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> For the broadcasting use-case, it is often more important to=20 >>>>>>>> have a constant and predictable audio quality and network usage = >>>>>>>> than mere audibility at any cost. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Best regards, >>>>>>>>=20 >>>>>>>> Fredrik Bergholtz >>>>>>>>=20 >>>>>>>> Swedish Radio >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ payload >> mailing >>>>>>>> list payload@ietf.org =20 >>>>>>>> https://www.ietf.org/mailman/listinfo/payload >>>>>>=20 >>>>>> _______________________________________________ payload >> mailing >>>>>> list payload@ietf.org =20 >>>>>> https://www.ietf.org/mailman/listinfo/payload >>>=20 >>>=20 >>> _______________________________________________ payload mailing list = >>> payload@ietf.org https://www.ietf.org/mailman/listinfo/payload >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1 >>=20 >> iQEcBAEBAgAGBQJUqZhTAAoJEJ6/8sItn9q9NaAH/jTELxrPUMSmhWHIODeGOrJ >> X >> 67evbcn5cIsZY/8+yyofMNbaFq7DCqdR3BKX9uJ/dUJ+4yR/nbyxvw/msjd65dkv >> YS3HVibycnMOnZkFENr7by6vvMaZn7mIjbOWukxdBePDKHhQq7ZPec++j8gWVp >> bR >> 6qy7BSMJle9TTH3nt/kzV8YbnP7Pt0iVUorMYH/JFUzHfwcPRROKlqmdgf8yAcIZ >> 3Dv659NuWqoUtUx7gm+DtLIZciR2io0rKElhWf9Y7pvnPw9ZjP/ztlWMaj+zlVeU >> WE9fjpEtBxWCqH2KooYAhKeS2wTbvNBXvMzIRojYDcFp50gYHhgih+heQ9yVdYg=3D >> =3DADn2 >> -----END PGP SIGNATURE----- >>=20 >> _______________________________________________ >> payload mailing list >> payload@ietf.org >> https://www.ietf.org/mailman/listinfo/payload >>=20 >> _______________________________________________ >> payload mailing list >> payload@ietf.org >> https://www.ietf.org/mailman/listinfo/payload >=20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload >=20 From nobody Mon Jan 5 09:47:57 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7912C1A871D for ; Mon, 5 Jan 2015 09:47:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UKy7203NO7yq for ; Mon, 5 Jan 2015 09:47:52 -0800 (PST) Received: from mail-qg0-f49.google.com (mail-qg0-f49.google.com [209.85.192.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 423E71A0041 for ; Mon, 5 Jan 2015 09:47:52 -0800 (PST) Received: by mail-qg0-f49.google.com with SMTP id f51so2495863qge.8 for ; Mon, 05 Jan 2015 09:47:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ocMgzwjpV9wgxgXLw4jojKel9vKoEeM9a8BU8v3YwNU=; b=PBJqijegJjnLjxbcM+eOTuBWve1t6sVAoOv6PADj1+JyJNcknInTknVntZmG5Bk4Wi qH8emfjyy5U853EbUIeR5Zkgye+K2l+1o1RVPDw9z+/b4N3Y6T5WRPwqJv7CpAqdNqe3 QLbUkejO1U3d2HU+SNsmbDM8KgGcvnQYcTJuSxknCxlVtLRS89lMBS92HBI6+/UxEdVs /0jrrNR5V6XR4igyRtVxT7MLmuFFGHAfLMnybGvMGsC0XfAQdnLG0CHWJn/Qio3v0pa7 CD4olRMpADekVacnBQMTeTopdb4QEiypqgt/71EkGXeqmH6Q+WzTh+4ldv/bMi13eY1G znQw== X-Gm-Message-State: ALoCoQlJs4BhOGYF5pD3KhYRdZrqpLKGLfKvlfo1FsLg18l8hN2aubYzmGxQstBI5hoQJ/dhNluB X-Received: by 10.140.19.139 with SMTP id 11mr91783290qgh.14.1420480071296; Mon, 05 Jan 2015 09:47:51 -0800 (PST) Received: from panoramix.jmvalin.ca (modemcable074.170-201-24.mc.videotron.ca. [24.201.170.74]) by mx.google.com with ESMTPSA id 4sm33765994qgh.22.2015.01.05.09.47.50 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Jan 2015 09:47:50 -0800 (PST) From: Jean-Marc Valin X-Google-Original-From: Jean-Marc Valin Message-ID: <54AACE45.2090100@mozilla.com> Date: Mon, 05 Jan 2015 12:47:49 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Victor Demjanenko, Ph.D." , 'Fredrik Bergholtz' References: <548A3FEA.2070400@mozilla.com> <7E6F2FBF-3E29-4608-A9AE-2C5124BCE261@sverigesradio.se> <26b91d07-8e22-4790-b06e-564ee30b071d@cisco.com> <006201d0273f$e708a230$b519e690$@co.in> <1CDC64C8-B130-4FB7-B73A-6F894CB729F0@sverigesradio.se> <54A99858.1030102@mozilla.com> <017401d02877$172e8b90$458ba2b0$@gmail.com>, <184801d028ef$eacb9650$c062c2f0$@Demjanenko@vocal.com> <54aaa5c0.83f2440a.5fff.ffffd3a3SMTPIN_ADDED_BROKEN@mx.google.com> In-Reply-To: <54aaa5c0.83f2440a.5fff.ffffd3a3SMTPIN_ADDED_BROKEN@mx.google.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/payload/cYDyBxn6mClIgE5EB1_dR_np8jU Cc: 'Jean-Marc Valin' , payload@ietf.org Subject: Re: [payload] draft-ietf-payload-rtp-opus-05: maxaveragebitrate X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 17:47:55 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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:fredrik.bergholtz@sverigesradio.se] 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; payload@ietf.org; 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 > >> On 5 jan 2015, at 15:00, "Victor Demjanenko, Ph.D." > wrote: >> >> 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:payload-bounces@ietf.org] 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: >> payload@ietf.org Subject: Re: [payload] >> draft-ietf-payload-rtp-opus-05: maxaveragebitrate >> >> 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:payload-bounces@ietf.org] On Behalf Of Mo Zanaty >>> (mzanaty) Sent: 05 January, 2015 12:06 AM To: Jean-Marc Valin; >>> Fredrik Bergholtz; Parthasarathi R Cc: payload@ietf.org >>> Subject: Re: [payload] draft-ietf-payload-rtp-opus-05: >>> maxaveragebitrate >>> >>> 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 >>> wrote: >>> > 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" >>>>> >>>> > 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:payload-bounces@ietf.org] *On >>>>>> Behalf Of *Ali C. Begen (abegen) *Sent:* Wednesday, >>>>>> December 31, 2014 4:57 PM *To:* Fredrik Bergholtz *Cc:* >>>>>> payload@ietf.org *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 >>>>>> >>>>> > *Sent:* Dec >>>>>> 31, 2014 11:42 AM *To:* Ali C. Begen (abegen) *Cc:* >>>>>> Jean-Marc Valin >>>>> >;Fredrik >>>>>> Bergholtz;payload@ietf.org >>>>>> *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)" >>>>>>> > 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 >>>>>>>> > >>>>>>>> wrote: >>>>> 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 payload@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/payload >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> payload > mailing >>>>>>>> list payload@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/payload >>>>> >>>>> >>>>> _______________________________________________ payload >>>>> mailing list payload@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/payload >>> >>> _______________________________________________ payload mailing >>> list payload@ietf.org >>> https://www.ietf.org/mailman/listinfo/payload >>> >>> _______________________________________________ payload mailing >>> list payload@ietf.org >>> https://www.ietf.org/mailman/listinfo/payload >> >> _______________________________________________ payload mailing >> list payload@ietf.org >> https://www.ietf.org/mailman/listinfo/payload >> > > _______________________________________________ payload mailing > list payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUqs4/AAoJEJ6/8sItn9q9ZAAH/12Fjooqux3X47vdrspOFoVh cw84fG2iR+Npuz89tYIYzOR13L+pCUoKJzQoPS8Dc9l3xf/t+0sDqQU4FPG2yVST y2b1R3bMjh3JFj8GOH3O24QqzD/CkV+IFE8DmbEJ2+eFUuckjiVEzSjtOiq6toBv T+NS9IRg4AuQ4JMUGPlCiTQBCYG9f/XuulFPFRoBCcjB2N0TFwMUBgIm/6K0GChW NQicAhbKOxQxM0y8O9Pxj1jimriopPX3jqhFmmZ/uyULefCJO+d20pb/tidvyJLK byuBMFFslkt/m51h2wPzmY81VybczoaHqrWFPn+qDX+r4NnKxZN5EIQx6H2OLlc= =B1NF -----END PGP SIGNATURE----- From nobody Mon Jan 5 23:35:10 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DDD71A9113; Mon, 5 Jan 2015 23:35:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id azpg4d9OE4uJ; Mon, 5 Jan 2015 23:35:07 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6CF1A1BFC; Mon, 5 Jan 2015 23:35:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150106073507.14546.83652.idtracker@ietfa.amsl.com> Date: Mon, 05 Jan 2015 23:35:07 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/Lj-Z3xl-lwYgrQsNkhDARn2nwMA Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-opus-06.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 07:35:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Payloads Working Group of the IETF. Title : RTP Payload Format for Opus Speech and Audio Codec Authors : Julian Spittka Koen Vos Jean-Marc Valin Filename : draft-ietf-payload-rtp-opus-06.txt Pages : 17 Date : 2015-01-05 Abstract: This document defines the Real-time Transport Protocol (RTP) payload format for packetization of Opus encoded speech and audio data necessary to integrate the codec in the most compatible way. Further, it describes media type registrations for the RTP payload format. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-opus/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-payload-rtp-opus-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-payload-rtp-opus-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jan 5 23:38:43 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40CFF1A6FEA for ; Mon, 5 Jan 2015 23:38:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Bo1QzGI3URI for ; Mon, 5 Jan 2015 23:38:36 -0800 (PST) Received: from mail-qc0-f169.google.com (mail-qc0-f169.google.com [209.85.216.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B3191A1A46 for ; Mon, 5 Jan 2015 23:38:36 -0800 (PST) Received: by mail-qc0-f169.google.com with SMTP id w7so16633259qcr.14 for ; Mon, 05 Jan 2015 23:38:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=iQfr3gMdWkyN2W8rzXkR0XVXoAw7VPFi9Ziogxoo3W4=; b=NQzp/Z5VbA1PA1QRrblxlU7aufKBUp5Q5TREIadxGS2ClczWxA284f3JB1gfBtq5Xd dUCvYaBFcnnhsGAM7yFIRkfWbUy74UU4b6Etxybztmgj0vDdjgerwvFiVRxFQMdK4Fti e/YIl4I4FarXWLU2u4Sz7rx1FaFkzk7scjPV6jamafwxqSnN5mfm4y/1g/dOneN9wiwT 0nshCWob3YN9JEo9gz80+MbDhF7g+La7gjEFlyI/rtL0WErGucjPWchzNUR9NRYXRAjD LGETzvMnd2ogQttAqaHwDDWzONXHzPRKPPzUH+ruXBwiFYGcYshPkhsEM4EUz45bTYzE NIdA== X-Gm-Message-State: ALoCoQnWDItyb91ecAr3VEzuW3/Jewf5+uoXuA4ZB32c2YAXBPJg3KYf4oDBzDdNo7zn40QOazsM X-Received: by 10.224.160.212 with SMTP id o20mr153450389qax.57.1420529915824; Mon, 05 Jan 2015 23:38:35 -0800 (PST) Received: from panoramix.jmvalin.ca (modemcable074.170-201-24.mc.videotron.ca. [24.201.170.74]) by mx.google.com with ESMTPSA id j9sm20293944qgj.46.2015.01.05.23.38.35 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Jan 2015 23:38:35 -0800 (PST) From: Jean-Marc Valin X-Google-Original-From: Jean-Marc Valin Message-ID: <54AB90FA.6090900@mozilla.com> Date: Tue, 06 Jan 2015 02:38:34 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Fredrik Bergholtz References: <548A3FEA.2070400@mozilla.com> <7E6F2FBF-3E29-4608-A9AE-2C5124BCE261@sverigesradio.se> <26b91d07-8e22-4790-b06e-564ee30b071d@cisco.com> <006201d0273f$e708a230$b519e690$@co.in> <1CDC64C8-B130-4FB7-B73A-6F894CB729F0@sverigesradio.se> <54A99858.1030102@mozilla.com> , <54A9C9D0.8050002@mozilla.com> <06DA8517-E9D8-4726-8FAE-EB7D4B110674@sverigesradio.se> In-Reply-To: <06DA8517-E9D8-4726-8FAE-EB7D4B110674@sverigesradio.se> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/payload/dtfNWbeIIIfHx960gjnVQC2Sexs Cc: "payload@ietf.org" Subject: Re: [payload] draft-ietf-payload-rtp-opus-05: maxaveragebitrate X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 07:38:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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: > I think that re-instating maxaveragebitrate would do it for me. > > /Fredrik > > >> On 5 jan 2015, at 00:16, "Jean-Marc Valin" >> 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). >>>> >>>> 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 >>>> wrote: >>>> >>>> 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" >>>>> >>>> > 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:payload-bounces@ietf.org] *On >>>>>> Behalf Of *Ali C. Begen (abegen) *Sent:* Wednesday, >>>>>> December 31, 2014 4:57 PM *To:* Fredrik Bergholtz *Cc:* >>>>>> payload@ietf.org *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 >>>>>> >>>>> > *Sent:* Dec >>>>>> 31, 2014 11:42 AM *To:* Ali C. Begen (abegen) *Cc:* >>>>>> Jean-Marc Valin >>>>> >;Fredrik >>>>>> Bergholtz;payload@ietf.org >>>>>> *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)" >>>>>>> > 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 >>>>>>>> > >>>>>>>> wrote: >>>>> 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 payload@ietf.org >>>>>>>>>> >>>>>>>>>> https://www.ietf.org/mailman/listinfo/payload >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> payload mailing list payload@ietf.org >>>>>>>> >>>>>>>> https://www.ietf.org/mailman/listinfo/payload >>>> >>>> >>>>> _______________________________________________ payload >>>>> mailing list payload@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/payload >>>> >>>> >>>> _______________________________________________ payload >>>> mailing list payload@ietf.org >>>> https://www.ietf.org/mailman/listinfo/payload >>>> >>>> _______________________________________________ payload >>>> mailing list payload@ietf.org >>>> https://www.ietf.org/mailman/listinfo/payload > > _______________________________________________ payload mailing > list payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUq5D3AAoJEJ6/8sItn9q9+XkH/27U71MfStYlp2WXoaiW9SmP YSpGdAbDipfnJ+7RZQ0bDf0GCRtxGxyVcAqsj9oYTFQAyMd67eRp88fzY0pRODVf VjgWm4VLzP7jbfemzxaZXMzO/MqoiMssIvmnDB2FCirZl03aZ0vcskRAqi/OXlCm hVJUWkf8MqxMJ1TKqbLn+WGlWHRk89wsyxYQkbfKTfQHVPmnno8eXGvDt71Gewi1 NYyycLisXOAAtvifE+OSGvE0PPw9GcxUgysV/fTRyzEsZV9KVzVQTa4Jj1x6ff8W 74ylYwYko5t93sRaEsQACVGjGYyXN/FfhpYZJNQ5S6j8gVrPc3Y5ZeFegx2jTEg= =fe42 -----END PGP SIGNATURE----- From nobody Tue Jan 6 01:38:13 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 100301A1F01 for ; Tue, 6 Jan 2015 01:38:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.351 X-Spam-Level: X-Spam-Status: No, score=-3.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6XIMebjt9orO for ; Tue, 6 Jan 2015 01:38:08 -0800 (PST) Received: from mail-3.sr.se (mail-3.sr.se [192.165.8.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 678C61A1EEA for ; Tue, 6 Jan 2015 01:38:06 -0800 (PST) X-Halon-ID: b4a1c255-9587-11e4-b5a7-000c2976599e DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sverigesradio.se; s=sverigesradio; h=x-halon-id:received:received:received:from:to:cc:subject:thread-topic: thread-index:date:message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator:x-c2processedorg: content-type:content-transfer-encoding:mime-version; bh=qIc9JecCHkNHA8sO7Dq7cErTTnDcv4cKEvcQHkynev8=; b=HM79eAUb6VTjzUSL0Ghbjc0YGbzDbT+KDxOOIBKbv8YrNM593jdKtvwAAz4Brig+NQxk3FobP54A7 UVOpvCeCxXkoQta6APWY7sx/eZHS7PbgtFqVD65RBDCiVMT+pmsOC0F+bkkntcSLr4kepfqlTeF/2A z6s20wkvHahMmHC0= Received: from RDCEX21.sr.se (unknown [134.25.170.82]) by mail-3.sr.se (Halon Mail Gateway) with ESMTPS; Tue, 6 Jan 2015 10:38:01 +0100 (CET) Received: from RDCEX21.sr.se (134.25.170.82) by RDCEX21.sr.se (134.25.170.82) with Microsoft SMTP Server (TLS) id 15.0.995.29; Tue, 6 Jan 2015 10:38:00 +0100 Received: from RDCEX21.sr.se ([fe80::cc2e:f081:5e77:d52e]) by RDCEX21.sr.se ([fe80::cc2e:f081:5e77:d52e%21]) with mapi id 15.00.0995.028; Tue, 6 Jan 2015 10:38:00 +0100 From: Fredrik Bergholtz To: Jean-Marc Valin Thread-Topic: [payload] draft-ietf-payload-rtp-opus-05: maxaveragebitrate Thread-Index: AdATp89X++FTuPj7QpWp8hHcyPj53AB992kAA8ORFIAADAt6MQABiR0AAJTPRIAACqfAwwA7HwQAAATj/wAAAnsWAAAZtePNACodPwAABkRKVg== Date: Tue, 6 Jan 2015 09:38:00 +0000 Message-ID: <2BC0E0E8-67BC-45B8-93E1-71CBDC9AEA60@sverigesradio.se> References: <548A3FEA.2070400@mozilla.com> <7E6F2FBF-3E29-4608-A9AE-2C5124BCE261@sverigesradio.se> <26b91d07-8e22-4790-b06e-564ee30b071d@cisco.com> <006201d0273f$e708a230$b519e690$@co.in> <1CDC64C8-B130-4FB7-B73A-6F894CB729F0@sverigesradio.se> <54A99858.1030102@mozilla.com> ,<54A9C9D0.8050002@mozilla.com> <06DA8517-E9D8-4726-8FAE-EB7D4B110674@sverigesradio.se>, <54AB90FA.6090900@mozilla.com> In-Reply-To: <54AB90FA.6090900@mozilla.com> Accept-Language: en-GB, sv-SE, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-c2processedorg: 17a716aa-7169-4253-8985-281a7037fe2e Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/t5tfnuiUvmlVjZ4Yt42yr96EEl8 Cc: "payload@ietf.org" Subject: Re: [payload] draft-ietf-payload-rtp-opus-05: maxaveragebitrate X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 09:38:12 -0000 Excellent. Thanks! /Fredrik > On 6 jan 2015, at 08:38, "Jean-Marc Valin" wrote: >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Just posted a new version that brings back maxaveragebitrate exactly > as it was before. >=20 > Cheers, >=20 > Jean-Marc >=20 >> On 05/01/15 05:32 AM, Fredrik Bergholtz wrote: >> I think that re-instating maxaveragebitrate would do it for me. >>=20 >> /Fredrik >>=20 >>=20 >>> On 5 jan 2015, at 00:16, "Jean-Marc Valin" >>> wrote: >> So would everyone be happy if I just revert to using >> maxaveragebitrate as in draft 04? >>=20 >> Jean-Marc >>=20 >>=20 >>>>> 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;=20 >>>>> config in AAC). >>>>>=20 >>>>> Other notable codecs that lack this include VP8 and VP9. >>>>>=20 >>>>> 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=3D line). The SDP b=3D >>>>> 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. >>>>>=20 >>>>> Mo >>>>>=20 >>>>> On 1/4/15, 2:45 PM, Jean-Marc Valin >>>>> wrote: >>>>>=20 >>>>> 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? >>>>>=20 >>>>> Cheers, >>>>>=20 >>>>> Jean-Marc >>>>>=20 >>>>>> On 03/01/15 09:32 AM, Fredrik Bergholtz wrote: Hi. >>>>>=20 >>>>>> 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. >>>>>=20 >>>>>> 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=20 >>>>>> digress. >>>>>=20 >>>>>> 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. >>>>>=20 >>>>>> Best regards Fredrik Bergholtz Swedish Radio >>>>>=20 >>>>>> On 3 jan 2015, at 11:27, "Parthasarathi R"=20 >>>>>> >>>>> > wrote: >>>>>=20 >>>>>>> Hi all, >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> I understand that bandwidth =B3b=B2 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. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Thanks >>>>>>>=20 >>>>>>> Partha >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> *From:*payload [mailto:payload-bounces@ietf.org] *On >>>>>>> Behalf Of *Ali C. Begen (abegen) *Sent:* Wednesday, >>>>>>> December 31, 2014 4:57 PM *To:* Fredrik Bergholtz *Cc:* >>>>>>> payload@ietf.org *Subject:* Re: >>>>>>> [payload] draft-ietf-payload-rtp-opus-05: >>>>>>> maxaveragebitrate >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Authors >>>>>>>=20 >>>>>>> Please chime in and lets discuss s quick solution for >>>>>>> this on the list. Once agreed we can ship this draft. >>>>>>>=20 >>>>>>> -acbegen >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> *From:*Fredrik Bergholtz >>>>>>> >>>>>> > *Sent:* Dec >>>>>>> 31, 2014 11:42 AM *To:* Ali C. Begen (abegen) *Cc:* >>>>>>> Jean-Marc Valin >>>>>> >;Fredrik=20 >>>>>>> Bergholtz;payload@ietf.org =20 >>>>>>> *Subject:* Re: [payload] draft-ietf-payload-rtp-opus-05:=20 >>>>>>> maxaveragebitrate >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Yes, I do see a strong need for specifying the bitrate. >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> Best regards Fredrik Bergholtz Swedish Radio >>>>>>>=20 >>>>>>>=20 >>>>>>>> On 31 dec 2014, at 05:57, "Ali C. Begen (abegen)"=20 >>>>>>>> > wrote: >>>>>>>>=20 >>>>>>>> My understanding is that the b=3D 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. >>>>>>>>=20 >>>>>>>> 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. >>>>>>>>=20 >>>>>>>> Fredrik (or anyone else in the WG), do you see a strong >>>>>>>> need for this? If so, now is the time to mention that. >>>>>>>>=20 >>>>>>>> -acbegen >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> On Dec 12, 2014, at 3:07 AM, Jean-Marc Valin=20 >>>>>>>>> > >>>>>>>>> wrote: >>>>>> 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? >>>>>=20 >>>>>> Jean-Marc >>>>>=20 >>>>>>>>>>> On 10/12/14 05:11 AM, Fredrik Bergholtz wrote: >>>>>>>>>>> Hi. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> 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. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> I must admit that I haven=B9t read all of RFC 3556 >>>>>>>>>>> but as I understand it, a b=3D 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=20 >>>>>>>>>>> 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=3D line works for >>>>>>>>>>> apt-X but makes no sense for Opus and vice versa. >>>>>>>>>>> I think that the a=3Dfmtp line is the correct place >>>>>>>>>>> to specify the desired bitrate. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> For the broadcasting use-case, it is often more=20 >>>>>>>>>>> important to have a constant and predictable >>>>>>>>>>> audio quality and network usage than mere >>>>>>>>>>> audibility at any cost. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Best regards, >>>>>>>>>>>=20 >>>>>>>>>>> Fredrik Bergholtz >>>>>>>>>>>=20 >>>>>>>>>>> Swedish Radio >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________=20 >>>>>>>>>>> payload mailing list payload@ietf.org=20 >>>>>>>>>>> =20 >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/payload >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> payload mailing list payload@ietf.org >>>>>>>>> =20 >>>>>>>>> https://www.ietf.org/mailman/listinfo/payload >>>>>=20 >>>>>=20 >>>>>> _______________________________________________ payload >>>>>> mailing list payload@ietf.org=20 >>>>>> https://www.ietf.org/mailman/listinfo/payload >>>>>=20 >>>>>=20 >>>>> _______________________________________________ payload >>>>> mailing list payload@ietf.org=20 >>>>> https://www.ietf.org/mailman/listinfo/payload >>>>>=20 >>>>> _______________________________________________ payload >>>>> mailing list payload@ietf.org=20 >>>>> https://www.ietf.org/mailman/listinfo/payload >>=20 >> _______________________________________________ payload mailing >> list payload@ietf.org=20 >> https://www.ietf.org/mailman/listinfo/payload > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 >=20 > iQEcBAEBAgAGBQJUq5D3AAoJEJ6/8sItn9q9+XkH/27U71MfStYlp2WXoaiW9SmP > YSpGdAbDipfnJ+7RZQ0bDf0GCRtxGxyVcAqsj9oYTFQAyMd67eRp88fzY0pRODVf > VjgWm4VLzP7jbfemzxaZXMzO/MqoiMssIvmnDB2FCirZl03aZ0vcskRAqi/OXlCm > hVJUWkf8MqxMJ1TKqbLn+WGlWHRk89wsyxYQkbfKTfQHVPmnno8eXGvDt71Gewi1 > NYyycLisXOAAtvifE+OSGvE0PPw9GcxUgysV/fTRyzEsZV9KVzVQTa4Jj1x6ff8W > 74ylYwYko5t93sRaEsQACVGjGYyXN/FfhpYZJNQ5S6j8gVrPc3Y5ZeFegx2jTEg=3D > =3Dfe42 > -----END PGP SIGNATURE----- From nobody Tue Jan 6 09:48:44 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24B221A0122 for ; Tue, 6 Jan 2015 09:48:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.621 X-Spam-Level: X-Spam-Status: No, score=-0.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_14=0.6, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TWu7FjYuIKIG for ; Tue, 6 Jan 2015 09:48:40 -0800 (PST) Received: from outbound.mailhostbox.com (outbound.mailhostbox.com [162.222.225.19]) by ietfa.amsl.com (Postfix) with ESMTP id BCCDB1A1A31 for ; Tue, 6 Jan 2015 09:48:39 -0800 (PST) Received: from userPC (unknown [122.178.249.70]) (Authenticated sender: partha@parthasarathi.co.in) by outbound.mailhostbox.com (Postfix) with ESMTPA id 30B39639ABC; Tue, 6 Jan 2015 17:48:31 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1420566516; bh=SBAErp23u5j5ykvnEF4IniIINeNPSO6Q87POsmm5hwk=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=I6U4KlSMj/Rdaa+xJfYjRxAOm8iFbBDhanbdTDen9em+D33QS/1cHN0f/vNuEsw1P 83BGNFmBOtIk3Uwwu9URM7sS+jZYVsb7r29wy3EFvu0eREHvpLRoK1og2a/Pde/YA2 c+M7bZnnH40blwC7p8sgTnvwn2ETprjAAZNe/vXg= From: "Parthasarathi R" To: "'Jean-Marc Valin'" , "'Fredrik Bergholtz'" References: <548A3FEA.2070400@mozilla.com> <7E6F2FBF-3E29-4608-A9AE-2C5124BCE261@sverigesradio.se> <26b91d07-8e22-4790-b06e-564ee30b071d@cisco.com> <006201d0273f$e708a230$b519e690$@co.in> <1CDC64C8-B130-4FB7-B73A-6F894CB729F0@sverigesradio.se> <54A99858.1030102@mozilla.com> , <54A9C9D0.8050002@mozilla.com> <06DA8517-E9D8-4726-8FAE-EB7D4B110674@sverigesradio.se> <54AB90FA.6090900@mozilla.com> In-Reply-To: <54AB90FA.6090900@mozilla.com> Date: Tue, 6 Jan 2015 23:18:26 +0530 Message-ID: <002d01d029d8$fd0eba60$f72c2f20$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdApg8/yrVPArByMQLa5kIgBCh/5zQAUqv7Q Content-Language: en-us X-CTCH-RefID: str=0001.0A020201.54AC2031.009A, ss=1, re=0.001, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.001 X-CTCH-Rules: C_4847, X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/M-NUR2xrMuJZO5CT0D6Fw57sQXU Cc: payload@ietf.org Subject: Re: [payload] draft-ietf-payload-rtp-opus-05: maxaveragebitrate X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 17:48:43 -0000 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=20 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.=20 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.=20 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 > -----Original Message----- > From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Jean-Marc > Valin > Sent: Tuesday, January 06, 2015 1:09 PM > To: Fredrik Bergholtz > Cc: payload@ietf.org > Subject: Re: [payload] draft-ietf-payload-rtp-opus-05: > maxaveragebitrate >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Just posted a new version that brings back maxaveragebitrate exactly > as it was before. >=20 > Cheers, >=20 > Jean-Marc >=20 > On 05/01/15 05:32 AM, Fredrik Bergholtz wrote: > > I think that re-instating maxaveragebitrate would do it for me. > > > > /Fredrik > > > > > >> On 5 jan 2015, at 00:16, "Jean-Marc Valin" > >> 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). > >>>> > >>>> 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=3D line). The SDP b=3D > >>>> 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 > >>>> wrote: > >>>> > >>>> 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" > >>>>> >>>>> > wrote: > >>>> > >>>>>> Hi all, > >>>>>> > >>>>>> > >>>>>> > >>>>>> I understand that bandwidth =B3b=B2 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:payload-bounces@ietf.org] *On > >>>>>> Behalf Of *Ali C. Begen (abegen) *Sent:* Wednesday, > >>>>>> December 31, 2014 4:57 PM *To:* Fredrik Bergholtz *Cc:* > >>>>>> payload@ietf.org *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 > >>>>>> >>>>>> > *Sent:* Dec > >>>>>> 31, 2014 11:42 AM *To:* Ali C. Begen (abegen) *Cc:* > >>>>>> Jean-Marc Valin >>>>>> >;Fredrik > >>>>>> Bergholtz;payload@ietf.org > >>>>>> *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)" > >>>>>>> > wrote: > >>>>>>> > >>>>>>> My understanding is that the b=3D 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 > >>>>>>>> > > >>>>>>>> wrote: > >>>>> 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=B9t read all of RFC 3556 > >>>>>>>>>> but as I understand it, a b=3D 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=3D line works for > >>>>>>>>>> apt-X but makes no sense for Opus and vice versa. > >>>>>>>>>> I think that the a=3Dfmtp 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 payload@ietf.org > >>>>>>>>>> > >>>>>>>>>> https://www.ietf.org/mailman/listinfo/payload > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> payload mailing list payload@ietf.org > >>>>>>>> > >>>>>>>> https://www.ietf.org/mailman/listinfo/payload > >>>> > >>>> > >>>>> _______________________________________________ payload > >>>>> mailing list payload@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/payload > >>>> > >>>> > >>>> _______________________________________________ payload > >>>> mailing list payload@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/payload > >>>> > >>>> _______________________________________________ payload > >>>> mailing list payload@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/payload > > > > _______________________________________________ payload mailing > > list payload@ietf.org > > https://www.ietf.org/mailman/listinfo/payload > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 >=20 > iQEcBAEBAgAGBQJUq5D3AAoJEJ6/8sItn9q9+XkH/27U71MfStYlp2WXoaiW9SmP > YSpGdAbDipfnJ+7RZQ0bDf0GCRtxGxyVcAqsj9oYTFQAyMd67eRp88fzY0pRODVf > VjgWm4VLzP7jbfemzxaZXMzO/MqoiMssIvmnDB2FCirZl03aZ0vcskRAqi/OXlCm > hVJUWkf8MqxMJ1TKqbLn+WGlWHRk89wsyxYQkbfKTfQHVPmnno8eXGvDt71Gewi1 > NYyycLisXOAAtvifE+OSGvE0PPw9GcxUgysV/fTRyzEsZV9KVzVQTa4Jj1x6ff8W > 74ylYwYko5t93sRaEsQACVGjGYyXN/FfhpYZJNQ5S6j8gVrPc3Y5ZeFegx2jTEg=3D > =3Dfe42 > -----END PGP SIGNATURE----- >=20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload From nobody Wed Jan 7 04:55:59 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8175E1A8A3E for ; Wed, 7 Jan 2015 04:55:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id frBHguiSkd8G for ; Wed, 7 Jan 2015 04:55:43 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C3F41A8A4C for ; Wed, 7 Jan 2015 04:55:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14290; q=dns/txt; s=iport; t=1420635320; x=1421844920; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=p9P+ycTbUQ73qInNbkAPr1BwGX1NYwvIwh/vAMAJj9Q=; b=AUFWpejTx9Ps+L9Y1IqAU3heU0VY1nkjCKS7ogmpOacuUM9yoXtaL1GP aZtawekeeh3X9QQXyjyRxxO83UgaaskWJDiL54O+h0W86La39f3rL4H7M dUnTzBAHd+uboRvE3MW66leW4aIHy/KhjZUtiwxJIbEZ2U4wZrP28ikEo E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am8FAIMrrVStJA2M/2dsb2JhbABcgmQiUlgExicKhSlKAoEOQwEBAQEBfYQMAQEBAwEBAQEJYgsFBwQCAQgRBAEBAScHJwsUCQgCBA4FG4gJCAEMwk8BAQEBAQEBAQEBAQEBAQEBAQEBAQETBIoOhRkBARwzBwaDEIETBYkzhHuJAIEOgm6CNId7gzkiggEdgVBvgQw5fgEBAQ X-IronPort-AV: E=Sophos;i="5.07,714,1413244800"; d="scan'208";a="111038564" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-8.cisco.com with ESMTP; 07 Jan 2015 12:55:19 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t07CtJI5000925 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 Jan 2015 12:55:19 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0195.001; Wed, 7 Jan 2015 06:55:18 -0600 From: "Ali C. Begen (abegen)" To: Parthasarathi R Thread-Topic: [payload] draft-ietf-payload-rtp-opus-05: maxaveragebitrate Thread-Index: AdATp89X++FTuPj7QpWp8hHcyPj53ACMooEAA8OQx4AACfM1gP//uHjz//tbzbCACfO8AIAB6bwAgAAnIACAABPZAIAAvOsAgAFhrgCAAKplAIABQGuA Date: Wed, 7 Jan 2015 12:55:18 +0000 Message-ID: <6F2D4628-1540-45B7-B31F-FAE7D841860F@cisco.com> References: <548A3FEA.2070400@mozilla.com> <7E6F2FBF-3E29-4608-A9AE-2C5124BCE261@sverigesradio.se> <26b91d07-8e22-4790-b06e-564ee30b071d@cisco.com> <006201d0273f$e708a230$b519e690$@co.in> <1CDC64C8-B130-4FB7-B73A-6F894CB729F0@sverigesradio.se> <54A99858.1030102@mozilla.com> <,> <54A9C9D0.8050002@mozilla.com> <06DA8517-E9D8-4726-8FAE-EB7D4B110674@sverigesradio.se> <54AB90FA.6090900@mozilla.com> <002d01d029d8$fd0eba60$f72c2f20$@co.in> In-Reply-To: <002d01d029d8$fd0eba60$f72c2f20$@co.in> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.222.164] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <9E3E9F3D52ABE94F83942510BB5788C1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/XYkZMS2SL0OEQOBz1lvw7se6LrI Cc: Jean-Marc Valin , "payload@ietf.org" Subject: Re: [payload] draft-ietf-payload-rtp-opus-05: maxaveragebitrate X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 12:55:50 -0000 I think it would have been nice if b=3D attribute or something similar was = used for all codecs in the same fashion, but that did not really work. I ag= ree 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 exce= ptions here and there and dealing with such complexities would likely be to= ugh. So if someone wants to implement codecs a and b, he needs to understan= d the payload parameters for both. Eliminating only one such parameter woul= d not make much difference IMO. > On Jan 6, 2015, at 7:48 PM, Parthasarathi R = wrote: >=20 > Hi Jean-Marc/Fredrik/all, >=20 > I understand that there is a need for the parameter in the codec level an= d > it is followed as fmtp parameter specific to the given codec=20 >=20 > 1) max-br (RFC 6185) - H.264 > 2) maxbitrate (RFC 4749) - G.729.1 > 3) bitrate (RFC 5577) - G.722.1 > 3) maxaveragebitrate - Opus? >=20 > 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.=20 >=20 > My concern is that it is better to have some standard naming convention f= or > maximum bit rate for the given codec as >=20 > 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.=20 > 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 i= n > the same SDP media line. >=20 > Please let me know your opinion on the same. >=20 > Thanks > Partha >=20 >=20 >> -----Original Message----- >> From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Jean-Marc >> Valin >> Sent: Tuesday, January 06, 2015 1:09 PM >> To: Fredrik Bergholtz >> Cc: payload@ietf.org >> Subject: Re: [payload] draft-ietf-payload-rtp-opus-05: >> maxaveragebitrate >>=20 >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >>=20 >> Just posted a new version that brings back maxaveragebitrate exactly >> as it was before. >>=20 >> Cheers, >>=20 >> Jean-Marc >>=20 >> On 05/01/15 05:32 AM, Fredrik Bergholtz wrote: >>> I think that re-instating maxaveragebitrate would do it for me. >>>=20 >>> /Fredrik >>>=20 >>>=20 >>>> On 5 jan 2015, at 00:16, "Jean-Marc Valin" >>>> wrote: >>>>=20 >>> So would everyone be happy if I just revert to using >>> maxaveragebitrate as in draft 04? >>>=20 >>> Jean-Marc >>>=20 >>>=20 >>>>>> 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). >>>>>>=20 >>>>>> Other notable codecs that lack this include VP8 and VP9. >>>>>>=20 >>>>>> 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=3D line). The SDP b=3D >>>>>> 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. >>>>>>=20 >>>>>> Mo >>>>>>=20 >>>>>> On 1/4/15, 2:45 PM, Jean-Marc Valin >>>>>> wrote: >>>>>>=20 >>>>>> 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? >>>>>>=20 >>>>>> Cheers, >>>>>>=20 >>>>>> Jean-Marc >>>>>>=20 >>>>>>> On 03/01/15 09:32 AM, Fredrik Bergholtz wrote: Hi. >>>>>>=20 >>>>>>> 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. >>>>>>=20 >>>>>>> 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. >>>>>>=20 >>>>>>> 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. >>>>>>=20 >>>>>>> Best regards Fredrik Bergholtz Swedish Radio >>>>>>=20 >>>>>>> On 3 jan 2015, at 11:27, "Parthasarathi R" >>>>>>> >>>>>> > wrote: >>>>>>=20 >>>>>>>> Hi all, >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> I understand that bandwidth =B3b=B2 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. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> 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. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Thanks >>>>>>>>=20 >>>>>>>> Partha >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> *From:*payload [mailto:payload-bounces@ietf.org] *On >>>>>>>> Behalf Of *Ali C. Begen (abegen) *Sent:* Wednesday, >>>>>>>> December 31, 2014 4:57 PM *To:* Fredrik Bergholtz *Cc:* >>>>>>>> payload@ietf.org *Subject:* Re: >>>>>>>> [payload] draft-ietf-payload-rtp-opus-05: >>>>>>>> maxaveragebitrate >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Authors >>>>>>>>=20 >>>>>>>> Please chime in and lets discuss s quick solution for >>>>>>>> this on the list. Once agreed we can ship this draft. >>>>>>>>=20 >>>>>>>> -acbegen >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> *From:*Fredrik Bergholtz >>>>>>>> >>>>>>> > *Sent:* Dec >>>>>>>> 31, 2014 11:42 AM *To:* Ali C. Begen (abegen) *Cc:* >>>>>>>> Jean-Marc Valin >>>>>>> >;Fredrik >>>>>>>> Bergholtz;payload@ietf.org >>>>>>>> *Subject:* Re: [payload] draft-ietf-payload-rtp-opus-05: >>>>>>>> maxaveragebitrate >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Yes, I do see a strong need for specifying the bitrate. >>>>>>>>=20 >>>>>>>> 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. >>>>>>>>=20 >>>>>>>> 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. >>>>>>>>=20 >>>>>>>> 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. >>>>>>>>=20 >>>>>>>> Best regards Fredrik Bergholtz Swedish Radio >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> On 31 dec 2014, at 05:57, "Ali C. Begen (abegen)" >>>>>>>>> > wrote: >>>>>>>>>=20 >>>>>>>>> My understanding is that the b=3D 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. >>>>>>>>>=20 >>>>>>>>> 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. >>>>>>>>>=20 >>>>>>>>> Fredrik (or anyone else in the WG), do you see a strong >>>>>>>>> need for this? If so, now is the time to mention that. >>>>>>>>>=20 >>>>>>>>> -acbegen >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> On Dec 12, 2014, at 3:07 AM, Jean-Marc Valin >>>>>>>>>> > >>>>>>>>>> wrote: >>>>>>> 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? >>>>>>=20 >>>>>>> Jean-Marc >>>>>>=20 >>>>>>>>>>>> On 10/12/14 05:11 AM, Fredrik Bergholtz wrote: >>>>>>>>>>>> Hi. >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> 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. >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> I must admit that I haven=B9t read all of RFC 3556 >>>>>>>>>>>> but as I understand it, a b=3D 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=3D line works for >>>>>>>>>>>> apt-X but makes no sense for Opus and vice versa. >>>>>>>>>>>> I think that the a=3Dfmtp line is the correct place >>>>>>>>>>>> to specify the desired bitrate. >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> 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. >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Best regards, >>>>>>>>>>>>=20 >>>>>>>>>>>> Fredrik Bergholtz >>>>>>>>>>>>=20 >>>>>>>>>>>> Swedish Radio >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> payload mailing list payload@ietf.org >>>>>>>>>>>> >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/payload >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> payload mailing list payload@ietf.org >>>>>>>>>> >>>>>>>>>> https://www.ietf.org/mailman/listinfo/payload >>>>>>=20 >>>>>>=20 >>>>>>> _______________________________________________ payload >>>>>>> mailing list payload@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/payload >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ payload >>>>>> mailing list payload@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/payload >>>>>>=20 >>>>>> _______________________________________________ payload >>>>>> mailing list payload@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/payload >>>=20 >>> _______________________________________________ payload mailing >>> list payload@ietf.org >>> https://www.ietf.org/mailman/listinfo/payload >>>=20 >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1 >>=20 >> iQEcBAEBAgAGBQJUq5D3AAoJEJ6/8sItn9q9+XkH/27U71MfStYlp2WXoaiW9SmP >> YSpGdAbDipfnJ+7RZQ0bDf0GCRtxGxyVcAqsj9oYTFQAyMd67eRp88fzY0pRODVf >> VjgWm4VLzP7jbfemzxaZXMzO/MqoiMssIvmnDB2FCirZl03aZ0vcskRAqi/OXlCm >> hVJUWkf8MqxMJ1TKqbLn+WGlWHRk89wsyxYQkbfKTfQHVPmnno8eXGvDt71Gewi1 >> NYyycLisXOAAtvifE+OSGvE0PPw9GcxUgysV/fTRyzEsZV9KVzVQTa4Jj1x6ff8W >> 74ylYwYko5t93sRaEsQACVGjGYyXN/FfhpYZJNQ5S6j8gVrPc3Y5ZeFegx2jTEg=3D >> =3Dfe42 >> -----END PGP SIGNATURE----- >>=20 >> _______________________________________________ >> payload mailing list >> payload@ietf.org >> https://www.ietf.org/mailman/listinfo/payload >=20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload From nobody Wed Jan 7 16:42:23 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D2531A01D6 for ; Wed, 7 Jan 2015 16:42:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_14=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EF-DMxf63-_y for ; Wed, 7 Jan 2015 16:42:18 -0800 (PST) Received: from outbound.mailhostbox.com (outbound.mailhostbox.com [162.222.225.26]) by ietfa.amsl.com (Postfix) with ESMTP id 3A8BA1A01A5 for ; Wed, 7 Jan 2015 16:42:17 -0800 (PST) Received: from userPC (unknown [122.178.249.70]) (Authenticated sender: partha@parthasarathi.co.in) by outbound.mailhostbox.com (Postfix) with ESMTPA id DB3B03C043B; Thu, 8 Jan 2015 00:42:09 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1420677735; bh=CtMKytS9jl8JRE5YetfPc3iUaYQb95YY5xiYpYxnie4=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=V2A/3YNgeym6XXwhjmISjVRUEIJqzk9e3/SVl8eOtksQQpKFITBuv72oDmc9lb1ni xmmTnM/OUGbPQINDaCKeSqiw4YpzE6hAwyujPMxtwJ7JmNAyshYOzxvBlYBW6ZDtRH h7xBaQUfbzjxZv68euHsmdH+2wdS1CgSi7xvjmaY= From: "Parthasarathi R" To: "'Ali C. Begen \(abegen\)'" References: <548A3FEA.2070400@mozilla.com> <7E6F2FBF-3E29-4608-A9AE-2C5124BCE261@sverigesradio.se> <26b91d07-8e22-4790-b06e-564ee30b071d@cisco.com> <006201d0273f$e708a230$b519e690$@co.in> <1CDC64C8-B130-4FB7-B73A-6F894CB729F0@sverigesradio.se> <54A99858.1030102@mozilla.com> <, > <54A9C9D0.8050002@mozilla.com> <06DA8517-E9D8-4726-8FAE-EB7D4B110674@sverigesradio.se> <54AB90FA.6090900@mozilla.com> <002d01d029d8$fd0eba60$f72c2f20$@co.in> <6F2D4628-1540-45B7-B31F-FAE7D841860F@cisco.com> In-Reply-To: <6F2D4628-1540-45B7-B31F-FAE7D841860F@cisco.com> Date: Thu, 8 Jan 2015 06:12:02 +0530 Message-ID: <006a01d02adb$ef37cb80$cda76280$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdATp89X++FTuPj7QpWp8hHcyPj53ACMooEAA8OQx4AACfM1gP//uHjz//tbzbCACfO8AIAB6bwAgAAnIACAABPZAIAAvOsAgAFhrgCAAKplAIABQGuA//+ghbA= Content-Language: en-us x-cr-hashedpuzzle: CAAr DNoF Fw3q NaD/ TIZA Uryd XIwa Y+aA eT0s gNFI kO+5 lSrC l8Ad moY6 nRex sQuO; 4; YQBiAGUAZwBlAG4AQABjAGkAcwBjAG8ALgBjAG8AbQA7AGYAcgBlAGQAcgBpAGsALgBiAGUAcgBnAGgAbwBsAHQAegBAAHMAdgBlAHIAaQBnAGUAcwByAGEAZABpAG8ALgBzAGUAOwBqAG0AdgBhAGwAaQBuAEAAagBtAHYAYQBsAGkAbgAuAGMAYQA7AHAAYQB5AGwAbwBhAGQAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {66340BA3-AAA1-419D-8148-88A7FBFFB89A}; cABhAHIAdABoAGEAQABwAGEAcgB0AGgAYQBzAGEAcgBhAHQAaABpAC4AYwBvAC4AaQBuAA==; Thu, 08 Jan 2015 00:41:53 GMT; UgBFADoAIABbAHAAYQB5AGwAbwBhAGQAXQAgAGQAcgBhAGYAdAAtAGkAZQB0AGYALQBwAGEAeQBsAG8AYQBkAC0AcgB0AHAALQBvAHAAdQBzAC0AMAA1ADoAIABtAGEAeABhAHYAZQByAGEAZwBlAGIAaQB0AHIAYQB0AGUA x-cr-puzzleid: {66340BA3-AAA1-419D-8148-88A7FBFFB89A} X-CTCH-RefID: str=0001.0A020201.54ADD2A6.014B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 172.18.214.93 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/ldSfUD1WQjl9WOcgTTnHkkdeiCI Cc: 'Jean-Marc Valin' , payload@ietf.org Subject: Re: [payload] draft-ietf-payload-rtp-opus-05: maxaveragebitrate X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 00:42:22 -0000 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 > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > Sent: Wednesday, January 07, 2015 6:25 PM > To: Parthasarathi R > Cc: Jean-Marc Valin; Fredrik Bergholtz; payload@ietf.org > Subject: Re: [payload] draft-ietf-payload-rtp-opus-05: > maxaveragebitrate >=20 > I think it would have been nice if b=3D 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. >=20 >=20 > > On Jan 6, 2015, at 7:48 PM, Parthasarathi R > wrote: > > > > 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 > > > > > >> -----Original Message----- > >> From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Jean- > Marc > >> Valin > >> Sent: Tuesday, January 06, 2015 1:09 PM > >> To: Fredrik Bergholtz > >> Cc: payload@ietf.org > >> Subject: Re: [payload] draft-ietf-payload-rtp-opus-05: > >> maxaveragebitrate > >> > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> > >> 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: > >>> I think that re-instating maxaveragebitrate would do it for me. > >>> > >>> /Fredrik > >>> > >>> > >>>> On 5 jan 2015, at 00:16, "Jean-Marc Valin" > >>>> 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). > >>>>>> > >>>>>> 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=3D line). The SDP = b=3D > >>>>>> 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 > >>>>>> wrote: > >>>>>> > >>>>>> 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" > >>>>>>> >>>>>>> > wrote: > >>>>>> > >>>>>>>> Hi all, > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> I understand that bandwidth =B3b=B2 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:payload-bounces@ietf.org] *On > >>>>>>>> Behalf Of *Ali C. Begen (abegen) *Sent:* Wednesday, > >>>>>>>> December 31, 2014 4:57 PM *To:* Fredrik Bergholtz *Cc:* > >>>>>>>> payload@ietf.org *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 > >>>>>>>> >>>>>>>> > *Sent:* Dec > >>>>>>>> 31, 2014 11:42 AM *To:* Ali C. Begen (abegen) *Cc:* > >>>>>>>> Jean-Marc Valin >>>>>>>> >;Fredrik > >>>>>>>> Bergholtz;payload@ietf.org > >>>>>>>> *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)" > >>>>>>>>> > wrote: > >>>>>>>>> > >>>>>>>>> My understanding is that the b=3D 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 > >>>>>>>>>> > > >>>>>>>>>> wrote: > >>>>>>> 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=B9t read all of RFC 3556 > >>>>>>>>>>>> but as I understand it, a b=3D 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=3D line works for > >>>>>>>>>>>> apt-X but makes no sense for Opus and vice versa. > >>>>>>>>>>>> I think that the a=3Dfmtp 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 payload@ietf.org > >>>>>>>>>>>> > >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/payload > >>>>>>>>>> > >>>>>>>>>> _______________________________________________ > >>>>>>>>>> payload mailing list payload@ietf.org > >>>>>>>>>> > >>>>>>>>>> https://www.ietf.org/mailman/listinfo/payload > >>>>>> > >>>>>> > >>>>>>> _______________________________________________ payload > >>>>>>> mailing list payload@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/payload > >>>>>> > >>>>>> > >>>>>> _______________________________________________ payload > >>>>>> mailing list payload@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/payload > >>>>>> > >>>>>> _______________________________________________ payload > >>>>>> mailing list payload@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/payload > >>> > >>> _______________________________________________ payload mailing > >>> list payload@ietf.org > >>> https://www.ietf.org/mailman/listinfo/payload > >>> > >> -----BEGIN PGP SIGNATURE----- > >> Version: GnuPG v1 > >> > >> iQEcBAEBAgAGBQJUq5D3AAoJEJ6/8sItn9q9+XkH/27U71MfStYlp2WXoaiW9SmP > >> YSpGdAbDipfnJ+7RZQ0bDf0GCRtxGxyVcAqsj9oYTFQAyMd67eRp88fzY0pRODVf > >> VjgWm4VLzP7jbfemzxaZXMzO/MqoiMssIvmnDB2FCirZl03aZ0vcskRAqi/OXlCm > >> hVJUWkf8MqxMJ1TKqbLn+WGlWHRk89wsyxYQkbfKTfQHVPmnno8eXGvDt71Gewi1 > >> NYyycLisXOAAtvifE+OSGvE0PPw9GcxUgysV/fTRyzEsZV9KVzVQTa4Jj1x6ff8W > >> 74ylYwYko5t93sRaEsQACVGjGYyXN/FfhpYZJNQ5S6j8gVrPc3Y5ZeFegx2jTEg=3D > >> =3Dfe42 > >> -----END PGP SIGNATURE----- > >> > >> _______________________________________________ > >> payload mailing list > >> payload@ietf.org > >> https://www.ietf.org/mailman/listinfo/payload > > > > _______________________________________________ > > payload mailing list > > payload@ietf.org > > https://www.ietf.org/mailman/listinfo/payload From nobody Thu Jan 8 09:34:17 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A65CB1A8BC3 for ; Thu, 8 Jan 2015 09:34:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZztF6S3cJkfv for ; Thu, 8 Jan 2015 09:34:05 -0800 (PST) Received: from mail-vc0-x22b.google.com (mail-vc0-x22b.google.com [IPv6:2607:f8b0:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 276EA1A8AF9 for ; Thu, 8 Jan 2015 09:34:05 -0800 (PST) Received: by mail-vc0-f171.google.com with SMTP id hy4so1594847vcb.2 for ; Thu, 08 Jan 2015 09:34:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=W92rTC2yd4r+7oxX5DTUA0uXU47JkcB/H2nZCr5BUMA=; b=TbZYl+jtGPOULBr1q8S74ZyztYJZf9RM7Z04VD1IIVhWUO6P9SicBjn1B9hhC+477D KJmL9y5M2pbEgiPWIFjxf6eKlS9w1tM2YgzlXkrA4opBwNwUxLCZij5ATlQX4r7T4Wlx 0Kh/dSiMN9yauqg6nItWjS9YltbCziLhnmjIDGnn/5nLAXbrCv2nAmiljc51PJPjQLLn CVMl+ZKBWBxzZe2xe5/JKLiPM9eSlTHBP/J1A+DadHb2EOev61i27b3ezR6aKQDUtAEf dO4UGs1wp0UNUqvMQSlCR60MJjUt6djudGCiEyYdXfDbky+JjZnurmZoVhHVpzZlYUR0 y4bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=W92rTC2yd4r+7oxX5DTUA0uXU47JkcB/H2nZCr5BUMA=; b=bWzBF5zhXrpzjTtX//EM/SzlrVb4xkeRC8BRGcK0TSebuLwpdrFdKlL2EZj/PsirRu lymKtebJ5erbb+nCYL5eFvPI+9ezjpE4XtGdDLoxPHkjTLMyWSqR1NLaeMWSDwWDOZQb hSek7Amr/1FbXLZkVpKfRKmftlHekd0H/eRJKzPlxXNL9uUnU/jzDpnyEVNFNR1aR1+m eqWNGN6HOJRd6fQRk5YPm2A/x1bXUJlKqKApPS2fGPJ+nZHM6dRzJo0di/9cG6cOgkBn Jid/6ne0cU2QW+JsOmePUhOKgjh8SCvBmKDd09sMG/e6FgVIuJvUzW3tW9Mdv9o64EgW Seag== X-Gm-Message-State: ALoCoQkmS8z2VN0u3BN/h7SPgVQMwX97xtgh7N8BLIZv9HW3kOvFgclQYP8O2/Yg4Sx7WcLCPyAZ X-Received: by 10.53.1.134 with SMTP id bg6mr6355338vdd.37.1420738444334; Thu, 08 Jan 2015 09:34:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.111.232 with HTTP; Thu, 8 Jan 2015 09:33:44 -0800 (PST) From: Justin Uberti Date: Thu, 8 Jan 2015 09:33:44 -0800 Message-ID: To: payload@ietf.org Content-Type: multipart/alternative; boundary=001a1135f22c4b5079050c2772f3 Archived-At: Subject: [payload] Packetization draft for VP9 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 17:34:09 -0000 --001a1135f22c4b5079050c2772f3 Content-Type: text/plain; charset=UTF-8 There wasn't much opportunity to talk about this at IETF 91, so I wanted to mention that there is now a draft for RTP packetization for the VP9 video codec, https://tools.ietf.org/html/draft-uberti-payload-vp9-00. VP9 supports both temporal and spatial scalability features, and the proposed packetization is designed to handle this. Please take a look and send comments. --001a1135f22c4b5079050c2772f3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
There wasn= 9;t much opportunity to talk about this at IETF 91, so I wanted to mention = that there is now a draft for RTP packetization for the VP9 video codec,=C2= =A0https://tools.i= etf.org/html/draft-uberti-payload-vp9-00.=C2=A0
VP9 supports both tempor= al and spatial scalability features, and the proposed packetization is desi= gned to handle this. Please take a look and send comments.
--001a1135f22c4b5079050c2772f3-- From nobody Fri Jan 9 08:09:05 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5B3E1A8AF7 for ; Thu, 8 Jan 2015 09:31:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ty7mGcWS9VDK for ; Thu, 8 Jan 2015 09:31:46 -0800 (PST) Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A9BA1A8AEC for ; Thu, 8 Jan 2015 09:31:46 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id hq11so1598514vcb.3 for ; Thu, 08 Jan 2015 09:31:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=GAC6z+KsR91ySeiPo3RhJHlY25gxiOMo2UYm+YVh6Z8=; b=QvK/9MU+b8Nmj9GSv0VfJ23uOFSxUK13MPbSQ0VQk8dc4GEgyyfGNi8qpg1ll+XKXb O98/IbMZSLp9Bfwedzriu8uewxBHfihT9j86kDIwaqqQEJKflkPmdNdl+Vm6uld/mSt2 pZY6KecKSPlsGo09u/k4ZmskqH2Gr5XBEB0CM6bUQyBwWos81WW+KeeGHlkawqkf0TQa mwBPQDZSQK1cF6ZWtOkYgvkWwXWwg9pvmtU9G4DoWlnseBURNr4VPA/d+vZsXPJzUWWW 2RzOCZQEi1wGpTiG8g9cghnLlEAEKCEZIbtX90sd6cD2NExs3MOcyaueblDQL/9Jpmh+ NPSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=GAC6z+KsR91ySeiPo3RhJHlY25gxiOMo2UYm+YVh6Z8=; b=dJ4N66OzDtT/0/kL2tF4gLrJijbKO3K3rnnejd5ETkHLqZWjGC3ptgJrlCfIGe2iqj OQxiwevrXWL6preM5C1nmFI3U0tvIxd2seGllcqBteFNfMsJdGN3dQpE8YQwzgD7mkiu v2yJ4yS22kZrZ97QKcSUKhP124cu43th1UwDDyOf8lR7Nxhq2JZzrmWBqCHiw3tKBNhW WmeqzOgCUZgGBs5rZScE+AMR9YJmXPKDULoRJ8tewyfyqrmtkx5/vkpBil+a2vCSYMkk r95HYzRai7Jn0AkxXQAVXvJGNi8lAMdX+luODyzLLalKioTEatvh9kk5ye9lthJUbRys hsAA== X-Gm-Message-State: ALoCoQlR811m+WaF3Q0xOsbgCm7QQ2G55nzVKIDlSNAXoPc5CRFDrp86XfnNA6Hw4T27S1B+kmJE X-Received: by 10.52.183.34 with SMTP id ej2mr6570943vdc.9.1420738305481; Thu, 08 Jan 2015 09:31:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.111.232 with HTTP; Thu, 8 Jan 2015 09:31:25 -0800 (PST) From: Justin Uberti Date: Thu, 8 Jan 2015 09:31:25 -0800 Message-ID: To: payload@ietf.org Content-Type: multipart/alternative; boundary=bcaec548a19d0483f6050c276a35 Archived-At: X-Mailman-Approved-At: Fri, 09 Jan 2015 08:09:04 -0800 Subject: [payload] Packetization draft for VP9 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 17:31:48 -0000 --bcaec548a19d0483f6050c276a35 Content-Type: text/plain; charset=UTF-8 There wasn't much opportunity to talk about this at IETF 91, so I wanted to mention that there is now a draft for RTP packetization for the VP9 video codec, https://tools.ietf.org/html/draft-uberti-payload-vp9-00. VP9 supports both temporal and spatial scalability features, and the proposed packetization is designed to handle this. Please take a look and send comments. --bcaec548a19d0483f6050c276a35 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
There wasn't much opportunity to talk about this at IE= TF 91, so I wanted to mention that there is now a draft for RTP packetizati= on for the VP9 video codec, https://tools.ietf.org/html/draft-uberti-payload-vp9-0= 0.=C2=A0

VP9 supports both temporal and spatial scal= ability features, and the proposed packetization is designed to handle this= . Please take a look and send comments.
--bcaec548a19d0483f6050c276a35-- From nobody Sun Jan 11 00:13:02 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 558471A1B26 for ; Sun, 11 Jan 2015 00:12:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.99 X-Spam-Level: X-Spam-Status: No, score=0.99 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HUyaUmcbB8Cu for ; Sun, 11 Jan 2015 00:12:53 -0800 (PST) Received: from nm22-vm2.bullet.mail.ne1.yahoo.com (nm22-vm2.bullet.mail.ne1.yahoo.com [98.138.91.210]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4E721A1B11 for ; Sun, 11 Jan 2015 00:12:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1420963972; bh=8q+/NdAxFzBSN27Je6akaZku+DsqfKuijG/HmjRblhk=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=OH3c6Nda08d4dcI6kPWeBs2I62Y3kxTD1HeK4Sn0JqFcD/710FKTwY0+aJFKC0yebMIjH3r2cyYJGH8DCLXdEe6UnvWVGKN6981I1eWqQEL85uzyb5zr5tFvG+FZkfj4QmOKjIWmmKs7v3zGgHmWM1djv/UeXUU9jiLIL2uRUzLjSCFvcgnFz+zS9E2FVIFAEbWu0tDWrXvb1J+Yz5DDxVe8gIqor6Bz0FlOBh+UCFrjUH8nRjhC3uCMLR2W0ej6liKW7QQ4yHCHQu/lV+6/CMXuDyyTOg2Xd/mz5WxNnsVoN4OGfiRcqnbq0uSyNpnhGwMKRYYFE350+3aywSkYZA== Received: from [98.138.100.113] by nm22.bullet.mail.ne1.yahoo.com with NNFMP; 11 Jan 2015 08:12:52 -0000 Received: from [98.138.89.167] by tm104.bullet.mail.ne1.yahoo.com with NNFMP; 11 Jan 2015 08:12:52 -0000 Received: from [127.0.0.1] by omp1023.mail.ne1.yahoo.com with NNFMP; 11 Jan 2015 08:12:52 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 92555.36777.bm@omp1023.mail.ne1.yahoo.com X-YMail-OSG: srzymtQVM1kX.alJZPJv0xSViXQ3VVUsk5oKMDqGMnW8y70rMDAJjxG9PwXD6_j HoAGxFM.E7tgmvPrg3ShmdMLdhKRymFHcfR0Cwe2YdbqNZZZVtZoparcNE8z7nht6LROJJBfj5di ezd47ZOvnenNSb_QJrnY49f6NPqhs0GVEHhgjXztHtw8kNAqm4BxG.l0Dpzvxrj91ALuRWx1HUyL hWPZX.hfHY9GFcm5GAPunYmqaDU9VZPcMl7lyFfixg1MpkusKYEQHDTI6R.lgw840fmhj4NNpA2_ Kr9khVBjknWbYiwB_6rSSurYfq2UJmMENsa2HipLu3pUBAqKw85awqnn50ZiUk7_C9eqLOFUM3Kq ToxX2r7Y7cNLXr2ds.q9pgGaVkt6PhSvDzBtZjUlkL1CTJ.j_vt03R4hHLH9mSB3q_dE_938lJVP BidGEbUU2UqcfirqBoniQS1NcVXc_XgKV_RL8DC8BGhBUy1p8FLpYVDtgu.qM0BjSsyqEg4.BkrL NLdc- Received: by 98.138.105.213; Sun, 11 Jan 2015 08:12:51 +0000 Date: Sun, 11 Jan 2015 08:12:50 +0000 (UTC) From: IKRAM UDDIN To: "payload@ietf.org" Message-ID: <513825961.239795.1420963970823.JavaMail.yahoo@jws10059.mail.ne1.yahoo.com> In-Reply-To: <380149661.239689.1420963873102.JavaMail.yahoo@jws10059.mail.ne1.yahoo.com> References: <006a01d02adb$ef37cb80$cda76280$@co.in> <380149661.239689.1420963873102.JavaMail.yahoo@jws10059.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_239794_959114072.1420963970805" Archived-At: Subject: [payload] draft-ietf-payload-rtp-opus-05: maxaveragebitrate X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: IKRAM UDDIN List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2015 08:12:58 -0000 ------=_Part_239794_959114072.1420963970805 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Check RFC5577 and RFC4749 for bitrate parameter (for voice)=C2=A0 Regards, Ikram Ud Din InterNetworks Research Laboratory,Universiti Utara Malaysia. I'm fine in case it is considered as implementers issue. These bitrate related parameters are optional parameters for the given code= c and each implementor has its his own choice to implement or ignore. Thanks Partha > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > Sent: Wednesday, January 07, 2015 6:25 PM > To: Parthasarathi R > Cc: Jean-Marc Valin; Fredrik Bergholtz; payload@ietf.org > Subject: Re: [payload] draft-ietf-payload-rtp-opus-05: > maxaveragebitrate >=20 > I think it would have been nice if b=3D 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. >=20 >=20 > > On Jan 6, 2015, at 7:48 PM, Parthasarathi R > wrote: > > > > 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)=C2=A0 - 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 > > > > > >> -----Original Message----- > >> From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Jean- > Marc > >> Valin > >> Sent: Tuesday, January 06, 2015 1:09 PM > >> To: Fredrik Bergholtz > >> Cc: payload@ietf.org > >> Subject: Re: [payload] draft-ietf-payload-rtp-opus-05: > >> maxaveragebitrate > >> > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> > >> Just posted a new version that brings back maxaveragebitrate exactly > >> as it was before. > >> > >> Cheers, > >> > >> =C2=A0=C2=A0=C2=A0 Jean-Marc > >> > >> On 05/01/15 05:32 AM, Fredrik Bergholtz wrote: > >>> I think that re-instating maxaveragebitrate would do it for me. > >>> > >>> /Fredrik > >>> > >>> > >>>> On 5 jan 2015, at 00:16, "Jean-Marc Valin" > >>>> 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). > >>>>>> > >>>>>> 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=3D line). The SDP b=3D > >>>>>> 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 > >>>>>> wrote: > >>>>>> > >>>>>> 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" > >>>>>>> >>>>>>> > wrote: > >>>>>> > >>>>>>>> Hi all, > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> I=C2=A0 understand that bandwidth =C2=B3b=C2=B2 parameter has lo= t 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=C2=A0 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:payload-bounces@ietf.org] *On > >>>>>>>> Behalf Of *Ali C. Begen (abegen) *Sent:* Wednesday, > >>>>>>>> December 31, 2014 4:57 PM *To:* Fredrik Bergholtz *Cc:* > >>>>>>>> payload@ietf.org *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 > >>>>>>>> >>>>>>>> > *Sent:* Dec > >>>>>>>> 31, 2014 11:42 AM *To:* Ali C. Begen (abegen) *Cc:* > >>>>>>>> Jean-Marc Valin >>>>>>>> >;Fredrik > >>>>>>>> Bergholtz;payload@ietf.org > >>>>>>>> *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)" > >>>>>>>>> > wrote: > >>>>>>>>> > >>>>>>>>> My understanding is that the b=3D 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 > >>>>>>>>>> > > >>>>>>>>>> wrote: > >>>>>>> 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=C2=B9t read all of RFC 3556 > >>>>>>>>>>>> but as I understand it, a b=3D 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=3D line works for > >>>>>>>>>>>> apt-X but makes no sense for Opus and vice versa. > >>>>>>>>>>>> I think that the a=3Dfmtp 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 payload@ietf.org > >>>>>>>>>>>> > >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/payload > >>>>>>>>>> > >>>>>>>>>> _______________________________________________ > >>>>>>>>>> payload mailing list payload@ietf.org > >>>>>>>>>> > >>>>>>>>>> https://www.ietf.org/mailman/listinfo/payload > >>>>>> > >>>>>> > >>>>>>> _______________________________________________ payload > >>>>>>> mailing list payload@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/payload > >>>>>> > >>>>>> > >>>>>> _______________________________________________ payload > >>>>>> mailing list payload@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/payload > >>>>>> > >>>>>> _______________________________________________ payload > >>>>>> mailing list payload@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/payload > >>> > >>> _______________________________________________ payload mailing > >>> list payload@ietf.org > >>> https://www.ietf.org/mailman/listinfo/payload > >>> > >> -----BEGIN PGP SIGNATURE----- > >> Version: GnuPG v1 > >> > >> iQEcBAEBAgAGBQJUq5D3AAoJEJ6/8sItn9q9+XkH/27U71MfStYlp2WXoaiW9SmP > >> YSpGdAbDipfnJ+7RZQ0bDf0GCRtxGxyVcAqsj9oYTFQAyMd67eRp88fzY0pRODVf > >> VjgWm4VLzP7jbfemzxaZXMzO/MqoiMssIvmnDB2FCirZl03aZ0vcskRAqi/OXlCm > >> hVJUWkf8MqxMJ1TKqbLn+WGlWHRk89wsyxYQkbfKTfQHVPmnno8eXGvDt71Gewi1 > >> NYyycLisXOAAtvifE+OSGvE0PPw9GcxUgysV/fTRyzEsZV9KVzVQTa4Jj1x6ff8W > >> 74ylYwYko5t93sRaEsQACVGjGYyXN/FfhpYZJNQ5S6j8gVrPc3Y5ZeFegx2jTEg=3D > >> =3Dfe42 > >> -----END PGP SIGNATURE----- > >> > >> _______________________________________________ > >> payload mailing list > >> payload@ietf.org > >> https://www.ietf.org/mailman/listinfo/payload > > > > _______________________________________________ > > payload mailing list > > payload@ietf.org > > https://www.ietf.org/mailman/listinfo/payload _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload ------=_Part_239794_959114072.1420963970805 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


=
= Hi,
Check RFC5577 a= nd RFC4749 for bitrate parameter (for voice)
&n= bsp;
Regards,
= Ikram Ud Din
InterNetworks Research= Laboratory,
Unive= rsiti Utara Malaysia.


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

These bitrate related parameters are optional parameters for the giv= en codec
and each implementor has its his own choice to i= mplement or ignore.

Thanks
Partha

> -----Original Message= -----
> From: Ali C. Begen (abegen) [mailto:abegen@cisco.com]
> Sent: Wednesday, January 07, 2015 6:25 PM
> To:= Parthasarathi R
> Cc: Jean-Marc Valin; Fredrik Bergho= ltz; payload@ietf.org
> S= ubject: Re: [payload] draft-ietf-payload-rtp-opus-05:
>= ; maxaveragebitrate
>
> I think = it would have been nice if b=3D attribute or something similar
> was used for all codecs in the same fashion, but that did not re= ally
> work. I agree that a common payload parameter w= ould 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 parame= ters for both.
> Eliminating only one such parameter w= ould not make much difference IMO.
>
>
> > On Jan 6, 2015, at 7:48 PM, Parthasarat= hi R
> <partha@parthasarathi.co.in> wrote:
> >
> > Hi Jean-Marc/Fredrik/all,> >
> > I understand that th= ere is a need for the parameter in the codec
> level a= nd
> > 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 par= ameter 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
> conventio= n for
> > maximum bit rate for the given codec as> >
> > 1) It is simple to i= mplement in the generic fashion in case of
> multiple<= br clear=3D"none">> > codec handling in the given SDP. This is the co= mmon implementation.
> > 2) Offer/answer behavior w= ill be common across multiple codec.
> > 3) Interac= tion with bandwidth ("b") parameter in the SDP level and
= > these
> > codec specific max bit rate paramete= r will be clear in case both
> exists in
> > the same SDP media line.
> >
> > Please let me know your opinion on the same.
> >
> > Thanks
&g= t; > Partha
> >
> >
> >> -----Original Message-----
&g= t; >> From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Jean-
> Marc
> >> Valin
> >> Sent: Tuesday, January 06, 2015 1:09 PM
> >> To: Fredrik Bergholtz
> >> Cc: <= a rel=3D"nofollow" shape=3D"rect" ymailto=3D"mailto:payload@ietf.org" targe= t=3D"_blank" href=3D"mailto:payload@ietf.org">payload@ietf.org
> >> Subject: Re: [payload] draft-ietf-payload-rtp-opus-= 05:
> >> maxaveragebitrate
>= ; >>
> >> -----BEGIN PGP SIGNED MESSAGE---= --
> >> Hash: SHA1
> >&g= t;
> >> Just posted a new version that brings ba= ck maxaveragebitrate exactly
> >> as it was befo= re.
> >>
> >> Cheers,=
> >>
> >>  &nbs= p;  Jean-Marc
> >>
> &= gt;> On 05/01/15 05:32 AM, Fredrik Bergholtz wrote:
&g= t; >>> I think that re-instating maxaveragebitrate would do it for= me.
> >>>
> >>>= ; /Fredrik
> >>>
> >&= gt;>
> >>>> On 5 jan 2015, at 00:16, "J= ean-Marc Valin" <jmva= lin@jmvalin.ca>
> >>>> wrote:
> >>>>
> >>> So w= ould everyone be happy if I just revert to using
> >= ;>> maxaveragebitrate as in draft 04?
> >>= >
> >>> Jean-Marc
> &= gt;>>
> >>>
> >= >>>>> On 04/01/15 05:05 PM, Mo Zanaty (mzanaty) wrote: Some = other
> >>>>>> codecs have fmtp para= meters for maximum bitrate explicitly
> >>>&g= t;>> (e.g. max-br in H264 / H264-SVC / H265) and/or implicitly
> >>>>>> (e.g. profile-level-id in H264 / = H264-SVC / H265 / AAC;
> >>>>>> conf= ig in AAC).
> >>>>>>
> >>>>>> Other notable codecs that lack this includ= e VP8 and VP9.
> >>>>>>
> >>>>>> This is a general problem which may bec= ome more important
> >>>>>> with com= plex applications that include simulcast and scalable
>= ; >>>>>> media within the same media description (m=3D li= ne). The SDP b=3D
> >>>>>> parameter= is clearly insufficient for expressing multiple
> >= ;>>>>> different maximum bitrates for each payload type, unl= ess we
> >>>>>> define a new bandwid= th modifier which includes explicit PT
> >>>&= gt;>> bindings. Payload formats that include fmtp parameters for
> >>>>>> maximum bitrate can avoid this = problem, so I think it is
> >>>>>> a= dvisable to add this to Opus, VP8 and VP9.
> >>&= gt;>>>
> >>>>>> Mo
> >>>>>>
> >>>= >>> On 1/4/15, 2:45 PM, Jean-Marc Valin <jmvalin@jmvalin.ca>
> >>>>>> wrote:
> >>>&g= t;>>
> >>>>>> Setting the bitr= ate isn't exactly a new problem here. Opus
> >>&= gt;>>> isn't the first codec to support more than one rate so how<= br clear=3D"none">> >>>>>> are the other codecs (audio= and video) handling bitrate
> >>>>>>= ; signaling?
> >>>>>>
> >>>>>> Cheers,
> >>&g= t;>>>
> >>>>>> Jean-Marc> >>>>>>
> >&g= t;>>>>> On 03/01/15 09:32 AM, Fredrik Bergholtz wrote: Hi.> >>>>>>
> >&= gt;>>>>> One thought om the general media level bit rate
> >>>>>>> specification is that it c= an never be anything other than
> >>>>>= >> an approximate value. Different codecs define different
> >>>>>>> constraints on the bit rate. I = think that the easiest way
> >>>>>>&= gt; 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 b= e
> >>>>>>> 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
> >>>>>>&g= t; 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 extens= ion is known as "ACIP
> >>>>>>> P= rofiles" and can be found at the EBU web site. But I
>= >>>>>>> digress.
> >>>&= gt;>>
> >>>>>>> I don't thi= nk that forcing encoders to approximate the
> >>= >>>>> nearest allowed value for the selected codec is less> >>>>>>> complicated than interpr= eting an exact value. In addition,
> >>>>&= gt;>> it would add a non-deterministic aspect, thus the resulting
> >>>>>>> bit rate may not be what t= he user expected.
> >>>>>>
> >>>>>>> Best regards Fredrik Bergholtz = Swedish Radio
> >>>>>>
> >>>>>>> On 3 jan 2015, at 11:27, "Parthasara= thi R"
> >>>>>>> <partha@parthasarathi= .co.in
> >>>>>>> <mailto:<= a rel=3D"nofollow" shape=3D"rect" ymailto=3D"mailto:partha@parthasarathi.co= .in" target=3D"_blank" href=3D"mailto:partha@parthasarathi.co.in">partha@pa= rthasarathi.co.in>> wrote:
> >>>>= ;>>
> >>>>>>>> Hi all,> >>>>>>>>
&g= t; >>>>>>>>
> >>>>= >>>>
> >>>>>>>> I&= nbsp; understand that bandwidth =C2=B3b=C2=B2 parameter has lot of
> >>>>>>>> variants like AS, TIAS and = usage but all those parameters
> >>>>>&= gt;>> are media level and not codec specific. The bandwidth
> >>>>>>>> allocation is going to be h= appen 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
> >>>>>&= gt;>> 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 complicate= s these bandwidth calculation
> >>>>>&g= t;>> still further which is applicable to maxaveragebitrate
> >>>>>>>> parameter in opus.
> >>>>>>>>
> >= >>>>>>>
> >>>>>>= ;>>
> >>>>>>>> I could n= ot understand why the generic parameter should
> >&= gt;>>>>>> not used or generic parameter has to be enhance= d which
> >>>>>>>> meets Opus = requirement rather than opus specific
> >>>&g= t;>>>> parameter.
> >>>>>&g= t;>>
> >>>>>>>>
> >>>>>>>>
> >= >>>>>>> Thanks
> >>>>= >>>>
> >>>>>>>> Pa= rtha
> >>>>>>>>
> >>>>>>>>
> >>&g= t;>>>>>
> >>>>>>>&= gt; *From:*payload [mailto:payload-bounces@ietf.org] *On
> >= ;>>>>>>> Behalf Of *Ali C. Begen (abegen) *Sent:* Wedn= esday,
> >>>>>>>> December 31,= 2014 4:57 PM *To:* Fredrik Bergholtz *Cc:*
> >>= >>>>>> pay= load@ietf.org <mailto:payload@ietf.org> *Subject:* Re:
> >>>= ;>>>>> [payload] draft-ietf-payload-rtp-opus-05:
> >>>>>>>> maxaveragebitrate
> >>>>>>>>
> >>= >>>>>>
> >>>>>>>= ;>
> >>>>>>>> Authors
> >>>>>>>>
> &= gt;>>>>>>> Please chime in and lets discuss s quick so= lution for
> >>>>>>>> this on = the list. Once agreed we can ship this draft.
> >&g= t;>>>>>>
> >>>>>>&= gt;> -acbegen
> >>>>>>>>> >>>>>>>>
>= ; >>>>>>>>
> >>>>&= gt;>>> *From:*Fredrik Bergholtz
> >>>= ;>>>>> <fredrik.bergholtz@sverigesradio.se> >>>>>>>> <mailto:fr= edrik.bergholtz@sverigesradio.se>> *Sent:* Dec
= > >>>>>>>> 31, 2014 11:42 AM *To:* Ali C. Begen = (abegen) *Cc:*
> >>>>>>>> Jean= -Marc Valin <jmvali= n@mozilla.com
> >>>>>>>> &= lt;mailto:jmvalin@mozi= lla.com>>;Fredrik
> >>>>>>= >> Bergholtz;payload@i= etf.org <mailto:paylo= ad@ietf.org>
> >>>>>>>>= *Subject:* Re: [payload] draft-ietf-payload-rtp-opus-05:
> >>>>>>>> maxaveragebitrate
= > >>>>>>>>
> >>>&g= t;>>>>
> >>>>>>>><= br clear=3D"none">> >>>>>>>> Yes, I do see a str= ong need for specifying the bitrate.
> >>>>= ;>>>>
> >>>>>>>> I= n the broadcasting use case we have to make sure that we
= > >>>>>>>> get the best audio quality that is po= ssible for the
> >>>>>>>> netw= ork that is currently used but never try to send more
>= ; >>>>>>>> data than the particular link is capable= of. For this
> >>>>>>>> reaso= n, specifying a maximum bit rate is required.
> >&g= t;>>>>>>
> >>>>>>&= gt;> 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
&g= t; >>>>>>>> over time we will often use constant bi= t rate and then it
> >>>>>>>> = becomes even more important to be able to specify what
&g= t; >>>>>>>> bit rate should be.
&= gt; >>>>>>>>
> >>>>= ;>>>> We will use the Opus codec over various network links
> >>>>>>>> with different capabil= ities in terms of bit rate, delay
> >>>>&g= t;>>> variation, absolute delay, etc and we will typically use
> >>>>>>>> the SDP to signal the = parameters that best fit both the
> >>>>&g= t;>>> current network and the current type of radio
> >>>>>>>> production.
>= ; >>>>>>>>
> >>>>&= gt;>>> Best regards Fredrik Bergholtz Swedish Radio
> >>>>>>>>
> >>&g= t;>>>>>
> >>>>>>>&= gt;> On 31 dec 2014, at 05:57, "Ali C. Begen (abegen)"
> >>>>>>>>> <abegen@cisco.com <mailto:abegen@cisco.com>> wrote:
> >>>>>>>>>
> >>= >>>>>>> My understanding is that the b=3D line in the = SDP is
> >>>>>>>>> quite a = subjective parameter. I have seen people use it
> >= >>>>>>>> differently over the past several years. S= o, it is a
> >>>>>>>>> bit = difficult to infer much accuracy from that line.
> >= ;>>>>>>>>
> >>>>&g= t;>>>> 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 arou= nd
> >>>>>>>>> how to set t= hat value and what to do with that value
> >>>= ;>>>>>> need to be clearly specified.
&= gt; >>>>>>>>>
> >>>= ;>>>>>> Fredrik (or anyone else in the WG), do you see a = strong
> >>>>>>>>> need for= this? If so, now is the time to mention that.
> >&= gt;>>>>>>>
> >>>>>= >>>> -acbegen
> >>>>>>&g= t;>>
> >>>>>>>>>
> >>>>>>>>>> On Dec 12, 2014= , at 3:07 AM, Jean-Marc Valin
> >>>>>&g= t;>>>> <jmvalin@mozilla.com <mailto:jmvalin@mozilla.com>>
> >&g= t;>>>>>>>> wrote:
> >>&g= t;>>>> I have to say this is not something I understand really<= br clear=3D"none">> >>>>>>> well. Does anyone else = here have an opinion on how to
> >>>>>&= gt;> specify bit-rate?
> >>>>>>> >>>>>>> Jean-Marc
> >>>>>>
> >>>>&g= t;>>>>>>> On 10/12/14 05:11 AM, Fredrik Bergholtz wrot= e:
> >>>>>>>>>>>> = Hi.
> >>>>>>>>>>>>=
> >>>>>>>>>>>>> >>>>>>>>>>>>
> >>>>>>>>>>>> I read i= n 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 pr= ovides added value over
> >>>>>>>= >>>>> the bandwidth modifiers added by RFC 3556.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
&g= t; >>>>>>>>>>>> I must admit that I hav= en=C2=B9t read all of RFC 3556
> >>>>>&= gt;>>>>>> but as I understand it, a b=3D 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 descri= ption. Different coding
> >>>>>>>= >>>>> algorithms have different constraints on the
> >>>>>>>>>>>> allowed bit= rate. For example, I might want to
> >>>>&= gt;>>>>>>> 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= =3D line works for
> >>>>>>>>&= gt;>>> apt-X but makes no sense for Opus and vice versa.
> >>>>>>>>>>>> I think tha= t the a=3Dfmtp line is the correct place
> >>>= ;>>>>>>>>> to specify the desired bitrate.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> For the broadcast= ing use-case, it is often more
> >>>>>&= gt;>>>>>> important to have a constant and predictable> >>>>>>>>>>>> audio= quality and network usage than mere
> >>>>= ;>>>>>>>> audibility at any cost.
> >>>>>>>>>>>>
&g= t; >>>>>>>>>>>>
> = >>>>>>>>>>>>
> >= ;>>>>>>>>>>> Best regards,
> >>>>>>>>>>>>
= > >>>>>>>>>>>> Fredrik Bergholtz
> >>>>>>>>>>>>
> >>>>>>>>>>>> Swedish R= adio
> >>>>>>>>>>>>= ;
> >>>>>>>>>>>>> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> ___________= ____________________________________
> >>>>= ;>>>>>>>> payload mailing list payload@ietf.org
> &g= t;>>>>>>>>>>> <mailto:payload@ietf.org>
&g= t; >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/payload
> >>>>>>>>>>
> >= ;>>>>>>>>> _____________________________________= __________
> >>>>>>>>>> = payload mailing list payload= @ietf.org
> >>>>>>>>>&g= t; <mailto:payload@ietf.o= rg>
> >>>>>>>>>> = https://www.ietf.org/mailman/listinfo/payl= oad
> >>>>>>
&= gt; >>>>>>
> >>>>>>= ;> _______________________________________________ payload
> >>>>>>> mailing list payload@ietf.org
> >>= ;>>>>> https://www.ietf.org= /mailman/listinfo/payload
> >>>>>&g= t;
> >>>>>>
> &= gt;>>>>> _______________________________________________ pay= load
> >>>>>> mailing list payload@ietf.org
> >>>>>> https://= www.ietf.org/mailman/listinfo/payload
> >>&g= t;>>>
> >>>>>> ____________= ___________________________________ payload
> >>= >>>> mailing list payload@ietf.org
> >>>>>> https://www.ietf.org/mailman/listinfo/payload<= /a>
> >>>
> >>>= _______________________________________________ payload mailing
> >>> list payload@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/payload
> >>>
> >> -----BEGIN P= GP SIGNATURE-----
> >> Version: GnuPG v1
> >>
> >> iQEcBAEBAgAGBQJUq5= D3AAoJEJ6/8sItn9q9+XkH/27U71MfStYlp2WXoaiW9SmP
> >&= gt; YSpGdAbDipfnJ+7RZQ0bDf0GCRtxGxyVcAqsj9oYTFQAyMd67eRp88fzY0pRODVf
> >> VjgWm4VLzP7jbfemzxaZXMzO/MqoiMssIvmnDB2FCirZl03aZ= 0vcskRAqi/OXlCm
> >> hVJUWkf8MqxMJ1TKqbLn+WGlWHR= k89wsyxYQkbfKTfQHVPmnno8eXGvDt71Gewi1
> >> NYyyc= LisXOAAtvifE+OSGvE0PPw9GcxUgysV/fTRyzEsZV9KVzVQTa4Jj1x6ff8W
> >> 74ylYwYko5t93sRaEsQACVGjGYyXN/FfhpYZJNQ5S6j8gVrPc3Y5ZeFegx= 2jTEg=3D
> >> =3Dfe42
> >= ;> -----END PGP SIGNATURE-----
> >>
> >> _______________________________________________
> >> payload mailing list
> &g= t;> payload@ietf.org<= br clear=3D"none">> >> https://= www.ietf.org/mailman/listinfo/payload
> >
> > _______________________________________________
> > payload mailing list
> > payload@ietf.org
> > https://www.ietf.org/m= ailman/listinfo/payload

__________= _____________________________________
payload mailing lis= t
payload@= ietf.org
https://www= .ietf.org/mailman/listinfo/payload


<= /html> ------=_Part_239794_959114072.1420963970805-- From nobody Mon Jan 12 02:42:50 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86D9A1A0191 for ; Mon, 12 Jan 2015 02:42:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jKr114p4EVoL for ; Mon, 12 Jan 2015 02:42:38 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69F851A8AC5 for ; Mon, 12 Jan 2015 02:42:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5414; q=dns/txt; s=iport; t=1421059337; x=1422268937; h=from:to:cc:subject:date:message-id:references: mime-version; bh=w9sztE7bb6DkYUr5SUQc5Nbczxc9RjeHf71PjcOkw0o=; b=kN1oojHBDgW/hN13ehrBiO9bJpXDE58hyFDBrnGPkiLsa4u/eKSNh0Fm df3bXM9pqMzVJ0b3AiwXZfwYEgxHY06bzexRq1gfxw23cpHM10pCN6rbh eeyiqvT9JPod/vPabqdWhDeb6CmpHYcGzfin0hh2lwoT0thQl2t19vcfF 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAKCjs1StJV2Q/2dsb2JhbABbgkMhIoEuy2yBE0MBAQEBAX2EDQEBBAxtEAIBCD8HMhQRAgQOBYgsAcs4AQEBAQEBAQEBAQEBAQEBAQEBARmPeYMdgRMFjj2JDZF4IoIBHYFQb4FFfgEBAQ X-IronPort-AV: E=Sophos;i="5.07,743,1413244800"; d="scan'208,217";a="112361907" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-1.cisco.com with ESMTP; 12 Jan 2015 10:42:16 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t0CAgGGH021494 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 Jan 2015 10:42:16 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Mon, 12 Jan 2015 04:42:16 -0600 From: "Ali C. Begen (abegen)" To: Jean-Marc Valin Thread-Topic: [payload] draft-ietf-payload-rtp-opus-05: maxaveragebitrate Thread-Index: AdATp89X++FTuPj7QpWp8hHcyPj53ACMooEAA8OQx4AACfM1gP//uHjz//tbzbCACfO8AIAB6bwAgAAnIACAABPZAIAAvOsAgAFhrgCAAe8jAA== Date: Mon, 12 Jan 2015 10:42:15 +0000 Message-ID: References: <548A3FEA.2070400@mozilla.com> <7E6F2FBF-3E29-4608-A9AE-2C5124BCE261@sverigesradio.se> <26b91d07-8e22-4790-b06e-564ee30b071d@cisco.com> <006201d0273f$e708a230$b519e690$@co.in> <1CDC64C8-B130-4FB7-B73A-6F894CB729F0@sverigesradio.se> <54A99858.1030102@mozilla.com> <,> <54A9C9D0.8050002@mozilla.com> <06DA8517-E9D8-4726-8FAE-EB7D4B110674@sverigesradio.se> <54AB90FA.6090900@mozilla.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [10.19.222.164] Content-Type: multipart/alternative; boundary="_000_EFC567A0F1CD43F0ADBFE94BE2626EE3ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "payload@ietf.org" Subject: Re: [payload] draft-ietf-payload-rtp-opus-05: maxaveragebitrate X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 10:42:46 -0000 --_000_EFC567A0F1CD43F0ADBFE94BE2626EE3ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Here goes my chair review on version 06: Section 3.1.2: 1) "network capacity=94 is not the term you are looking for. You need to sa= y something like =93available bandwidth=94. Section 4.2: 1) I suppose in table 2, =93x=94 means not supported or N/A, which should b= e mentioned in the document. What do the empty slots mean? Section 6.1: 1) For "Published specification:", you should not say "none", rather say "R= FC [XXXX]" with an editor note the RFC editor to fix the number upon public= ation. 2) According to the template in rfc 6838, you are missing "Fragment identif= ier considerations", which I believe simply say "N/A." 3) Change controller should be "IETF Payload Working Group delegated from t= he IESG.=94 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 > wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Just posted a new version that brings back maxaveragebitrate exactly as it was before. Cheers, Jean-Marc --_000_EFC567A0F1CD43F0ADBFE94BE2626EE3ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Here goes my chair review on version 06:

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

Section 4.2:
1) I suppose in table 2, =93x=94 means not supported or N/A, which should b= e mentioned in the document. What do the empty slots mean?

Section 6.1:
1) For "Published specification:", you should not say "none&= quot;, 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 id= entifier considerations", which I believe simply say "N/A."<= /div>

3) Change controller should be "IETF Payload Working Group delegated f= rom the IESG.=94

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 <<= a href=3D"mailto:jmvalin@jmvalin.ca">jmvalin@jmvalin.ca> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

Cheers,

Jean-Marc

--_000_EFC567A0F1CD43F0ADBFE94BE2626EE3ciscocom_-- From gunnar.n.persson@ericsson.com Mon Jan 12 02:55:52 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51A9B1A8AD2 for ; Mon, 12 Jan 2015 02:55:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.6 X-Spam-Level: X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VfOxIpd5TDG4 for ; Mon, 12 Jan 2015 02:55:50 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBE791A8ADC for ; Mon, 12 Jan 2015 02:54:47 -0800 (PST) X-AuditID: c1b4fb30-f79106d000001184-c1-54b3a7f5d479 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id ED.BC.04484.5F7A3B45; Mon, 12 Jan 2015 11:54:45 +0100 (CET) Received: from ESESSMB201.ericsson.se ([169.254.1.236]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0195.001; Mon, 12 Jan 2015 11:54:45 +0100 From: Gunnar Persson N To: "payload@ietf.org" Thread-Topic: Question regarding RFC 4867 Thread-Index: AdAuUH857qeNJSTRRZuyvLlMgIMbpA== Date: Mon, 12 Jan 2015 10:54:44 +0000 Message-ID: <7F3814818CC0B04E97C2ADBA62B5C9681C5345D8@ESESSMB201.ericsson.se> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_7F3814818CC0B04E97C2ADBA62B5C9681C5345D8ESESSMB201erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyM+Jvje7X5ZtDDJbc1bW4dPEskwOjx5Il P5kCGKO4bFJSczLLUov07RK4MiadbGMsuK1b0d93mKWBcYpGFyMnh4SAicT6xm1MELaYxIV7 69m6GLk4hASOMErcXvmKCcJZwigxo/0RWBWbgJnEj0NXGbsYOThEBDQlHn0XAgkLC6hINK6c zwhig4RPX7jIBlGiJ/H4WimIySKgKrHgqzNIBa+Ar8TzrzvBqhkFZCXuf7/HAmIzC4hL3Hoy H+ocAYkle84zQ9iiEi8f/2MFGSMhoCQxbWsaRHm+xKMpy9ghRgpKnJz5hGUCo9AsJJNmISmb haQMIq4jsWD3JzYIW1ti2cLXzDD2mQOPmZDFFzCyr2IULU4tTspNNzLSSy3KTC4uzs/Ty0st 2cQIjIaDW34b7GB8+dzxEKMAB6MSD++G8E0hQqyJZcWVuYcYpTlYlMR58xw2hAgJpCeWpGan phakFsUXleakFh9iZOLglGpg5BH9scKo6NSsVrVkx9Zvqqc3cx9ZuUwtO5HjiEyHk8f+t5tM zN44nbbn8dp1w7Fo9vEJGYwLGnlvne9UF9+yi3NC6oQehesc2rl71VOPb+q9/1zIk93gf1c7 j75SvZJIqe5j339ViTO2i234HB1uF9gk0B19l++/1abmsJS37/z1juj+3H9diaU4I9FQi7mo OBEAIu9LrGcCAAA= Archived-At: X-Mailman-Approved-At: Mon, 12 Jan 2015 03:03:17 -0800 Subject: [payload] Question regarding RFC 4867 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 11:01:15 -0000 --_000_7F3814818CC0B04E97C2ADBA62B5C9681C5345D8ESESSMB201erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi I have a simple question regarding RFC 4867 In chapter... 4.3.1. The Payload Head= er ...it is stated: Therefore, if a terminal continuously wishes to receive frames in the same mode X, it needs to set CMR=3DX for all its outbound payloads, and if a terminal has no preference in which mode to receive, it SHOULD set CMR=3D15 in all its outbound payloads. Question: Does "all its outbound payloads" mean "every RTP frame" (I e every 20ms)? Comment: On air interface CMR value is only communicated every second speech frame (= I e every 40ms). I assume the idea is that BSS shall remember the last comm= unicated CMR from mobile terminal and insert this CMR in all RTP frames. Pl= ease comment if my assumption is correct. Best Regards, Gunnar Persson at Ericsson --_000_7F3814818CC0B04E97C2ADBA62B5C9681C5345D8ESESSMB201erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi

I have a simple question regarding RFC 4867

In chapter…

4.3.1.  The Payload Header

…it is stated:
 
Therefore, if a terminal continuously wi=
shes to receive frames in the
   same mode X, it needs to se=
t CMR=3DX for all its outbound payloads, and
   if a terminal has no prefer=
ence in which mode to receive, it SHOULD
   set CMR=3D15 in all its out=
bound payloads.
 

Question:

Does “all its outbound payloads” mean= “every RTP frame” (I e every 20ms)?

 

Comment:

On air interface CMR value is only communicated ever= y second speech frame (I e every 40ms). I assume the idea is that BSS shall= remember the last communicated CMR from mobile terminal and insert this CM= R in all RTP frames. Please comment if my assumption is correct.

 

Best Regards,

Gunnar Persson at Ericsson

--_000_7F3814818CC0B04E97C2ADBA62B5C9681C5345D8ESESSMB201erics_-- From nobody Mon Jan 12 21:14:19 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB221A8A11 for ; Mon, 12 Jan 2015 21:14:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.58 X-Spam-Level: X-Spam-Status: No, score=-1.58 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GE1TDotOHSJY for ; Mon, 12 Jan 2015 21:14:13 -0800 (PST) Received: from mail-qg0-f47.google.com (mail-qg0-f47.google.com [209.85.192.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49D151A89B4 for ; Mon, 12 Jan 2015 21:14:13 -0800 (PST) Received: by mail-qg0-f47.google.com with SMTP id q108so741571qgd.6 for ; Mon, 12 Jan 2015 21:14:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=HqJ1SOQDKh49VK+v31RT73nLHYSJBm+bWLLbTDBrXhc=; b=UomTeO2rLM8ZX/rRNdP00Ie1oxHzw+MDeIXNLCMUdojq0rso4+ilGHc1wRBS9EPDAk WpHmOsfGOIDyu6ZehB3hAYjFaqxfX2U56E39l54fsgDc4FHM+7vIUzqQREK57m7S4lIi pd6tAdgEuHTMfQMrR5mBbMuMMH0T7oFH/MNOtZd8JWAiDsmk9kXMR1HSrbRfiH5TAcKE Hr7p5e0xLceL958oK/DTEB7OBoGhN8VdpQtVRVCMo8lSzTGiFEImTU4qNDsyu0afza9a AV9nHEBMTas/FqYE6r1TCPEEsdddUI2UT9BbGhozbKQUiVnbab7VYU2+vkboPtk1kr6r Vp3A== X-Gm-Message-State: ALoCoQm09iVygYO8uaMZQu8/fTcc3GCgxD57aWy/xFD1OVTxq0qswhh/i3GvG2fzNnRSVwRaYaYF X-Received: by 10.224.137.2 with SMTP id u2mr25119925qat.70.1421126052412; Mon, 12 Jan 2015 21:14:12 -0800 (PST) Received: from panoramix.jmvalin.ca (modemcable074.170-201-24.mc.videotron.ca. [24.201.170.74]) by mx.google.com with ESMTPSA id o34sm16793000qge.29.2015.01.12.21.14.10 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Jan 2015 21:14:11 -0800 (PST) Message-ID: <54B4A9A1.3070202@mozilla.com> Date: Tue, 13 Jan 2015 00:14:09 -0500 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 CC: "payload@ietf.org" References: <548A3FEA.2070400@mozilla.com> <7E6F2FBF-3E29-4608-A9AE-2C5124BCE261@sverigesradio.se> <26b91d07-8e22-4790-b06e-564ee30b071d@cisco.com> <006201d0273f$e708a230$b519e690$@co.in> <1CDC64C8-B130-4FB7-B73A-6F894CB729F0@sverigesradio.se> <54A99858.1030102@mozilla.com> <, > <54A9C9D0.8050002@mozilla.com> <06DA8517-E9D8-4726-8FAE-EB7D4B110674@sverigesradio.se> <54AB90FA.6090900@mozilla.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [payload] draft-ietf-payload-rtp-opus-05: maxaveragebitrate X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 05:14:17 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. > 3) Change controller should be "IETF Payload Working Group > delegated from the IESG.” Will do. Jean-Marc > 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 > > wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> Just posted a new version that brings back maxaveragebitrate >> exactly as it was before. >> >> Cheers, >> >> Jean-Marc > > > > _______________________________________________ payload mailing > list payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUtKmhAAoJEJ6/8sItn9q9MAYH/jMDmvluWLHkc9PuiXFosuvj Ebza1UIdjNU9Eeu6U6IihUYM2XXqf5RaiHZ7XqGDEJaQp2xSF48GJ9Po3lOMnDcI 1mx/MwWA6c8vJhk1EomrdcaD7AxjfII/M54w1+MRbl2Vd8HmJYYK8aPx/73YPMvG YsgmKavC/ERRQTWgmufNiv2EwVwcSn9aynHEICkN6yoI76a66CY6gthXTiKx+Fz9 bFM5Eaf5I8Vx2GZKsFXmvrIV4Y2ps47H8WakmDjTyoGKn5kvNak/6MvGqlNRqld/ Qmn785OoBptq1gZM1krKM95gi5bSknvM56ANDQ9XRY5/RqNceO2ukIj9TXqHJeY= =uwZW -----END PGP SIGNATURE----- From nobody Mon Jan 12 22:42:38 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB5E1A8A16 for ; Mon, 12 Jan 2015 22:42:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x7vuQ0zMdJPj for ; Mon, 12 Jan 2015 22:42:33 -0800 (PST) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FA781A89EB for ; Mon, 12 Jan 2015 22:42:33 -0800 (PST) Received: by mail-we0-f170.google.com with SMTP id w61so1048023wes.1 for ; Mon, 12 Jan 2015 22:42:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=OcMKZWevbZvdluuSQuiAMME5W9bfBMfUvQOkzXuKFMs=; b=tDRm5e6KGuVLL+h25KBK/XAxGdm4LKJkgX2rNrNVGwU1vSvR2lDV943NNLeAYIf13I EP9umIZWFr3O+Vske723CzwQEhehhgjxDnxmBRAYESKPu/uf5ct/zhmgqom7N8YMufDx 46IBpGVVQ1CeCVnUCmFzuzo8X0GG7ACkqz/vIPQkI8O+i0wVuMzATFjgaWYmWeC4HoCj OjhzQBAYU9hQ/AhsURZLys7o86h6nGC07/LHM4yprnpWZRcElVekJR9fKpWpTWTFC9mU FucZ98WPMbheE21a5602rzjeFz3xMhF0ctgeKRGOmGz9Ws8uWEWFq1yGeXJOsPs8o5kT Dajw== X-Received: by 10.181.29.198 with SMTP id jy6mr3407272wid.0.1421131352221; Mon, 12 Jan 2015 22:42:32 -0800 (PST) Received: from RoniE (bzq-79-183-102-161.red.bezeqint.net. [79.183.102.161]) by mx.google.com with ESMTPSA id fw6sm490782wib.1.2015.01.12.22.42.30 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 12 Jan 2015 22:42:31 -0800 (PST) From: "Roni Even" To: Date: Tue, 13 Jan 2015 08:42:28 +0200 Message-ID: <068601d02efc$1ad33530$50799f90$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0687_01D02F0C.DE5CC880" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdAu+5jurQSTx+twSaCD31UiM/ljbQ== Content-Language: en-us Archived-At: Subject: [payload] Call for adoption of RTP Payload Format for Non-Interleaved and Interleaved Parity FEC X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 06:42:36 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0687_01D02F0C.DE5CC880 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, The RTCweb FEC usage is looking for a solution the proposed RTP payload format was presented and got support in the last IETF meeting. We would like to add a milestone for RTP Payload Format for Non-Interleaved and Interleaved Parity FEC and adopt draft-singh-payload-rtp-1d2d-parity-scheme-00 as the proposal for addressing the mile stone. Please provide feedback to the WG chairs by January 23rd Thanks Roni Even Payload WG co-chair ------=_NextPart_000_0687_01D02F0C.DE5CC880 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

The RTCweb FEC = usage is looking for a solution the proposed RTP payload format was = presented and got support in the last IETF meeting. = 

We would =
like to add a milestone for RTP Payload =
Format for Non-Interleaved and Interleaved Parity FEC and adopt =
draft-singh-payload-rtp-1d2d-parity-scheme-00 as the proposal for =
addressing the mile stone.
 =

Please =
provide feedback to the WG chairs by January =
23rd
Thanks=

Roni =
Even
Payload WG =
co-chair
 =
------=_NextPart_000_0687_01D02F0C.DE5CC880-- From nobody Tue Jan 13 01:00:07 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBA421ACE4D for ; Tue, 13 Jan 2015 00:59:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w_Q2pDpX4cYY for ; Tue, 13 Jan 2015 00:59:51 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73FC81ACE4C for ; Tue, 13 Jan 2015 00:59:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4172; q=dns/txt; s=iport; t=1421139588; x=1422349188; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=+2Om7ANQGS5Ln31PZ3lXCA8g+iNihMQrpbSqhN++4mk=; b=Os5giZhMcBTLiteKqnxH3X2+vnwKtN1ZZ50K8CK93JZ7FR2bF3S+isCS gRkha1IezHZX6lutb85IoHPMAxMroD1Tdv0aDd0yVJ87gbN1mQWSrS2E1 vGs9qXrFI8t+Asg9MNN5SVWzni7E3H75hHvgTeA8strgkze5N6GC3oCyM I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuULAE7etFStJA2H/2dsb2JhbABbgmQiUlgEgjpHwwEKhSdGAgICHHZDAQEBAQF9hAwBAQEDAQEBAQkXEToLDAQCAQYCEQMBAgECAiMDAgICJQsUAQgIAgQBDQWIJAgBDJw7nGqTZwEBAQEBAQEBAQEBAQEBAQEBAQEBARMEgSGOPRsHBoJigUEFjGKBW4kNkXgiggEdgVBvgUV+AQEB X-IronPort-AV: E=Sophos;i="5.07,748,1413244800"; d="scan'208";a="112708139" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-1.cisco.com with ESMTP; 13 Jan 2015 08:59:47 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t0D8xlRT024885 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 13 Jan 2015 08:59:47 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0195.001; Tue, 13 Jan 2015 02:59:46 -0600 From: "Ali C. Begen (abegen)" To: Jean-Marc Valin , Jean-Marc Valin Thread-Topic: [payload] draft-ietf-payload-rtp-opus-05: maxaveragebitrate Thread-Index: AdATp89X++FTuPj7QpWp8hHcyPj53ACMooEAA8OQx4AACfM1gP//uHjz//tbzbCACfO8AIAB6bwAgAAnIACAABPZAIAAvOsAgAFhrgCAAe8jAIAI5gQAgABjXoA= Date: Tue, 13 Jan 2015 08:59:46 +0000 Message-ID: References: <548A3FEA.2070400@mozilla.com> <7E6F2FBF-3E29-4608-A9AE-2C5124BCE261@sverigesradio.se> <26b91d07-8e22-4790-b06e-564ee30b071d@cisco.com> <006201d0273f$e708a230$b519e690$@co.in> <1CDC64C8-B130-4FB7-B73A-6F894CB729F0@sverigesradio.se> <54A99858.1030102@mozilla.com> <54A9C9D0.8050002@mozilla.com> <06DA8517-E9D8-4726-8FAE-EB7D4B110674@sverigesradio.se> <54AB90FA.6090900@mozilla.com> <54B4A744.7080009@mozilla.com> In-Reply-To: <54B4A744.7080009@mozilla.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [10.19.222.164] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "payload@ietf.org" Subject: Re: [payload] draft-ietf-payload-rtp-opus-05: maxaveragebitrate X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 08:59:58 -0000 SGkgSk0sDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBKZWFuLU1hcmMgVmFs aW4gPGp2YWxpbkBtb3ppbGxhLmNvbT4NCkRhdGU6IFR1ZXNkYXksIEphbnVhcnkgMTMsIDIwMTUg YXQgNzowNCBBTQ0KVG86ICJBbGkgQy4gQmVnZW4iIDxhYmVnZW5AY2lzY28uY29tPiwgSmVhbi1N YXJjIFZhbGluIDxqbXZhbGluQGptdmFsaW4uY2E+DQpDYzogInBheWxvYWRAaWV0Zi5vcmciIDxw YXlsb2FkQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtwYXlsb2FkXSBkcmFmdC1pZXRmLXBheWxv YWQtcnRwLW9wdXMtMDU6IG1heGF2ZXJhZ2ViaXRyYXRlDQoNCj4tLS0tLUJFR0lOIFBHUCBTSUdO RUQgTUVTU0FHRS0tLS0tDQo+SGFzaDogU0hBMQ0KPg0KPkhpIEFsaSwNCj4NCj5PbiAxMi8wMS8x NSAwNTo0MiBBTSwgQWxpIEMuIEJlZ2VuIChhYmVnZW4pIHdyb3RlOg0KPj4gU2VjdGlvbiAzLjEu MjogMSkgIm5ldHdvcmsgY2FwYWNpdHnigJ0gaXMgbm90IHRoZSB0ZXJtIHlvdSBhcmUNCj4+IGxv b2tpbmcgZm9yLiBZb3UgbmVlZCB0byBzYXkgc29tZXRoaW5nIGxpa2Ug4oCcYXZhaWxhYmxlIGJh bmR3aWR0aOKAnS4NCj4NCj5Ib3cgYWJvdXQgImF2YWlsYWJsZSBuZXR3b3JrIGJhbmR3aWR0aCIg c2luY2Ugd2UgdXNlICJiYW5kd2lkdGgiDQo+bWFpbmx5IGZvciBhdWRpbyBmcmVxdWVuY2llcyBp biB0aGlzIGRyYWZ0Pw0KDQpZZXMsIGJldHRlci4NCg0KPg0KPj4gU2VjdGlvbiA0LjI6IDEpIEkg c3VwcG9zZSBpbiB0YWJsZSAyLCDigJx44oCdIG1lYW5zIG5vdCBzdXBwb3J0ZWQgb3INCj4+IE4v QSwgd2hpY2ggc2hvdWxkIGJlIG1lbnRpb25lZCBpbiB0aGUgZG9jdW1lbnQuIFdoYXQgZG8gdGhl IGVtcHR5DQo+PiBzbG90cyBtZWFuPw0KPg0KPkFjdHVhbGx5ICJ4IiBtZWFucyBzdXBwb3J0ZWQg YW5kIHRoZSBvbmVzIHdpdGhvdXQgYW4gIngiIGFyZW4ndA0KPnN1cHBvcnRlZC4gSSBndWVzcyB0 aGF0IHdhc24ndCBjbGVhci4gTWF5YmUgIm8iIGZvciBzdXBwb3J0ZWQgYW5kICJ4Ig0KPmZvciBu b3Qgc3VwcG9ydGVkPyBPciBkbyB5b3UgaGF2ZSBvdGhlciBzdWdnZXN0aW9ucz8NCg0KWWVhaCwg dGhhdCBpcyB3aGF0IEkgbWVhbnQuIEkgZG9udCBjYXJlIG11Y2ggYWJvdXQgdGhlIHggdnMgbyBh cyBsb25nIGFzDQp0aGV5IGFyZSBleHBsYWluZWQgaW4gdGhlIHRleHQuIEJ1dCBJ4oCZZCBwcmVm ZXIg4oCceOKAnSB0byBkZW5vdGUg4oCcbm8gc3VwcG9ydOKAnS4NCg0KPg0KPj4gU2VjdGlvbiA2 LjE6IDEpIEZvciAiUHVibGlzaGVkIHNwZWNpZmljYXRpb246IiwgeW91IHNob3VsZCBub3Qgc2F5 DQo+PiAibm9uZSIsIHJhdGhlciBzYXkgIlJGQyBbWFhYWF0iIHdpdGggYW4gZWRpdG9yIG5vdGUg dGhlIFJGQyBlZGl0b3INCj4+IHRvIGZpeCB0aGUgbnVtYmVyIHVwb24gcHVibGljYXRpb24uDQo+ DQo+Tm90IHN1cmUgd2hhdCB5b3UgbWVhbiBoZXJlLg0KDQpKdXN0IHJlcGxhY2UgdGhlIHRleHQg d2l0aDoNCg0KUHVibGlzaGVkIHNwZWNpZmljYXRpb246IFJGQyBbWFhYWF0NCk5vdGUgdG8gdGhl IFJGQyBFZGl0b3I6IFJlcGxhY2UgW1hYWFhdIHdpdGggdGhlIG51bWJlciBvZiB0aGUgcHVibGlz aGVkDQpSRkMuDQoNCj4NCj4+IDIpIEFjY29yZGluZyB0byB0aGUgdGVtcGxhdGUgaW4gcmZjIDY4 MzgsIHlvdSBhcmUgbWlzc2luZw0KPj4gIkZyYWdtZW50IGlkZW50aWZpZXIgY29uc2lkZXJhdGlv bnMiLCB3aGljaCBJIGJlbGlldmUgc2ltcGx5IHNheQ0KPj4gIk4vQS4iDQo+DQo+V2lsbCBkby4N Cj4NCj4+IDMpIENoYW5nZSBjb250cm9sbGVyIHNob3VsZCBiZSAiSUVURiBQYXlsb2FkIFdvcmtp bmcgR3JvdXANCj4+IGRlbGVnYXRlZCBmcm9tIHRoZSBJRVNHLuKAnQ0KPg0KPldpbGwgZG8uDQo+ DQo+CUplYW4tTWFyYw0KDQpKdXN0IG1ha2UgdGhlc2UgY2hhbmdlcyBhbmQgSSB3aWxsIGFzayBv dXIgQUQgdG8gcHJvY2VzcyB0aGlzLg0KDQpUaGFua3MuDQoNCj4NCj4+IFdlIHNob3VsZCBiZSBy ZWFkeSB0byBzaGlwIHRoaXMgZHJhZnQgb25jZSB0aGUgYWJvdmUgaXMgYWRkcmVzc2VkLg0KPj4g LWFjYmVnZW4NCj4+IA0KPj4gDQo+Pj4gT24gSmFuIDYsIDIwMTUsIGF0IDk6MzggQU0sIEplYW4t TWFyYyBWYWxpbiA8am12YWxpbkBqbXZhbGluLmNhDQo+Pj4gPG1haWx0bzpqbXZhbGluQGptdmFs aW4uY2E+PiB3cm90ZToNCj4+PiANCj4+PiAtLS0tLUJFR0lOIFBHUCBTSUdORUQgTUVTU0FHRS0t LS0tIEhhc2g6IFNIQTENCj4+PiANCj4+PiBKdXN0IHBvc3RlZCBhIG5ldyB2ZXJzaW9uIHRoYXQg YnJpbmdzIGJhY2sgbWF4YXZlcmFnZWJpdHJhdGUNCj4+PiBleGFjdGx5IGFzIGl0IHdhcyBiZWZv cmUuDQo+Pj4gDQo+Pj4gQ2hlZXJzLA0KPj4+IA0KPj4+IEplYW4tTWFyYw0KPj4gDQo+PiANCj4+ IA0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gcGF5 bG9hZCBtYWlsaW5nDQo+PiBsaXN0IHBheWxvYWRAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF5bG9hZA0KPj4gDQo+LS0tLS1CRUdJTiBQR1AgU0lH TkFUVVJFLS0tLS0NCj5WZXJzaW9uOiBHbnVQRyB2MQ0KPg0KPmlRRWNCQUVCQWdBR0JRSlV0S2RC QUFvSkVKNi84c0l0bjlxOUM4WUgvaVhpOTlBblJlYnhNc1RqQTd3ZHRSVkYNCj5vNVZrMUNtanc1 NVV3MmFtakxCeTNHKzV5WU1aMXVRRm5ESVFrSSsyV3dEY1pJUGN4V290QVVGM1BhanlNVzBmDQo+ eWlzZGVLeGkzdCtCTWFiclFtSlZnM011TTZiQXhOOWhZdFYzbzRHNitQQ1dNNi8xcjBFSDFMUHNq M0VLQUo4WQ0KPlhxeHJhOTVITVRlNG5kcDdSRU5KWGFNblNKZVBETHdNb1hpMGVLWVN1Vjc5alNo UFk2U3ZndVZtU0h4ZTNGeDENCj5mWk1tZi9rVHBTeE1oTzdmMXJZM0tlai94ZTF6U0Y3TGZpS1FC RXM3bzRGaGx1bUVRbDFoVytCQk82bHJ6RC95DQo+Smpqc00vaDBIclkvS0JRN0sxNXdKT2lNb1R2 cW55dHlJZTRTTkFiN2M5QTJ6Tkd6NFFqbzllSms2WjBkZkhVPQ0KPj1aVUlwDQo+LS0tLS1FTkQg UEdQIFNJR05BVFVSRS0tLS0tDQo+DQoNCg0K From nobody Tue Jan 13 04:51:29 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB591A8AB9 for ; Tue, 13 Jan 2015 04:51:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.277 X-Spam-Level: X-Spam-Status: No, score=-3.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-2.3, SPF_FAIL=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nk_aGdD61vtY for ; Tue, 13 Jan 2015 04:51:25 -0800 (PST) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF92D1A1B7D for ; Tue, 13 Jan 2015 04:51:25 -0800 (PST) Received: from [10.1.6.254] (unknown [131.203.247.184]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 95893F2680 for ; Tue, 13 Jan 2015 04:51:24 -0800 (PST) Message-ID: <54B514C9.8010405@xiph.org> Date: Tue, 13 Jan 2015 04:51:21 -0800 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26 MIME-Version: 1.0 To: payload@ietf.org References: <068601d02efc$1ad33530$50799f90$@gmail.com> In-Reply-To: <068601d02efc$1ad33530$50799f90$@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [payload] Call for adoption of RTP Payload Format for Non-Interleaved and Interleaved Parity FEC X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 12:51:28 -0000 Roni Even wrote: > We would like to add a milestone forRTP Payload Format for Non-Interleaved and Interleaved Parity FEC and adoptdraft-singh-payload-rtp-1d2d-parity-scheme-00 as the proposal for addressing the mile stone. I think we should do both of these things. From nobody Tue Jan 13 05:28:58 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E99111A8A1E for ; Mon, 12 Jan 2015 22:54:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UtLTQ39obEZS for ; Mon, 12 Jan 2015 22:54:11 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 30D821A8A1F for ; Mon, 12 Jan 2015 22:54:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: payload@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150113065410.16621.7035.idtracker@ietfa.amsl.com> Date: Mon, 12 Jan 2015 22:54:10 -0800 From: IETF Secretariat Archived-At: X-Mailman-Approved-At: Tue, 13 Jan 2015 05:28:57 -0800 Subject: [payload] Milestones changed for payload WG X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 06:54:13 -0000 Changed milestone "Submit RTP Payload Format for Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW) for Proposed Standard", resolved as "Done". Changed milestone "Submit RTP profile for the carriage of SMPTE 336M data for Proposed Standard", resolved as "Done". Changed milestone "Submit How to Write an RTP Payload Format for Informational", resolved as "Done". Changed milestone "Submit RTP Payload Format for VP8 Video for Proposed Standard", resolved as "Done". Changed milestone "Submit RTP Payload Format for Standard apt-X and Enhanced apt-X Codecs for Proposed Standard", resolved as "Done". Changed milestone "Submit RTP Payload Format for G.711.0 for Proposed Standard", resolved as "Done". Changed milestone "Submit RTP Payload Format for High Efficiency Video Coding for Proposed Standard.", resolved as "Done". Changed milestone "Submit RTP Payload Format for Opus Speech and Audio Codec as proposed standard", set due date to March 2015 from December 2012. URL: http://datatracker.ietf.org/wg/payload/charter/ From nobody Tue Jan 13 06:21:03 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F3381A8BB0; Tue, 13 Jan 2015 06:20:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Ra1ILHiZDgk; Tue, 13 Jan 2015 06:20:56 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D13A1A8AF2; Tue, 13 Jan 2015 06:20:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150113142056.4691.73296.idtracker@ietfa.amsl.com> Date: Tue, 13 Jan 2015 06:20:56 -0800 Archived-At: Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-opus-07.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 14:20:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Payloads Working Group of the IETF. Title : RTP Payload Format for Opus Speech and Audio Codec Authors : Julian Spittka Koen Vos Jean-Marc Valin Filename : draft-ietf-payload-rtp-opus-07.txt Pages : 17 Date : 2015-01-13 Abstract: This document defines the Real-time Transport Protocol (RTP) payload format for packetization of Opus encoded speech and audio data necessary to integrate the codec in the most compatible way. Further, it describes media type registrations for the RTP payload format. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-opus/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-payload-rtp-opus-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-payload-rtp-opus-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jan 13 06:22:53 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71AAF1A8AF9 for ; Tue, 13 Jan 2015 06:22:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UGx_Fba0Pt-G for ; Tue, 13 Jan 2015 06:22:34 -0800 (PST) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 647AC1A8AFE for ; Tue, 13 Jan 2015 06:22:34 -0800 (PST) Received: by mail-qa0-f42.google.com with SMTP id dc16so2232176qab.1 for ; Tue, 13 Jan 2015 06:22:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=HiX7lZ35GStAaOmBJ12XpVBIuBbY+aRc9xLrPX+JvYA=; b=DDoypfYdZampk2L+/dD1wm1gkBuHb9yMKkM3hrus3TvQ3o0Uw3IxzZpGHksENnB+hI PHIrJeRQVw5X9T9sm4OmZCGRuakyTSk8bhcXw3QZonwsFW05piNbBEl4pWfk5YOpGtDR 0VNxvcZayLBFUJ0UdE1WjvL/82QryMcCnjeyWfD7G8uCuJbNbmsaUZ4/3uzHmY2OneR6 zu0VtwRJTBM/RHz2BydaAHyVM6pyzteHwAKYVyIGp90KWwSV1YWFPvKyFFjRpEMSxVXC xM8BLFEQ7J2eiZguh3BuYQUc9G9yzcnUfRd5Mfc4kxk/2nU3uQ+WHIPREwrq9HqDHzFj +uiw== X-Gm-Message-State: ALoCoQnr/d/pafOYvy4Vgz4Sptb5+xJMbzZGDosJBsSPROBgl7VUKbT5/2/zUaKpz8q8eUm0GRoy X-Received: by 10.140.96.195 with SMTP id k61mr55160324qge.104.1421158953573; Tue, 13 Jan 2015 06:22:33 -0800 (PST) Received: from panoramix.jmvalin.ca (modemcable074.170-201-24.mc.videotron.ca. [24.201.170.74]) by mx.google.com with ESMTPSA id y95sm17748010qgy.14.2015.01.13.06.22.31 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Jan 2015 06:22:32 -0800 (PST) Message-ID: <54B52A26.9000400@mozilla.com> Date: Tue, 13 Jan 2015 09:22:30 -0500 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" , Jean-Marc Valin References: <548A3FEA.2070400@mozilla.com> <7E6F2FBF-3E29-4608-A9AE-2C5124BCE261@sverigesradio.se> <26b91d07-8e22-4790-b06e-564ee30b071d@cisco.com> <006201d0273f$e708a230$b519e690$@co.in> <1CDC64C8-B130-4FB7-B73A-6F894CB729F0@sverigesradio.se> <54A99858.1030102@mozilla.com> <, > <54A9C9D0.8050002@mozilla.com> <06DA8517-E9D8-4726-8FAE-EB7D4B110674@sverigesradio.se> <54AB90FA.6090900@mozilla.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: "payload@ietf.org" Subject: Re: [payload] draft-ietf-payload-rtp-opus-05: maxaveragebitrate X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 14:22:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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: > 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 > > wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> Just posted a new version that brings back maxaveragebitrate >> exactly as it was before. >> >> Cheers, >> >> Jean-Marc > > > > _______________________________________________ payload mailing > list payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUtSogAAoJEJ6/8sItn9q9JycIAKIhrX20JBSUBVv81rvQPZOI Wdm8F7+28y2tIgnVWeUTzz7FByRsMFR90MNJRigNPlWfATpdHCxvjT/nC/Mo3MwK PUM7uvJqqDD6bo8FYMdRGYMFN4Ej3mEAq5Xvl+PTHwwh4N/pJW14UcifiBkwKTti kBTU80yHYAhUwTAODwbu7mqUE/WU8WQfboEpRpvZc3yte+jbUHQ6kPwJq6+yaeKi V/7T6icWte9yVEeuqkA8/vW3vI6YVc/PZyDX/fb0RLWPfF+kCzb1S6MhHb6lFhQD 5YukRKUayPB8GQ0L257ysfFxxRrtU/RTqbSvz8xPJMvZJqiWlWfE3qqyNs36gjY= =0yI5 -----END PGP SIGNATURE----- From nobody Tue Jan 13 09:49:56 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67CF71A8BB2 for ; Tue, 13 Jan 2015 09:49:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ga3OeJE8yXb5 for ; Tue, 13 Jan 2015 09:49:50 -0800 (PST) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0886D1A902D for ; Tue, 13 Jan 2015 09:49:49 -0800 (PST) Received: by mail-ie0-f180.google.com with SMTP id rp18so4147734iec.11 for ; Tue, 13 Jan 2015 09:49:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ycz7/wIJimfaB4mCL1TM51IfFvvzQTHovKsA/ZBVBSY=; b=LzXIs31jQrdo3iP4PKWcmzte+WbLGBmXe1WpBNIoqoBGi0CqFFiMEi6Qtvx+cRK9FO u6EkIXbpSBB3ALCZhMKVziZW7LbLkOP6NHC5PnQfnJdSuCVo3g/t3IOC5EB8IuGjogmE /wCjPA+pPmn8G8VYCTPwt8ODDMWM1JnqDPmdqDLa1zircHlG+jHho5OB1vGRKgmnL9kV 8QCcWimHSJVPZfz8UF4JqFh6ZYJOkedmZXKGUL3yBxE2lC+gGCeO7RwSSo51yc4rUg0o IuXxBBy0BNOtLAxLOMJ00hrToz/PZH1Y/s4L+0eqXcyySj+Wp5VVtu1tegulz2IuURz3 lzLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ycz7/wIJimfaB4mCL1TM51IfFvvzQTHovKsA/ZBVBSY=; b=Z5pKvnQstoyfQJKRqkCO7nf3iAlLltottqQBE2iN2DwTRMs0bk6DhVMIlCzh/Z05GD Y83nEtQrCEs7lAVNUUMxk2DdMSn2nUYBsE19Flujv2H3Ean7VuIcOdhctyHbI2f85876 bpaD08vrpussIT9SW+xy0uI5X2pkA5zNNVhYXM8Q2AJHlb66AhzIp5DTAs6JkFwB7sZd eQ8ozicELFdkIhlcWkYIynlW8sLqvjMC4mSga8+3cXMV45yOe8PnOA6jubymlNFFEUIh 6KTXNOXZO36Zznslq01T7Ds0UaETPIwsxjOEaSyPuIxBrCrqHBwbFKlfTe8FOLsDTYoZ 6Qrw== X-Gm-Message-State: ALoCoQn+ZUCHo5+ORjxpu14q75BSulJlHw7vDbmPyNk5TJDX8nmxUVEzmBdbrmMXUCZcDZwYk9g2 X-Received: by 10.50.2.38 with SMTP id 6mr724781igr.36.1421171389130; Tue, 13 Jan 2015 09:49:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.59.40 with HTTP; Tue, 13 Jan 2015 09:49:28 -0800 (PST) In-Reply-To: <54B514C9.8010405@xiph.org> References: <068601d02efc$1ad33530$50799f90$@gmail.com> <54B514C9.8010405@xiph.org> From: Justin Uberti Date: Tue, 13 Jan 2015 09:49:28 -0800 Message-ID: To: "Timothy B. Terriberry" Content-Type: multipart/alternative; boundary=089e0115fc9ed09b25050c8c3ff5 Archived-At: Cc: payload@ietf.org Subject: Re: [payload] Call for adoption of RTP Payload Format for Non-Interleaved and Interleaved Parity FEC X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 17:49:54 -0000 --089e0115fc9ed09b25050c8c3ff5 Content-Type: text/plain; charset=UTF-8 On Tue, Jan 13, 2015 at 4:51 AM, Timothy B. Terriberry wrote: > Roni Even wrote: > >> We would like to add a milestone forRTP Payload Format for >> Non-Interleaved and Interleaved Parity FEC and adoptdraft-singh-payload-rtp-1d2d-parity-scheme-00 >> as the proposal for addressing the mile stone. >> > > I think we should do both of these things. > I agree. > > --089e0115fc9ed09b25050c8c3ff5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jan 13, 2015 at 4:51 AM, Timothy B. Terriberry <tterribe@xiph.= org> wrote:
Roni Even wrote= :
We would like to add a milestone forRTP Payload Format for Non-Interleaved = and Interleaved Parity FEC and adoptdraft-singh-payload-rtp-1d2d-par= ity-scheme-00 as the proposal for addressing the mile stone.

I think we should do both of these things.

<= div>I agree.=C2=A0

--089e0115fc9ed09b25050c8c3ff5-- From nobody Tue Jan 13 17:38:11 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3A8C1ACE42 for ; Tue, 13 Jan 2015 17:38:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_AFFORDABLE=1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xxlpTnFfAIPd for ; Tue, 13 Jan 2015 17:38:05 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0671.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:671]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E59CB1A8746 for ; Tue, 13 Jan 2015 17:38:04 -0800 (PST) Received: from BLUPR05MB659.namprd05.prod.outlook.com (10.141.205.144) by BLUPR05MB657.namprd05.prod.outlook.com (10.141.205.142) with Microsoft SMTP Server (TLS) id 15.1.53.17; Wed, 14 Jan 2015 01:37:40 +0000 Received: from BLUPR05MB659.namprd05.prod.outlook.com ([10.141.205.144]) by BLUPR05MB659.namprd05.prod.outlook.com ([10.141.205.144]) with mapi id 15.01.0053.000; Wed, 14 Jan 2015 01:37:40 +0000 From: Thomas Edwards To: "payload@ietf.org" Thread-Topic: new I-D draft-edwards-rtp-ancillary RTP Payload for SMPTE ST 291 Ancillary Data Thread-Index: AQHQL5quGtaZ7oBEiEudnxYs/ccOvg== Date: Wed, 14 Jan 2015 01:37:39 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.5.141003 x-originating-ip: [104.173.220.231] authentication-results: spf=none (sender IP is ) smtp.mailfrom=Thomas.Edwards@fox.com; x-dmarcaction-test: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:BLUPR05MB657; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB657; x-forefront-prvs: 04569283F9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(189002)(199003)(377424004)(54356999)(122556002)(19617315012)(105586002)(2351001)(40100003)(106116001)(229853001)(107886001)(99286002)(101416001)(106356001)(16236675004)(83506001)(19580395003)(19580405001)(46102003)(87936001)(86362001)(2656002)(2900100001)(50986999)(450100001)(62966003)(77156002)(92566002)(110136001)(2501002)(102836002)(15975445007)(230783001)(66066001)(77096005)(64706001)(36756003); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB657; H:BLUPR05MB659.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: fox.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_D0DB04C22D344thomasedwardsfoxcom_" MIME-Version: 1.0 X-OriginatorOrg: fox.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jan 2015 01:37:39.7220 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: de99ade3-81db-4070-ae0d-3c1562041b30 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB657 Archived-At: Subject: [payload] new I-D draft-edwards-rtp-ancillary RTP Payload for SMPTE ST 291 Ancillary Data X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2015 01:38:08 -0000 --_000_D0DB04C22D344thomasedwardsfoxcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Payload WG, I have submitted a new I-D (draft-edwards-rtp-ancillary) defining an RTP Pa= yload for SMPTE ST 291 Ancillary Data. SMPTE Ancillary data is used in today's professional serial digital video f= ormats to carry a range of ancillary data types, including time code, KLV m= etadata, Closed Captioning, and the Active Format Description (AFD). The broadcast industry is preparing to move from the use of serial digital = video over coax to "all-IP" professional networked media inside our broadca= st plants. Two of the needed standards have been there for years waiting f= or affordable 10 GbE networks. IETF has already standardized RTP carriage = of uncompressed video in RFC 4175, and 24-bit uncompressed audio in RFC 319= 0 (as referenced by AES67). The one remaining item needed is a way of carrying SMPTE ancillary data ove= r RTP, which this I-D should address. The I-D has already been through an informal review by SMPTE 32NF, and I ha= ve worked in the comments received. I do not expect that this process will= require formal liaison with between IETF and SMPTE. The data model used f= or the Ancillary data in RTP is based on an existing SMPTE standard to carr= y Ancillary data over MPEG transport stream, so fortunately most of the "he= avy lifting" on the data model design has already been done. A new version of I-D, draft-edwards-rtp-ancillary-00.txt has been successfully submitted by Thomas G. Edwards and posted to the IETF repository. Name: draft-edwards-rtp-ancillary Revision: 00 Title: RTP Payload for SMPTE ST 291 Ancillary Data Document date: 2015-01-13 Group: Individual Submission Pages: 11 URL: http://www.ietf.org/internet-drafts/draft-edwards-rtp-ancil= lary-00.txt Status: https://datatracker.ietf.org/doc/draft-edwards-rtp-ancillar= y/ Htmlized: http://tools.ietf.org/html/draft-edwards-rtp-ancillary-00 Abstract: This memo describes an RTP Payload format for SMPTE Ancillary data, as defined by SMPTE ST 291-1. SMPTE Ancillary data is generally used along with professional video formats to carry a range of ancillary data types, including time code, KLV metadata, Closed Captioning, and the Active Format Description (AFD). -Thomas -- Thomas Edwards VP Engineering & Development FOX Network Engineering and Operations thomas.edwards@fox.com Phone: +1.310.369.6696 10201 West Pico Blvd. Los Angeles, CA 90035 --_000_D0DB04C22D344thomasedwardsfoxcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <0C9A43B16829A846BB06112A7DF9F445@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Dear Payload WG,

I have submitted a new I-D (draft-edwards-rtp-ancillary) defining an R= TP Payload for SMPTE ST 291 Ancillary Data.

SMPTE Ancillary data is used in today's professional serial digital vi= deo formats to carry a range of ancillary data types, including time code, = KLV metadata, Closed Captioning, and the Active Format Description (AFD).

The broadcast industry is preparing to move from the use of serial dig= ital video over coax to "all-IP" professional networked media ins= ide our broadcast plants.  Two of the needed standards have been there= for years waiting for affordable 10 GbE networks.  IETF has already standardized RTP carriage of uncompressed video in = RFC 4175, and 24-bit uncompressed audio in RFC 3190 (as referenced by AES67= ). 

The one remaining item needed is a way of carrying SMPTE ancillary dat= a over RTP, which this I-D should address.

The I-D has already been through an informal review by SMPTE 32NF, and= I have worked in the comments received.  I do not expect that this pr= ocess will require formal liaison with between IETF and SMPTE.  The da= ta model used for the Ancillary data in RTP is based on an existing SMPTE standard to carry Ancillary data over MPEG t= ransport stream, so fortunately most of the "heavy lifting" on th= e data model design has already been done.

A new version of I-D, draft-edwards-rtp-ancillary-00.txt
has been successfully submitted by Thomas G. Edwards and posted to the=
IETF repository.

Name: = draft-edwar= ds-rtp-ancillary
Revision: 00
Title: RTP Payloa= d for SMPTE ST 291 Ancillary Data
Document date: 2015-01-13
Group: Individual= Submission
Pages: 11


Abstract:
   This memo describes an RTP Payload format for SMPTE Ancil= lary data,
   as defined by SMPTE ST 291-1.  SMPTE Ancillary = data is generally used
   along with professional video formats to carry a range of= ancillary
   data types, including time code, KLV metadata, Closed Cap= tioning, and
   the Active Format Description (AFD).

-Thomas

--
Thomas Edwards
VP Engineering & Development
FOX Network Engineering and Operations
thomas.edwards@fox.com
Phone: +1.310.369.6696
10201 West Pico Blvd.
Los Angeles, CA 90035

--_000_D0DB04C22D344thomasedwardsfoxcom_-- From nobody Wed Jan 14 15:21:41 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F16901ACEA7 for ; Wed, 14 Jan 2015 15:21:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_AFFORDABLE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id acwHWOq94xmx for ; Wed, 14 Jan 2015 15:21:31 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0064.outbound.protection.outlook.com [65.55.169.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E6041ACF1D for ; Wed, 14 Jan 2015 15:21:30 -0800 (PST) Received: from BLUPR05MB659.namprd05.prod.outlook.com (10.141.205.144) by BLUPR05MB660.namprd05.prod.outlook.com (10.141.205.153) with Microsoft SMTP Server (TLS) id 15.1.53.17; Wed, 14 Jan 2015 23:21:28 +0000 Received: from BLUPR05MB659.namprd05.prod.outlook.com ([10.141.205.144]) by BLUPR05MB659.namprd05.prod.outlook.com ([10.141.205.144]) with mapi id 15.01.0053.000; Wed, 14 Jan 2015 23:21:28 +0000 From: Thomas Edwards To: "payload@ietf.org" Thread-Topic: new I-D draft-edwards-rtp-ancillary RTP Payload for SMPTE ST 291 Ancillary Data Thread-Index: AQHQL5quGtaZ7oBEiEudnxYs/ccOvpy/vE2A Date: Wed, 14 Jan 2015 23:21:28 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.5.141003 x-originating-ip: [216.205.246.242] authentication-results: spf=none (sender IP is ) smtp.mailfrom=Thomas.Edwards@fox.com; x-dmarcaction-test: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:BLUPR05MB660; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB660; x-forefront-prvs: 04569283F9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(377454003)(199003)(189002)(377424004)(230783001)(19617315012)(110136001)(106356001)(106116001)(105586002)(62966003)(2501002)(40100003)(16236675004)(99286002)(36756003)(122556002)(2351001)(107886001)(92566002)(15975445007)(68736005)(102836002)(86362001)(2900100001)(450100001)(77096005)(64706001)(97736003)(16297215004)(2950100001)(46102003)(77156002)(54356999)(50986999)(76176999)(66066001)(83506001)(19580395003)(19580405001)(87936001)(2656002)(101416001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB660; H:BLUPR05MB659.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fox.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_D0DC397D2D475thomasedwardsfoxcom_" MIME-Version: 1.0 X-OriginatorOrg: fox.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jan 2015 23:21:28.2645 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: de99ade3-81db-4070-ae0d-3c1562041b30 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB660 Archived-At: Subject: Re: [payload] new I-D draft-edwards-rtp-ancillary RTP Payload for SMPTE ST 291 Ancillary Data X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2015 23:21:34 -0000 --_000_D0DC397D2D475thomasedwardsfoxcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Payload WG, On the advice of the Payload WG chairs, I have re-submitted this I-D under = the name "draft-edwards-payload-rtp-ancillary" so that it properly shows up= in the Payload WG list of individual submissions. http://datatracker.ietf.org/doc/draft-edwards-payload-rtp-ancillary/ -Thomas From: FNG > Date: Tuesday, January 13, 2015 at 5:37 PM To: "payload@ietf.org" > Subject: new I-D draft-edwards-rtp-ancillary RTP Payload for SMPTE ST 291 A= ncillary Data Dear Payload WG, I have submitted a new I-D (draft-edwards-rtp-ancillary) defining an RTP Pa= yload for SMPTE ST 291 Ancillary Data. SMPTE Ancillary data is used in today's professional serial digital video f= ormats to carry a range of ancillary data types, including time code, KLV m= etadata, Closed Captioning, and the Active Format Description (AFD). The broadcast industry is preparing to move from the use of serial digital = video over coax to "all-IP" professional networked media inside our broadca= st plants. Two of the needed standards have been there for years waiting f= or affordable 10 GbE networks. IETF has already standardized RTP carriage = of uncompressed video in RFC 4175, and 24-bit uncompressed audio in RFC 319= 0 (as referenced by AES67). The one remaining item needed is a way of carrying SMPTE ancillary data ove= r RTP, which this I-D should address. The I-D has already been through an informal review by SMPTE 32NF, and I ha= ve worked in the comments received. I do not expect that this process will= require formal liaison with between IETF and SMPTE. The data model used f= or the Ancillary data in RTP is based on an existing SMPTE standard to carr= y Ancillary data over MPEG transport stream, so fortunately most of the "he= avy lifting" on the data model design has already been done. A new version of I-D, draft-edwards-rtp-ancillary-00.txt has been successfully submitted by Thomas G. Edwards and posted to the IETF repository. Name: draft-edwards-rtp-ancillary Revision: 00 Title: RTP Payload for SMPTE ST 291 Ancillary Data Document date: 2015-01-13 Group: Individual Submission Pages: 11 URL: http://www.ietf.org/internet-drafts/draft-edwards-rtp-ancil= lary-00.txt Status: https://datatracker.ietf.org/doc/draft-edwards-rtp-ancillar= y/ Htmlized: http://tools.ietf.org/html/draft-edwards-rtp-ancillary-00 Abstract: This memo describes an RTP Payload format for SMPTE Ancillary data, as defined by SMPTE ST 291-1. SMPTE Ancillary data is generally used along with professional video formats to carry a range of ancillary data types, including time code, KLV metadata, Closed Captioning, and the Active Format Description (AFD). -Thomas -- Thomas Edwards VP Engineering & Development FOX Network Engineering and Operations thomas.edwards@fox.com Phone: +1.310.369.6696 10201 West Pico Blvd. Los Angeles, CA 90035 --_000_D0DC397D2D475thomasedwardsfoxcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <95EC92D0CA85DE469A99285ADBF49B6F@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Dear Payload WG,

On the advice of the Payload WG chairs, I have re-submitted this I-D u= nder the name "draft-edwards-payload-rtp-ancillary" so that it pr= operly shows up in the Payload WG list of individual submissions.


-Thomas

From: FNG <thomas.edwards@fox.com>
Date: Tuesday, January 13, 2015 at = 5:37 PM
To: "payload@ietf.org" <payload@ietf.org>
Subject: new I-D draft-edwards-rtp-= ancillary RTP Payload for SMPTE ST 291 Ancillary Data

Dear Payload WG,

I have submitted a new I-D (draft-edwards-rtp-ancillary) defining an R= TP Payload for SMPTE ST 291 Ancillary Data.

SMPTE Ancillary data is used in today's professional serial digital vi= deo formats to carry a range of ancillary data types, including time code, = KLV metadata, Closed Captioning, and the Active Format Description (AFD).

The broadcast industry is preparing to move from the use of serial dig= ital video over coax to "all-IP" professional networked media ins= ide our broadcast plants.  Two of the needed standards have been there= for years waiting for affordable 10 GbE networks.  IETF has already standardized RTP carriage of uncompressed video in = RFC 4175, and 24-bit uncompressed audio in RFC 3190 (as referenced by AES67= ). 

The one remaining item needed is a way of carrying SMPTE ancillary dat= a over RTP, which this I-D should address.

The I-D has already been through an informal review by SMPTE 32NF, and= I have worked in the comments received.  I do not expect that this pr= ocess will require formal liaison with between IETF and SMPTE.  The da= ta model used for the Ancillary data in RTP is based on an existing SMPTE standard to carry Ancillary data over MPEG t= ransport stream, so fortunately most of the "heavy lifting" on th= e data model design has already been done.

A new version of I-D, draft-edwards-rtp-ancillary-00.txt
has been successfully submitted by Thomas G. Edwards and posted to the=
IETF repository.

Name: = draft-edwar= ds-rtp-ancillary
Revision: 00
Title: RTP Payloa= d for SMPTE ST 291 Ancillary Data
Document date: 2015-01-13
Group: Individual= Submission
Pages: 11


Abstract:
   This memo describes an RTP Payload format for SMPTE Ancil= lary data,
   as defined by SMPTE ST 291-1.  SMPTE Ancillary = data is generally used
   along with professional video formats to carry a range of= ancillary
   data types, including time code, KLV metadata, Closed Cap= tioning, and
   the Active Format Description (AFD).

-Thomas

--
Thomas Edwards
VP Engineering & Development
FOX Network Engineering and Operations
thomas.edwards@fox.com
Phone: +1.310.369.6696
10201 West Pico Blvd.
Los Angeles, CA 90035

--_000_D0DC397D2D475thomasedwardsfoxcom_-- From nobody Fri Jan 23 02:22:24 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BECE1A0687 for ; Fri, 23 Jan 2015 02:22:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eed35hBaHbUo for ; Fri, 23 Jan 2015 02:22:20 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 395521A066C for ; Fri, 23 Jan 2015 02:22:20 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-43-54c220daeb8f Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id C9.EA.04231.AD022C45; Fri, 23 Jan 2015 11:22:18 +0100 (CET) Received: from ESESSMB105.ericsson.se ([169.254.5.233]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0195.001; Fri, 23 Jan 2015 11:22:17 +0100 From: Bo Burman To: Roni Even , "payload@ietf.org" Thread-Topic: [payload] Call for adoption of RTP Payload Format for Non-Interleaved and Interleaved Parity FEC Thread-Index: AdAu+5jurQSTx+twSaCD31UiM/ljbQH+sQjA Date: Fri, 23 Jan 2015 10:22:17 +0000 Message-ID: References: <068601d02efc$1ad33530$50799f90$@gmail.com> In-Reply-To: <068601d02efc$1ad33530$50799f90$@gmail.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_BBE9739C2C302046BD34B42713A1E2A22E461F2AESESSMB105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyM+Jvje4thUMhBk/3KVpcuniWyeJvO7MD k8fOWXfZPZYs+ckUwBTFZZOSmpNZllqkb5fAlXFl3nf2gpvaFeefTWdrYHyk1sXIySEhYCJx Y94lRghbTOLCvfVsXYxcHEICRxglpqxZzw7hLGGUeD3xMgtIFZuAhsT8HXfBOkQEfCUWHzsA FhcWyJd4uPA/M0S8QGLXr0NsELaRxNI538DiLAKqEr8n9LOD2LxAvYv2/2AFsYUEzCXmP5nF BGJzClhIHDlwH6yeUUBW4v73e2DzmQXEJW49mc8EcamAxJI955khbFGJl4//sULYihLtTxsY IerzJRav3MwIsUtQ4uTMJywTGEVmIRk1C0nZLCRlEHEdiQW7P7FB2NoSyxa+Zoaxzxx4zIQs voCRfRWjaHFqcXFuupGxXmpRZnJxcX6eXl5qySZGYFwd3PJbdwfj6teOhxgFOBiVeHgLPh4M EWJNLCuuzD3EKM3BoiTOm+ewIURIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDI/vtw9kyLCJK y5+X+ERcC77xIYdbIOrKw6dzJtw+etkyOudb/cfefM+ue5mdvd/O2mSW6xQKPheaG1SrqOO/ 7ZjCnjNsk1Rab03jWfD58qlEu/51wpePPFuQ9KUqom7BzT/CNSuMep6duf3qve3vNe37kqO+ RQmJGmdxHFvO08r/+fg6zY16HUosxRmJhlrMRcWJAKIk/OyMAgAA Archived-At: Subject: Re: [payload] Call for adoption of RTP Payload Format for Non-Interleaved and Interleaved Parity FEC X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 10:22:23 -0000 --_000_BBE9739C2C302046BD34B42713A1E2A22E461F2AESESSMB105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support this /Bo From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Roni Even Sent: den 13 januari 2015 07:42 To: payload@ietf.org Subject: [payload] Call for adoption of RTP Payload Format for Non-Interlea= ved and Interleaved Parity FEC Hi, The RTCweb FEC usage is looking for a solution the proposed RTP payload for= mat was presented and got support in the last IETF meeting. We would like to add a milestone for RTP Payload Format for Non-Interleaved= and Interleaved Parity FEC and adopt draft-singh-payload-rtp-1d2d-parity-s= cheme-00 as the proposal for addressing the mile stone. Please provide feedback to the WG chairs by January 23rd Thanks Roni Even Payload WG co-chair --_000_BBE9739C2C302046BD34B42713A1E2A22E461F2AESESSMB105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I support this /Bo

 

From: payload = [mailto:payload-bounces@ietf.org] On Behalf Of Roni Even
Sent: den 13 januari 2015 07:42
To: payload@ietf.org
Subject: [payload] Call for adoption of RTP Payload Format for Non-I= nterleaved and Interleaved Parity FEC

 

Hi,

The RTCweb FEC usage is looking for a solution the p= roposed RTP payload format was presented and got support in the last IETF m= eeting. 

We would like to add a milestone for RTP Payload Format for Non-Interleaved and Interleaved Parity FEC a=
nd adopt draft-singh-payload-rtp-1d2d-parity-scheme-00 as the propos=
al for addressing the mile stone.
 
Please provide feedback to the WG chairs by January 23rd
Thanks
Roni Even
Payload WG co-chair
 
--_000_BBE9739C2C302046BD34B42713A1E2A22E461F2AESESSMB105erics_-- From nobody Thu Jan 29 07:52:10 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE881A1BF9 for ; Thu, 29 Jan 2015 07:52:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0UymBBCySjGv for ; Thu, 29 Jan 2015 07:52:07 -0800 (PST) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 535491A1BF4 for ; Thu, 29 Jan 2015 07:52:07 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id n3so28113583wiv.1 for ; Thu, 29 Jan 2015 07:52:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=s1ZYeWYXEvWbc+FhTQAzf2qafWcXcgu7i8C/49bRgUM=; b=M5ke1j0fTyob7hBLC36Qhcg8hACXxZw0LJamnpl0Z8nnjtzzbhV+qruHvBg3UZR7oz WGY6GhtNFvxMyMhl9YunTwvsQ1QrEHS6isAsLEo86a4+dng6L15aO5yRb7uAEBWZkZpp 4yUEWqI5H3Uv+Y+0I4uhMHnvKPvZakaL4CH3gRVu9MTLvKPXfQ9075OriwOMuuvXn0+F VDNZM3uBSdQ2O1EephD0o7hM8JXLFhGmL7dmY7RpMi/BTa9oPeIIN1/oOfzwm2SrzNH3 7tu0WzzO9ZIB4V7LUcVeJGCwD+lrVEKqGy40FWcQrHkba6CZ4KSSjQLI1f1PmOdSDLTl QMJg== X-Received: by 10.194.87.100 with SMTP id w4mr2278848wjz.65.1422546725787; Thu, 29 Jan 2015 07:52:05 -0800 (PST) Received: from RoniE (bzq-79-181-50-186.red.bezeqint.net. [79.181.50.186]) by mx.google.com with ESMTPSA id hz9sm10979975wjb.17.2015.01.29.07.52.03 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 29 Jan 2015 07:52:05 -0800 (PST) From: "Roni Even" To: Date: Thu, 29 Jan 2015 17:52:00 +0200 Message-ID: <04c501d03bdb$871e7060$955b5120$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04C6_01D03BEC.4AA803B0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdA720ikLUURdWpMQ4KHGEPOOineLA== Content-Language: en-us Archived-At: Subject: [payload] Result on Call for adoption of RTP Payload Format for Non-Interleaved and Interleaved Parity FEC X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 15:52:09 -0000 This is a multipart message in MIME format. ------=_NextPart_000_04C6_01D03BEC.4AA803B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, There was support to adopt this subject as a work item and adopt draft-singh-payload-rtp-1d2d-parity-scheme-00 as the initial document to address the milestone. I will create a milestone and the authors should submit the document as a WG document Roni Even Payload co-chair From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: 13 January, 2015 8:42 AM To: 'payload@ietf.org' Subject: Call for adoption of RTP Payload Format for Non-Interleaved and Interleaved Parity FEC Hi, The RTCweb FEC usage is looking for a solution the proposed RTP payload format was presented and got support in the last IETF meeting. We would like to add a milestone for RTP Payload Format for Non-Interleaved and Interleaved Parity FEC and adopt draft-singh-payload-rtp-1d2d-parity-scheme-00 as the proposal for addressing the mile stone. Please provide feedback to the WG chairs by January 23rd Thanks Roni Even Payload WG co-chair ------=_NextPart_000_04C6_01D03BEC.4AA803B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

There was support to = adopt this subject as a work item and adopt = draft-singh-payload-rtp-1d2d-parity-scheme-00 as the initial = document to address the milestone.

 

I will = create a milestone and the authors should submit the document as a WG = document

 

Roni Even

Payload = co-chair

 

From:= = Roni Even [mailto:ron.even.tlv@gmail.com]
Sent: 13 January, = 2015 8:42 AM
To: 'payload@ietf.org'
Subject: Call = for adoption of RTP Payload Format for Non-Interleaved and Interleaved = Parity FEC

 

Hi,

The RTCweb FEC = usage is looking for a solution the proposed RTP payload format was = presented and got support in the last IETF meeting. = 

We would =
like to add a milestone for RTP Payload =
Format for Non-Interleaved and Interleaved Parity FEC and adopt =
draft-singh-payload-rtp-1d2d-parity-scheme-00 as the proposal for =
addressing the mile stone.
 =

Please =
provide feedback to the WG chairs by January =
23rd
Thanks=

Roni =
Even
Payload WG =
co-chair
 =
------=_NextPart_000_04C6_01D03BEC.4AA803B0-- From nobody Fri Jan 30 02:54:34 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ADCC1A8AE0 for ; Fri, 30 Jan 2015 02:54:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xauMRnANmuoW for ; Fri, 30 Jan 2015 02:54:31 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 310001A8ADD for ; Fri, 30 Jan 2015 02:54:31 -0800 (PST) X-AuditID: c1b4fb30-f79106d000001184-f1-54cb62e576a0 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id D3.F5.04484.5E26BC45; Fri, 30 Jan 2015 11:54:29 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.92) with Microsoft SMTP Server id 14.3.195.1; Fri, 30 Jan 2015 11:54:28 +0100 Message-ID: <54CB62E4.30700@ericsson.com> Date: Fri, 30 Jan 2015 11:54:28 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Gunnar Persson N , "payload@ietf.org" References: <7F3814818CC0B04E97C2ADBA62B5C9681C5345D8@ESESSMB201.ericsson.se> In-Reply-To: <7F3814818CC0B04E97C2ADBA62B5C9681C5345D8@ESESSMB201.ericsson.se> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnluLIzCtJLcpLzFFi42KZGfG3Rvdp0ukQg7NTpSwuXTzL5MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujP7NX9kLDvJWnH95l6WBcT1XFyMnh4SAicTJQw+YIWwxiQv3 1rN1MXJxCAkcYZR40TCXBcJZziixfmU3G0gVr4CmxOLnG1i7GDk4WARUJY53soCE2QQsJG7+ aAQrERUIBip5ygpRLihxcuYTsBoRgViJnoW7wGxhASOJQ/OPM4HYQgK+Elevrgbr5RTwk1g4 bR/YQcwCBhJHFs1hhbDlJZq3zmaGqNeWaGjqYJ3AKDALyYpZSFpmIWlZwMi8ilG0OLU4KTfd yEgvtSgzubg4P08vL7VkEyMwBA9u+W2wg/Hlc8dDjAIcjEo8vBs+nwoRYk0sK67MPcQozcGi JM5rZ3woREggPbEkNTs1tSC1KL6oNCe1+BAjEwenVANj7MVt+lFuwZwF1jcrvxe3NG1hKuy1 2rMqVKjxsPZOr3fPF/td3D07NqPO5YPsregVJZ8kLH67cl7aEWfCNzXwzfHI1k3LzvWE6h5U arrNbsGwcfuzu39fdt3L2mea0uL2aaan6mWm+9x2FzZPWFQ28/B+i8nxD7V/dzxZqnpfWuzw bDnzrOi5SizFGYmGWsxFxYkAgl+5syICAAA= Archived-At: Subject: Re: [payload] Question regarding RFC 4867 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jan 2015 10:54:33 -0000 Hi, As author of this RFC, here is my answer. On 2015-01-12 11:54, Gunnar Persson N wrote: > Hi > > I have a simple question regarding RFC 4867 > > In chapter… > > > 4.3.1 . The > Payload Header > > …it is stated: > > > > Therefore, if a terminal continuously wishes to receive frames in the > > same mode X, it needs to set CMR=X for all its outbound payloads, and > > if a terminal has no preference in which mode to receive, it SHOULD > > set CMR=15 in all its outbound payloads. > > > > Question: > > *Does “all its outbound payloads” mean “every RTP frame” (I e every 20ms)? * payloads are RTP payloads, thus within each RTP packet sent for that stream that contain an AMR payload. > > > > Comment: > > On air interface CMR value is only communicated every second speech > frame (I e every 40ms). I assume the idea is that BSS shall remember the > last communicated CMR from mobile terminal and insert this CMR in all > RTP frames. Please comment if my assumption is correct. Yes, that becomes the implication if one sends RTP packets which contains only a single 20ms AMR frame. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Sat Jan 31 10:24:04 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC151A1B63 for ; Thu, 29 Jan 2015 07:58:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LsF0NETx5PXg for ; Thu, 29 Jan 2015 07:58:06 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 176661A1B71 for ; Thu, 29 Jan 2015 07:58:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: payload@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150129155805.18787.75343.idtracker@ietfa.amsl.com> Date: Thu, 29 Jan 2015 07:58:05 -0800 From: IETF Secretariat Archived-At: X-Mailman-Approved-At: Sat, 31 Jan 2015 10:24:03 -0800 Subject: [payload] Milestones changed for payload WG X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 15:58:08 -0000 Changed milestone "Submit RTP Payload Format for the iSAC codec for Proposed Standard", set due date to June 2015 from April 2011. URL: http://datatracker.ietf.org/wg/payload/charter/