Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86D4321F8643 for ; Sun, 19 Aug 2012 20:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.711 X-Spam-Level: X-Spam-Status: No, score=-5.711 tagged_above=-999 required=5 tests=[AWL=0.887, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GYPTfdiehw9T for ; Sun, 19 Aug 2012 20:26:06 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id D4C2321F863C for ; Sun, 19 Aug 2012 20:26:05 -0700 (PDT) X-IronPort-AV: E=McAfee;i="5400,1158,6809"; a="224753134" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine02.qualcomm.com with ESMTP; 19 Aug 2012 20:26:04 -0700 X-IronPort-AV: E=Sophos; i="4.77,795,1336374000"; d="scan'208,217"; a="310216541" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 19 Aug 2012 20:26:04 -0700 Received: from NASANEXD01H.na.qualcomm.com ([169.254.8.250]) by nasanexhc07.na.qualcomm.com ([172.30.39.190]) with mapi id 14.02.0318.001; Sun, 19 Aug 2012 20:26:03 -0700 From: "Mandyam, Giridhar" To: Tim Panton Thread-Topic: [rtcweb] Qualcomm's Position on Mandatory-to-Implement Audio Codecs for RTCWeb Thread-Index: Ac1wxkUEr1d+Ke5WQFCmnJL9YXz1tQLB6GGAACvIfBA= Date: Mon, 20 Aug 2012 03:26:02 +0000 Message-ID: References: <00DC1626-33DA-469F-9F06-4D59F2141260@phonefromhere.com> In-Reply-To: <00DC1626-33DA-469F-9F06-4D59F2141260@phonefromhere.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.39.5] Content-Type: multipart/alternative; boundary="_000_CAC8DBE4E9704C41BCB290C2F3CC921A162BAAFEnasanexd01hnaqu_" MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Qualcomm's Position on Mandatory-to-Implement Audio Codecs for RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 03:26:11 -0000 --_000_CAC8DBE4E9704C41BCB290C2F3CC921A162BAAFEnasanexd01hnaqu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Tim, Thank you for your well-thought out reply. Please note that I was using th= e options presented in the straw poll conducted on mandatory-to-implement (= MTI) audio codecs at the RTCWeb meeting in Vancouver IETF 84 as the basis f= or this position statement. Since I have not seen official RTCWeb minutes = from that meeting yet, I will have to reproduce from memory the voting opti= ons presented to the attendees: (1) G.711 only for MTI, (2) G.711 and Opus= only for MTI, and (3) Opus only for MTI. Based on Cullen's email from las= t week, I assume that the call for consensus is still around these three op= tions alone. I made exactly the same argument about H261 and was told (correctly) that i= t was unacceptable to mandate a codec that would give users a poorer than necessary experience. I think what applies for video applies fo= r audio. Specifically g711 is a poor codec choice in a wide variety of network situa= tions - e.g. 3g and edge of wifi. In my experience a lower bandwidth codec which supports wideband, dynamically variable bitrates and error corr= ection / packet loss concealment is required to give these users audio that is acceptable to use in the coffee-shop / airport scenario. Can you clarify what you would suggest as an alternative? If one is willin= g to concede that Opus is not the best audio codec for many lower bandwidth= situations (which is depicted in http://www.opus-codec.org/comparison/), t= hen "poorer than necessary" would seem to point to mandating the codec that= provides best-in-class performance at a given operating condition. This w= ould provide optimal user experience but would also lead to many codecs bei= ng designated as MTI. There are many codecs which that can be said for. We happily run speex on l= ow end smartphones. - Heck we even use the java implementation in applets and get acceptable performance. g722 has recently dropped out of pa= tent, uses the same bandwidth as 711 and gives significantly better audio. Any device capable of running SRTP is capable of running either 722 or spee= x in my experience. Sorry to request clarification again, but do you believe G.722 should be re= -examined as an MTI option? Based on my understanding, .722 is not conside= red in the current call-for-consensus (although other participants have sug= gested it as well). If we are to open up such a debate, it would be helpfu= l if you could provide quantitative data backing your position. You are confusing mandatory-to-implement and mandatory-to-use. Just because= Opus must be available , you don't have to use it. The devices you mention almost all have AMR in DSP - but unfortunately that is encumbered s= o isn't ideal as a mandatory-to-implememnt codec but may well be used when it is available. That was not my intention - maybe my original wording was unclear. It is a= burden on app developers to have to provide SW-based Opus libraries if Opu= s is not available natively on the HW platforms they are targeting. They w= ill have to do this if Opus is MTI. They will also have to optimize their = SW-based implementation for each target HW platform, which also is costly. Again - making Opus mandatory to implement does not preclude supporting or = using any other codecs. By the way point d) applies to any codec you choose to name - so you are pr= obably arguing for no mandatory-to-implement codec - which would be a mistake I think. It certainly applies to g711 - in spades! And not having Opus as MTI does not preclude its use either. If we assume = the "poorer than necessary" criterion over a wide range of operating condit= ions as a prerequisite for MTI, then neither Opus nor G.711 are adequate. = With G.711 as the sole MTI audio codec, implementations are free to negotia= te the best possible user experience given the environment at the moment an= d what each side supports. From: Tim Panton [mailto:tim@phonefromhere.com] Sent: Thursday, August 16, 2012 2:41 AM To: Mandyam, Giridhar Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Qualcomm's Position on Mandatory-to-Implement Audio C= odecs for RTCWeb On 15 Aug 2012, at 14:48, Mandyam, Giridhar wrote: Hello All, Qualcomm is in favor of G.711 being the only mandatory-to-implement codec f= or RTCWeb. We do not support having both Opus and G.711 as mandatory-to-im= plement codecs. We state the following reasons: a) There is no technical need to have an audio codec besides G.711 be = designated as mandatory to implement. Because RTCWeb uses SDP to negotiate= the codecs, the only reason to have anything as mandatory is to make sure = there is always at least one codec that both sides can use, a lowest common= denominator. This allows the market to decide which codecs to support, ra= ther than edict from a standards body. Implementations can base their choi= ce of which codec to support based on what they are trying to optimize. Fo= r example, better performance for the environment at the time of the sessio= n, such as cell phone or desktop. I made exactly the same argument about H261 and was told (correctly) that i= t was unacceptable to mandate a codec that would give users a poorer than necessary experience. I think what applies for video applies fo= r audio. Specifically g711 is a poor codec choice in a wide variety of network situa= tions - e.g. 3g and edge of wifi. In my experience a lower bandwidth codec which supports wideband, dynamically variable bitrates and error corr= ection / packet loss concealment is required to give these users audio that is acceptable to use in the coffee-shop / airport scenario. b) G.711 is universal, unencumbered, and widely implemented. In add= ition, note that codec implementation and testing is quite costly for chip = and device manufacturers, and that cost is ultimately reflected in the cost= of the end-user device. The computational simplicity of G.711 and its lon= g-time availability on a broad range of platforms means that the implementa= tion is available on low/entry-tier devices and testing costs have already = been amortized over many years, thereby enabling its use in low cost end-us= er devices. If we want to see widespread use of RTCWeb for voice, than we = will reach a much broader population if the minimum requirements do not pro= hibit low-cost devices. There are many codecs which that can be said for. We happily run speex on l= ow end smartphones. - Heck we even use the java implementation in applets and get acceptable performance. g722 has recently dropped out of pa= tent, uses the same bandwidth as 711 and gives significantly better audio. Any device capable of running SRTP is capable of running either 722 or spee= x in my experience. c) A mandate for Opus will limit initial RTCWeb clients to use softwa= re-based codecs (on general purpose processors) where Opus can be implemen= ted and tested easily until it is available on a variety of DSPs. Even the= n, it will likely start on high-cost platforms. This may in turn mean that= RTCWeb clients could consume significantly more battery power than DSP-bas= ed codecs used in many traditional (circuit-switched) voice services, furth= er inhibiting the end-user from choosing RTCWeb over those services. You are confusing mandatory-to-implement and mandatory-to-use. Just because= Opus must be available , you don't have to use it. The devices you mention almost all have AMR in DSP - but unfortunately that is encumbered s= o isn't ideal as a mandatory-to-implememnt codec but may well be used when it is available. d) We do not believe Opus is more versatile than other standardized co= decs, because any measure of versatility should take into account quality a= t a given bitrate. If Opus is not able to deliver superior quality at all = supported bitrates when compared to other codecs, then it cannot be deemed = as being more versatile simply because it supports more bitrates when compa= red to other standardized codecs. Again - making Opus mandatory to implement does not preclude supporting or = using any other codecs. By the way point d) applies to any codec you choose to name - so you are pr= obably arguing for no mandatory-to-implement codec - which would be a mistake I think. It certainly applies to g711 - in spades! In conclusion - the IETF has a strong tradition of starting work with the l= east amount of complexity and specification possible, gaining operational e= xperience, and then refining things with revisions or extensions. So, the = least amount of complexity would be G.711 as the sole audio codec. RTCweb is never going to be a _least_possible_complexity_ project. The requ= irements mean we need SRTP (DTLS?), a video modern codec, Echo cancellatio= n, AGC, etc. Adding a good audio codec will not significantly extend the co= mplexity. _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_CAC8DBE4E9704C41BCB290C2F3CC921A162BAAFEnasanexd01hnaqu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Tim,

