IETF Logo Mail Archive

Re: [rtcweb] RTCWEB needs an Internet Codec

Jean-Marc Valin <jmvalin@mozilla.com> Fri, 31 August 2012 20:33 UTC

Return-Path: <jmvalin@mozilla.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 2596021F8469 for <rtcweb@ietfa.amsl.com>; Fri, 31 Aug 2012 13:33:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.677
X-Spam-Level:
X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311]
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 5a+JTk41WHRn for <rtcweb@ietfa.amsl.com>; Fri, 31 Aug 2012 13:33:11 -0700 (PDT)
Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id 0B38321F8467 for <rtcweb@ietf.org>; Fri, 31 Aug 2012 13:33:11 -0700 (PDT)
Received: from [192.168.1.15] (modemcable094.20-21-96.mc.videotron.ca [96.21.20.94]) (Authenticated sender: jvalin@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 20ED2F269F; Fri, 31 Aug 2012 13:33:10 -0700 (PDT)
Message-ID: <50411F84.4010108@mozilla.com>
Date: Fri, 31 Aug 2012 16:33:08 -0400
From: Jean-Marc Valin <jmvalin@mozilla.com>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:15.0) Gecko/20120824 Thunderbird/15.0
MIME-Version: 1.0
To: Roman Shpount <roman@telurix.com>
References: <p06240603cc63f3f41ca9@99.111.97.136> <503F46C5.2090607@alvestrand.no> <EDC0A1AE77C57744B664A310A0B23AE240CBCCD8@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> <503F61CC.1010709@alvestrand.no> <CAC8DBE4E9704C41BCB290C2F3CC921A162D278D@nasanexd01h.na.qualcomm.com> <503FC1BF.5020004@alvestrand.no> <CAC8DBE4E9704C41BCB290C2F3CC921A162D2B0F@nasanexd01h.na.qualcomm.com> <5040541C.5020008@alvestrand.no> <20120831133845.GW72831@verdi> <5040CE32.5050003@jesup.org> <20120831151247.GY72831@verdi> <5040E7A5.50406@mozilla.com> <CAD5OKxtWCCu16-xQ=yhK9s3tyk+fyg4JPPXJ=yDVFubtPbHTgQ@mail.gmail.com>
In-Reply-To: <CAD5OKxtWCCu16-xQ=yhK9s3tyk+fyg4JPPXJ=yDVFubtPbHTgQ@mail.gmail.com>
X-Enigmail-Version: 1.4.4
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: Randell Jesup <randell-ietf@jesup.org>, rtcweb@ietf.org
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: Fri, 31 Aug 2012 20:33:12 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/31/2012 01:23 PM, Roman Shpount wrote:
> One issue I want to bring into consideration is computation
> complexity of Opus. It is normally acceptable for end user devices
> in point-to-point calls (I do not want to start all the mobile
> device CPU vs battery live discussion. It is irrelevant), but in
> cases where you need to process all the calls on some sort of
> central server (such as conferencing, or virtual reality, or
> massive multi-player games) the additional processing cost of
> supporting Opus can be significant. In such cases G.722 (ideally in
> combination with  PLC and CN to save bandwidth) can be a valid
> compromise, since it can provide quality better then G.711 with CPU
> processing requirements order of magnitude less then Opus.

Actually, you're making a really good point about complexity on the
server side. One important feature in Opus is scalable complexity.
Sure you can use it in ways that eat a lot of CPU to fully optimize
quality, but you can also get good enough quality at much lower
complexity. I just ran a quick test on my two year-old laptop. Using
the unoptimized C reference implementation with a single core, I can
encode and decode at 40 kb/s (higher quality than G.722) 150 channels
in real-time. Using architecture-specific optimizations and both
cores, we should be able to handle about 500 channels on my poor
laptop. And that's assuming that we're actually decoding and
re-encoding all streams, which we'd never do. In a mixing case where
we're decoding all channels, but only encoding one, we end up with
1000 channels.

Oh, one feature I forgot to mention about Opus is that (unlike G722)
it's *really* cheap to figure out which channels are active without
having to decode everything. That alone should provide at least a 2x
saving (more for larger conferences). So we're now at 2000 channels on
my poor old laptop. I think a recent multi-core server should have
about 10x that power. Conclusion, the audio codec complexity will just
*not* be a problem.

	Jean-Marc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQEcBAEBAgAGBQJQQR+EAAoJEJ6/8sItn9q9I7kH/05UHgmakBitdPghhvE4TYQC
/2t9VNNPkyBCNbHIsxskkDazZae7pgi0SVFe1me3xDdhIatrEtIK4wF8Y5ML6/sW
5HyxTTpoyeYJvbt4j8NZTf5MR6Nj6CEYWoWuZAdVdZRC4+Y0xjyFcu4DCP3xFg8D
SN1AsWZkM4SkMI9Ioa1EFiQUH+FPhRK2GPtLsqba8DGQ4ZeBbe8C9I52ECQAOdgA
2u2Kd8mqH1f7lellXWL5VKh3BVazJOEDXa7JGEExpRTlpUbicyguu2hNrYTUj+yP
itqyhRge02E7tYRQRuGnQg+s2N2GPvpFEr6k3a9XAdMAykX2xlIrZVgGaWEtru4=
=J6Nz
-----END PGP SIGNATURE-----

v2.23.0 | Report a Bug | By Email