Re: [rtcweb] Confirmation of consensus on audio codecs

Jean-Marc Valin <jmvalin@mozilla.com> Tue, 28 August 2012 16:30 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 0E2C221F8576 for <rtcweb@ietfa.amsl.com>; Tue, 28 Aug 2012 09:30:33 -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=[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 C+7DGVffTurA for <rtcweb@ietfa.amsl.com>; Tue, 28 Aug 2012 09:30:32 -0700 (PDT)
Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id 4538421F8575 for <rtcweb@ietf.org>; Tue, 28 Aug 2012 09:30:32 -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 mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id D0A86F2538; Tue, 28 Aug 2012 09:30:29 -0700 (PDT)
Message-ID: <503CF224.5050609@mozilla.com>
Date: Tue, 28 Aug 2012 12:30:28 -0400
From: Jean-Marc Valin <jmvalin@mozilla.com>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
References: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> <503CBB52.8070300@ericsson.com>
In-Reply-To: <503CBB52.8070300@ericsson.com>
X-Enigmail-Version: 1.4.3
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
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 16:30:33 -0000

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

On 08/28/2012 08:36 AM, Stefan Hakansson LK wrote:
> "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)?

The exact implementation (or version of that implementation) does not
matter as long as the implementation is compliant with (upcoming) RFC
6716.

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

The jitter buffer is not part of Opus, nor is it part of any other
codec I know of. As for loss concealment, the Opus reference
implementation proposes one, but implementers can choose what they
want because there is no interoperability issue with
changing/improving loss concealment.

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

The text in the upcoming RFC 6716 is very clear that only the decoder
is standardized. This is similar to how codecs like MP3 and AAC are
defined. We also provide a set of test vectors, along with a program
that evaluates the decoded output to determine whether the decoder
under test is compliant.

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

So far, Opus has been deployed in Firefox, GStreamer, FFMpeg,
Foobar2000, and a few other applications. This is far more deployment
than any ITU-T/MPEG codec has had by the time of standardization. Not
only that, but some of the underlying technology has been in use for
years now. The original SILK codec (not compatible with Opus but
having a lot in common) has been in Skype for about 3 years, while
CELT (again, not compatible but sharing a lot of technology) has been
deployed in many applications in the past 3 years, including Mumble,
which has about half a million users worldwide.

> In addition, I've been told that so far Opus has gone through less 
> characterization tests than codecs usually are put through.

When it comes to testing, I recommend reading
http://tools.ietf.org/html/draft-valin-codec-results-00 which
summarizes the listening tests that were done on Opus. Also, I
recommend reading
https://www.ietf.org/proceedings/82/slides/codec-4.pdf
This describes a whole series of tests we did that other SDOs
generally don't do on their codecs.

> I don't think it is fair to mandate the implementation of a codec
> (which is a large and complex piece) under these circumstances.

Well, compared to the rest of webrtc, I find that Opus is so small,
simple and well-defined :-)

Cheers,

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

iQEcBAEBAgAGBQJQPPIhAAoJEJ6/8sItn9q93vYH/1Q6/dW3ZTkIsMu8y9GOLLNK
Agyp8cyfmAREgjP5w5LZw0rmAMGfiPiWKuv7lvTgpivR3HOQbuhnMw9vdQEUJEPw
xLHpj5SmZMggA8LFNPcWcmztkUcTnEfKCxPcdFPhA2i3b2cBR/L1b4oLRkUY706c
p/EaBVIvOe7Uk54o13V0S671LaaJlX7qGY5Asf3BWLZlGB5xspwtOJvpQ+C6NiTD
94vPId9xKv1BlGIXPbWnUOb3sIAuegGbjkuM36m7DxqVH+zEiXBs8BIDDFdDVSV3
iatsJSeRb1E11/RSEoPjQQE2oiP3R+K2jZhEZeLSfdY75mpAjE11qqfDQMUUCo0=
=Otiw
-----END PGP SIGNATURE-----