Thank you for your well-t= hought out reply.  Please note that I was using the options presented = in the straw poll conducted on mandatory-to-implement (MTI) audio codecs at the RTCWeb meeting in Vancouver IETF 84 as the basis for this po= sition statement.  Since I have not seen official RTCWeb minutes from = that meeting yet, I will have to reproduce from memory the voting options p= resented to the attendees:  (1) G.711 only for MTI, (2) G.711 and Opus only for MTI, and (3) Opus only for MTI.&= nbsp; Based on Cullen’s email from last week, I assume that the call = for consensus is still around these three options alone.<= /p>

 <= /p>

I made exactly the same argument about H261 and was = told (correctly) that it was unacceptable to mandate a codec that would giv= e users a

poorer than necessary experience. I think what appli= es for video applies for audio.

 

Specifically g711 is a poor codec choice in a wide v= ariety of network situations - e.g. 3g and edge of wifi. In my experience a= lower bandwidth

codec which supports wideband, dynamically vari= able bitrates and error correction / packet loss concealment is required to= give these users audio

that is acceptable to use in the  coffee-shop /= airport scenario. 

 

Can you clarify what you = would suggest as an alternative?  If one is willing to concede that Op= us is not the best audio codec for many lower bandwidth situations (which is depicted in ht= tp://www.opus-codec.org/comparison/), then “poorer than necessary= ” would seem to point to mandating the codec that provides best-in-cl= ass performance at a given operating condition.  This would provide optimal user experience but would also lead to many cod= ecs being designated as MTI.

 <= /p>

There are many codecs which that can be said for. We= happily run speex on low end smartphones. - Heck we even use the java impl= ementation in

applets and get acceptable performance. g722 has rec= ently dropped out of patent, uses the same bandwidth as 711 and gives signi= ficantly better audio.

Any device capable of running SRTP is capable of run= ning either 722 or speex in my experience. 

 <= /p>

Sorry to request clarific= ation again, but do you believe G.722 should be re-examined as an MTI optio= n?  Based on my understanding, .722 is not considered in the current call-for-consensus (although other participants have suggested= it as well).  If we are to open up such a debate, it would be helpful= if you could provide quantitative data backing your position.

 <= /p>

You are confusing mandatory-to-implement and mandato= ry-to-use. Just because Opus must be available , you don't have to use it. = The devices you 

mention almost all have AMR in DSP - but unfortunate= ly that is encumbered so isn't ideal as a mandatory-to-implememnt codec but= may well be 

used when it is available. 

 <= /p>

That was not my intention= – maybe my original wording was unclear.  It is a burden on app= developers to have to provide SW-based Opus libraries if Opus is not available natively on the HW platforms they are targeting.  They will= have to do this if Opus is MTI.  They will also have to optimize thei= r SW-based implementation for each target HW platform, which also is costly= . 

 <= /p>

Again - making Opus mandatory to implement does not = preclude supporting or using any other codecs. 

 

By the way point d) applies to any codec you choose = to name - so you are probably arguing for no mandatory-to-implement codec -= which would be

