Re: [rtcweb] Confirmation of consensus on audio codecs

<Markus.Isomaki@nokia.com> Tue, 28 August 2012 19:11 UTC

Return-Path: <Markus.Isomaki@nokia.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 7B26221F85F7 for <rtcweb@ietfa.amsl.com>; Tue, 28 Aug 2012 12:11:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 rJvTBZnxMX0v for <rtcweb@ietfa.amsl.com>; Tue, 28 Aug 2012 12:11:14 -0700 (PDT)
Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 4B37F21F85B4 for <rtcweb@ietf.org>; Tue, 28 Aug 2012 12:11:13 -0700 (PDT)
Received: from vaebh105.NOE.Nokia.com (in-mx.nokia.com [10.160.244.31]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7SJB83E011657; Tue, 28 Aug 2012 22:11:09 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.56]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 28 Aug 2012 22:11:07 +0300
Received: from 008-AM1MPN1-042.mgdnok.nokia.com ([169.254.2.220]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.02.0309.003; Tue, 28 Aug 2012 21:11:06 +0200
From: <Markus.Isomaki@nokia.com>
To: <stefan.lk.hakansson@ericsson.com>, <rtcweb@ietf.org>
Thread-Topic: [rtcweb] Confirmation of consensus on audio codecs
Thread-Index: AQHNhRnM+dNiTmSGPk2wFICFjlokw5dvlXgg
Date: Tue, 28 Aug 2012 19:11:05 +0000
Message-ID: <E44893DD4E290745BB608EB23FDDB76229335D@008-AM1MPN1-042.mgdnok.nokia.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: [10.163.23.22]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 28 Aug 2012 19:11:07.0880 (UTC) FILETIME=[E0C99E80:01CD8550]
X-Nokia-AV: Clean
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: Tue, 28 Aug 2012 19:11:19 -0000

Hi Stefan,

I very much share your views and would like to support especially this option:

>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).

It is always nice to get decisions done early on. However, I don't think that leaving the mandatory-to-implement codecs (for either WB audio or video) open at this point will yet seriously impact the deployment or interoperability of WebRTC. There are still many other things to tackle. We should revisit the codec issue when all the other critical things are in a good shape. 

I'll post a separate mail on my views shortly.

Markus


>-----Original Message-----
>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf
>Of ext Stefan Hakansson LK
>Sent: 28 August, 2012 15:37
>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