Re: [rtcweb] RTCWEB needs an Internet Codec

<stephane.proust@orange.com> Thu, 30 August 2012 14:12 UTC

Return-Path: <stephane.proust@orange.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 E00DC21F84CE for <rtcweb@ietfa.amsl.com>; Thu, 30 Aug 2012 07:12:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.096
X-Spam-Level:
X-Spam-Status: No, score=-1.096 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_16=0.6, UNPARSEABLE_RELAY=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 fVnYHZnc3KJ6 for <rtcweb@ietfa.amsl.com>; Thu, 30 Aug 2012 07:12:00 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id F276321F8528 for <rtcweb@ietf.org>; Thu, 30 Aug 2012 07:11:59 -0700 (PDT)
Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 8DEF32DC3EB; Thu, 30 Aug 2012 16:11:58 +0200 (CEST)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 6E58D2380BE; Thu, 30 Aug 2012 16:11:58 +0200 (CEST)
Received: from PEXCVZYM14.corporate.adroot.infra.ftgroup ([fe80::a42f:c628:bc76:d592]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Thu, 30 Aug 2012 16:11:58 +0200
From: stephane.proust@orange.com
To: Martin Taylor <Martin.Taylor@metaswitch.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: [rtcweb] RTCWEB needs an Internet Codec
Thread-Index: AQHNhZg7VAle8mPeRUCAmEaNdk1WoZdwDLGAgAB45ACAAdmicA==
Date: Thu, 30 Aug 2012 14:11:56 +0000
Message-ID: <16529_1346335918_503F74AE_16529_311_1_2842AD9A45C83B44B57635FD4831E60A02A679@PEXCVZYM14.corporate.adroot.infra.ftgroup>
References: <CAKhHsXEW25Z=gaZ2gp5GOaM7upfoL2npt+k7HDNFpn36DcNtnQ@mail.gmail.com> <CAD5OKxuf=PqAYJDze7d7re8A+RBQUn8jUz1azqBBoEQrXPR8sA@mail.gmail.com> <185A2074C1DC2342B1514880D000CC1AA7748BD4@ENFICSMBX1.datcon.co.uk>
In-Reply-To: <185A2074C1DC2342B1514880D000CC1AA7748BD4@ENFICSMBX1.datcon.co.uk>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.197.38.4]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.19.115414
Subject: Re: [rtcweb] RTCWEB needs an Internet Codec
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: Thu, 30 Aug 2012 14:12:01 -0000

>An Internet codec is one which was designed specifically to handle a significant level of packet loss.  The G.xxx series codecs were designed for circuit-switched environments where packet loss is a non-issue.

Looking at the draft "Summary of Opus listening test results" which is supposed to "examine listening test results obtained for the Opus codec and how they relate to the requirements" I cannot see unfortunately any result on OPUS performance with packet losses and jitter nor any other result on any real measured usage over internet, especially for the intended usage in "full band"... So, I don't know exactly to what extent and with respect to what test results and what related requirement OPUS would be more an "internet codec" than other G.xxx codecs that have been already and successfully experienced over internet for years (at least with respect to this "packet loss" robustness criterion). Furthermore, some key features that enhance any voice codec performance for usage over internet are anyway outside the codec itself.

Stephane



De : rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] De la part de Martin Taylor
Envoyé : mercredi 29 août 2012 13:27
À : rtcweb@ietf.org
Objet : Re: [rtcweb] RTCWEB needs an Internet Codec

An Internet codec is one which was designed specifically to handle a significant level of packet loss.  The G.xxx series codecs were designed for circuit-switched environments where packet loss is a non-issue.

If you are not experiencing voice quality issues with G.722, then you are lucky enough to have a very low loss Internet connection.  We see frequent issues with G.722 when used for VoIP, especially over WiFi and upstream over ADSL.  Data traffic that competes with voice for bandwidth frequently causes choppy voice on these types of connection.  We have chosen to use SILK to deal with this issue, and this has resulted in major improvements in subjective voice quality.  SILK is one of the "ingredients" of Opus.

I believe that WebRTC applications which use Opus will deliver a far better user experience in general than those that use G.711 or G.722.  Whether that means Opus should be mandatory to implement is another matter.  In my view, it is only necessary to specify one MTI codec to ensure that there is a baseline for interop.  The market can decide what codecs it wishes to use to improve on this baseline interop.

Martin

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Roman Shpount
Sent: 29 August 2012 05:14
To: Alan Johnston
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] RTCWEB needs an Internet Codec

Not that I have anything against Opus, but what exactly makes Opus an internet codec? What is internet codec anyway? Makes this all kind of a meaningless argument.

I would argue that for my broadband internet connection G.722 is a perfect internet codec. I do not care about bandwidth savings of Opus, and quality wise, for the voice conversation, I cannot hear any difference.

I would argue G.711 should be the MTI codec. The rest can be left up to browser implementers. We can argue all we want, but the best royalty free low bitrate codec available will be the one everybody supports. We can force it to be Opus, but even if we don't, it will still be Opus on its merit alone. G.722 will probably end up being supported as well, since it is free, pretty good quality, and easy to implement.

P.S. Not that I am arguing for it, I am surprised no one made a case for iSAC, since it is also royalty free, low bit rate, and very high quality. It is event named "internet Speech Audio Codec".
_____________
Roman Shpount
On Tue, Aug 28, 2012 at 11:41 PM, Alan Johnston <alan.b.johnston@gmail.com> wrote:
The RTCWEB effort needs an Internet codec.  This is why Opus is the
right choice.  RTCWEB also needs one codec for backwards compatibility
with the VoIP world.  This is why G.711 is also the right choice.

Any G.mumble codec is NOT an Internet codec and will not have the same
performance on the Internet as one that was designed for the Internet!
 If anyone doesn't understand what that means, go back and examine the
CODEC Working Group archives to get educated.

If someone wants another codec instead of Opus, then they need to
propose another Internet codec.  Otherwise, we are not serving the
Internet.

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


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.