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 118D421F861F for ; Thu, 16 Aug 2012 02:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 3r3dY36JnA7e for ; Thu, 16 Aug 2012 02:41:12 -0700 (PDT) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id 47A1321F84FD for ; Thu, 16 Aug 2012 02:41:08 -0700 (PDT) Received: from [192.67.4.12] (unknown [192.67.4.12]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id BEE2237A905; Thu, 16 Aug 2012 10:49:53 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_D7AAB7AC-70E0-41A8-B4C2-3781AA1F0459" From: Tim Panton In-Reply-To: Date: Thu, 16 Aug 2012 10:40:53 +0100 Message-Id: <00DC1626-33DA-469F-9F06-4D59F2141260@phonefromhere.com> References: To: "Mandyam, Giridhar" X-Mailer: Apple Mail (2.1278) 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: Thu, 16 Aug 2012 09:41:13 -0000 --Apple-Mail=_D7AAB7AC-70E0-41A8-B4C2-3781AA1F0459 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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 having both Opus and G.711 as = mandatory-to-implement codecs. We state the following reasons: > =20 > 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, rather than edict from a standards body. = 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 give users a poorer than necessary experience. I think what applies for video applies = for audio. Specifically g711 is a poor codec choice in a wide variety of network = situations - e.g. 3g and edge of wifi. In my experience a lower = bandwidth codec which supports wideband, dynamically variable 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.=20 > b) G.711 is universal, unencumbered, and widely implemented. = In addition, 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 long-time availability on a broad range of platforms means = that the implementation 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-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-cost devices.=20= There are many codecs which that can be said for. We happily run speex = on low end smartphones. - Heck we even use the java implementation in applets and get acceptable performance. g722 has recently dropped out of = patent, uses the same bandwidth as 711 and gives significantly better = audio. Any device capable of running SRTP is capable of running either 722 or = speex in my experience.=20 > c) A mandate for Opus will limit initial RTCWeb clients to use = software-based codecs (on general purpose processors) where Opus can be = implemented and tested easily until it is available on a variety of = DSPs. Even then, 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-switched) voice services, further 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=20 mention almost all have AMR in DSP - but unfortunately that is = encumbered so isn't ideal as a mandatory-to-implememnt codec but may = well be=20 used when it is available.=20 > d) We do not believe Opus is more versatile than other = standardized codecs, because any measure of versatility should take into = account quality at 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 compared to other standardized codecs. Again - making Opus mandatory to implement does not preclude supporting = or using any other codecs.=20 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! > =20 > In conclusion - the IETF has a strong tradition of starting work with = the least amount of complexity and specification possible, gaining = operational experience, 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 = requirements mean we need SRTP (DTLS?), a video modern 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 --Apple-Mail=_D7AAB7AC-70E0-41A8-B4C2-3781AA1F0459 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
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 having = both Opus and G.711 as mandatory-to-implement 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, rather than edict from a standards body.  = 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 give users = a
poorer than necessary experience. I think what applies for = video applies for audio.

Specifically g711 is a = poor codec choice in a wide variety of network situations - e.g. 3g and = edge of wifi. In my experience a lower bandwidth
codec which = supports wideband, dynamically variable 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) G.711 is = universal, unencumbered, and widely implemented.    In = addition, 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 long-time availability on a broad range of platforms means = that the implementation 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-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-cost = devices. 

Th= ere are many codecs which that can be said for. We happily run speex on = low end smartphones. - Heck we even use the java implementation = in
applets and get acceptable performance. g722 has recently = dropped out of patent, uses the same bandwidth as 711 and gives = significantly better audio.
Any device capable of running SRTP = is capable of running either 722 or speex in my = experience. 


c) A mandate for = Opus will limit initial RTCWeb clients to use software-based  = codecs (on general purpose processors) where Opus can be implemented and = tested easily until it is available on a variety of DSPs.  Even = then, 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-switched) = voice services, further 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 so 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 codecs, because = any measure of versatility should take into account quality at 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 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 tradition of starting work with the least amount of = complexity and specification possible, gaining operational experience, = 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 = requirements mean we need  SRTP (DTLS?), a video modern codec, Echo = cancellation, AGC, etc. Adding a good audio codec will not significantly = extend the = complexity.