Re: [rtcweb] Confirmation of consensus on audio codecs

"Mandyam, Giridhar" <mandyam@quicinc.com> Wed, 29 August 2012 14:31 UTC

Return-Path: <mandyam@quicinc.com>
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 B75B221F86B5 for <rtcweb@ietfa.amsl.com>; Wed, 29 Aug 2012 07:31:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.792
X-Spam-Level:
X-Spam-Status: No, score=-5.792 tagged_above=-999 required=5 tests=[AWL=0.807, BAYES_00=-2.599, 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 mNcMIA9gRstP for <rtcweb@ietfa.amsl.com>; Wed, 29 Aug 2012 07:31:09 -0700 (PDT)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id C06DA21F8527 for <rtcweb@ietf.org>; Wed, 29 Aug 2012 07:31:09 -0700 (PDT)
X-IronPort-AV: E=McAfee;i="5400,1158,6818"; a="228407999"
Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine02.qualcomm.com with ESMTP; 29 Aug 2012 07:30:54 -0700
X-IronPort-AV: E=Sophos;i="4.80,334,1344236400"; d="scan'208";a="291435543"
Received: from nasanexhc14.na.qualcomm.com ([172.30.48.23]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 29 Aug 2012 07:30:54 -0700
Received: from NASANEXD01H.na.qualcomm.com ([169.254.8.250]) by nasanexhc14.na.qualcomm.com ([172.30.48.23]) with mapi id 14.02.0318.001; Wed, 29 Aug 2012 07:30:53 -0700
From: "Mandyam, Giridhar" <mandyam@quicinc.com>
To: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: [rtcweb] Confirmation of consensus on audio codecs
Thread-Index: AQHNe9LENUMF/Hj3nEmo2lnRJlNz25dvsTcAgAAjkuA=
Date: Wed, 29 Aug 2012 14:30:53 +0000
Message-ID: <CAC8DBE4E9704C41BCB290C2F3CC921A162D18B6@nasanexd01h.na.qualcomm.com>
References: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> <503CBB52.8070300@ericsson.com>
In-Reply-To: <503CBB52.8070300@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [199.106.115.132]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [rtcweb] Confirmation of consensus on audio codecs
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Aug 2012 14:31:13 -0000

I support a) below.  This will allow us to gain operational experience with various codecs, and an update to the RTCWeb specifications can later mandate additional codecs as needed.

-Giri Mandyam

-----Original Message-----
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Stefan Hakansson LK
Sent: Tuesday, August 28, 2012 5:37 AM
To: rtcweb@ietf.org
Subject: Re: [rtcweb] Confirmation of consensus on audio codecs

On 08/16/2012 07:15 PM, Cullen Jennings (fluffy) wrote:
>
> At the last meeting we took a hum on selecting Opus and G.711 as the 
> mediatory to implement audio codecs. If there is any new opinions 
> please send them to the list by August 30th, after which the chairs 
> will make a determination of consensus.

As much as I would like to say "I agree", I come to the conclusion it is not that simple.

I have two things that concern me:

* "Opus" not well enough defined
* Opus not mature and proven enough (this is the more important concern)

Lets talk about both of these.

"Opus" not well enough defined
==============================
Just saying "Opus" is a bit vague for me (who has not been in the codec WG). Is a certain version meant? Which one? Or is it a moving target (i.e. always implement the latest version)?

What is included (is jitter management, loss concealment part of Opus or something that is up to the implementation)?

And how is it judged what is a compliant implementation? Is there a ref implementation that you test against? How do you test? Are there test-vectors that must be conformed to? Or is "Opus" standardized as a wire format (meaning that any implementation that can produce/decode that wire format is compliant)? If the latter is true, implementers have more wiggle room to e.g. reduce complexity or design around IPRs (submarine IPRs may surface). Are implementors required to support all aspects of Opus, or are there sub-sets/profiles that would be sufficient (perhaps for certain classes of devices)? [1] suggests that not all ptime options need to be supported, but are there others things?

Many of the answers are probably available, but I think they should be put in front of the WG before making this decision.

Opus not mature and proven enough
=================================
As far as I understand, Opus is a brand new standard. There are implementations on-going, but yet no deployment, no experience from real world use (and definitely not from use in larger scale over a wide range of conditions, involving a broad range of end user devices). In addition, I've been told that so far Opus has gone through less characterization tests than codecs usually are put through.

I don't think it is fair to mandate the implementation of a codec (which is a large and complex piece) under these circumstances. Some real deployment (involving many device types) and experience (including operation in different conditions) should be gained before doing so. It could also be argued that there is a bigger risk from a licensing perspective to mandate a codec that has not been in use.


Do I mean we should mandate just G.711?
=======================================
No, not necessarily. Looking ahead, I am convinced that new and improved codecs for audio and video will be introduced as they become available. 
There is a logic in adopting technology that reduces the transmitted number of bits and enhances the end user experience, and the WG is designing a solution that enables new codecs to be introduced and used (and I really hope they can be made use of even if the applications is
untouched) IIUC. However, if G.711 would be the only MTI audio codec, services that expect audio BW that goes beyond narrowband could suffer since there is no guarantee that there is any other codec than G.711 supported by both endpoints.

In addition G.711 is not that well suited for for challenging network conditions (the most important parts like packet loss concealment and jitter management depends on the implementation - or are we going to standardize those parts?; what I am after is that it is unable to lower the send rate as reaction to congestion - the only method available is to use longer frames to make the IP header overhead lower).

I see three possible ways forward:

a) Mandate G.711 only, and let the market decide if there will be a universally available codec giving higher quality.