a mistake I think. It certainly applies to g711= - in spades!

 <= /p>

And not having Opus as MT= I does not preclude its use either.  If we assume the “poorer th= an necessary” criterion over a wide range of operating conditions as a prerequisite for MTI, then neither Opus nor G.711 are adequate.  Wi= th G.711 as the sole MTI audio codec, implementations are free to negotiate= the best possible user experience given the environment at the moment and = what each side supports. 

 <= /p>

From: Tim Pant= on [mailt= o:tim@phonefromhere.com]
Sent: Thursday, August 16, 2012 2:41 AM
To: Mandyam, Giridhar
Cc: rtcweb@iet= f.org
Subject: Re: [rtcweb] Qualcomm's Position on Mandatory-to-Implement = Audio Codecs for RTCWeb

 

 

On 15 Aug 2012, at 14:48, Mandyam, Giridhar wrote:



Hello All,

Qualcomm is in favor of G.711 being the= only mandatory-to-implement codec for RTCWeb.  We do not support havi= ng both Opus and G.711 as mandatory-to-implement codecs.  We state the following reasons:

 

a)<= span style=3D"font-size:7.0pt">      There is no technical need to have an audio codec besides G.711 be designated as= mandatory to implement.  Because RTCWeb uses SDP to negotiate the cod= ecs, the only reason to have anything as mandatory is to make sure there is= always at least one codec that both sides can use, a lowest common denominator.  This allows the market t= o decide which codecs to support, rather than edict from a standards body.&= nbsp; Implementations can base their choice of which codec to support based= on what they are trying to optimize.  For example, better performance for the environment at the time of the session= , such as cell phone or desktop.

 

I made exactly the same argument about H261 and was = told (correctly) that it was unacceptable to mandate a codec that would giv= e users a

poorer than necessary experience. I think what appli= es for video applies for audio.

 

Specifically g711 is a poor codec choice in a wide v= ariety of network situations - e.g. 3g and edge of wifi. In my experience a= lower bandwidth

codec which supports wideband, dynamically vari= able bitrates and error correction / packet loss concealment is required to= give these users audio

that is acceptable to use in the  coffee-shop /= airport scenario. 



b)<= span style=3D"font-size:7.0pt">      G.711 is universal, unencumbered, and widely implemented.    In a= ddition, note that codec implementation and testing is quite costly for chi= p and device manufacturers, and that cost is ultimately reflected in the co= st of the end-user device.  The computational simplicity of G.711 and its long-time availability on a broad range of platforms mean= s that the implementation is available on low/entry-tier devices and testin= g costs have already been amortized over many years, thereby enabling its u= se in low cost end-user devices.  If we want to see widespread use of RTCWeb for voice, than we will reach a= much broader population if the minimum requirements do not prohibit low-co= st devices. 

 

There are many codecs which that can be said for. We= happily run speex on low end smartphones. - Heck we even use the java impl= ementation in

applets and get acceptable performance. g722 has rec= ently dropped out of patent, uses the same bandwidth as 711 and gives signi= ficantly better audio.

Any device capable of running SRTP is capable of run= ning either 722 or speex in my experience. 

 



c)<= span style=3D"font-size:7.0pt">       A mandate for Opus will limit initial RTCWeb clients to use software-based&n= bsp; codecs (on general purpose processors) where Opus can be implemented a= nd tested easily until it is available on a variety of DSPs.  Even the= n, it will likely start on high-cost platforms.  This may in turn mean that RTCWeb clients could consume significantly more= battery power than DSP-based codecs used in many traditional (circuit-swit= ched) voice services, further inhibiting the end-user from choosing RTCWeb = over those services.

 

You are confusing mandatory-to-implement and mandato= ry-to-use. Just because Opus must be available , you don't have to use it. = The devices you 

mention almost all have AMR in DSP - but unfortunate= ly that is encumbered so isn't ideal as a mandatory-to-implememnt codec but= may well be 

used when it is available. 



d)<= span style=3D"font-size:7.0pt">      We do not believe Opus is more versatile than other standardized codecs, beca= use any measure of versatility should take into account quality at a given = bitrate.  If Opus is not able to deliver superior quality at all suppo= rted bitrates when compared to other codecs, then it cannot be deemed as being more versatile simply because it= supports more bitrates when compared to other standardized codecs.

 

 

Again - making Opus mandatory to implement does not = preclude supporting or using any other codecs. 

 

By the way point d) applies to any codec you choose = to name - so you are probably arguing for no mandatory-to-implement codec -= which would be

a mistake I think. It certainly applies to g711= - in spades!



 

In conclusion - the IETF has a strong t= radition of starting work with the least amount of complexity and specifica= tion possible, gaining operational experience, and then refining things with revisions or extensions.  So, the least amount o= f complexity would be G.711 as the sole audio codec.

 

RTCweb is never going to be a _least_possible_comple= xity_ project. The requirements mean we need  SRTP (DTLS?), a video mo= dern codec, Echo cancellation, AGC, etc. Adding a good audio codec will not= significantly extend the complexity.

 

 



_____________________________________= __________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb<= o:p>

 

--_000_CAC8DBE4E9704C41BCB290C2F3CC921A162BAAFEnasanexd01hnaqu_--