b) Postpone the decision for some time. Let Opus (and other new codecs if such are introduced) get deployed, tested, perhaps improved. The drawback with this approach is that the selection is delayed. If this approach is chosen, I would also recommend that the WG spends some time on selection criteria. In the presentation given in Vancouver ([2]) six criteria were used (three of them considered more important). I think they make sense, but can't remember we actually discussed them (or what other criteria that may make sense).

c) Mandate some other codec (that is already deployed and in use).

Of these approaches, perhaps b) is the most reasonable one.

Stefan

[1] http://datatracker.ietf.org/doc/draft-cbran-rtcweb-codec/?include_text=1
[2] http://www.ietf.org/proceedings/84/slides/slides-84-rtcweb-6.pdf




>
> Thanks, Cullen
>
> Please note that the following IPR disclosure have been made on these 
> codecs. They can be found at
>
> http://datatracker.ietf.org/ipr/
>
>
> 2010-11-07 * ID # 1445 "Broadcom Corporation's Statement about IPR 
> related to draft-ietf-codec-opus-00 and
> draft-ietf-codec-description-00 (1)" 2010-11-07 * ID # 1446 "Xiph.Org 
> Foundation's Statement about IPR related to draft-ietf-codec-opus-00" 
> 2010-11-12 * ID # 1447 "Broadcom Corporation's Statement about IPR 
> related to draft-ietf-codec-opus-00 and 
> draft-ietf-codec-description-00 (2)" 2011-03-23 * ID # 1520 "Qualcomm 
> Incorporated's Statement about IPR related to 
> draft-ietf-codec-opus-05" 2011-03-27 * ID # 1524 "Xiph.Org 
> Foundation's Statement about IPR related to draft-ietf-codec-opus-05" 
> 2011-03-29 * ID # 1526 "Broadcom Corporation's Statement about IPR 
> related to draft-ietf-codec-opus-05" 2011-03-29 * ID # 1525 "Skype 
> Limited's Statement about IPR related to draft-ietf-codec-opus-05" 
> 2011-07-23 * ID # 1602 "Skype Limited's Statement about IPR related to 
> draft-ietf-codec-opus-07" 2012-01-25 * ID # 1670 "Microsoft 
> Corporation's Statement about IPR related to draft-ietf-codec-opus-10" 
> 2012-03-12 * ID # 1712 "Huawei Technologies Co.,Ltd's Statement about 
> IPR related to draft-ietf-codec-opus-11 (1)" 2012-04-02 * ID # 1741 
> "Huawei Technologies Co.,Ltd's Statement about IPR related to 
> draft-ietf-codec-opus-11 (2)"
>
>
>
> _______________________________________________ rtcweb mailing list 
> rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
>

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb