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-----
- Re: [rtcweb] Confirmation of consensus on audio c… Richard Shockey
- Re: [rtcweb] Confirmation of consensus on audio c… Monty Montgomery
- [rtcweb] Confirmation of consensus on audio codecs Cullen Jennings (fluffy)
- Re: [rtcweb] Confirmation of consensus on audio c… Roman Shpount
- Re: [rtcweb] Confirmation of consensus on audio c… Bernard Aboba
- Re: [rtcweb] Confirmation of consensus on audio c… Richard Shockey
- Re: [rtcweb] Confirmation of consensus on audio c… Richard Shockey
- Re: [rtcweb] Confirmation of consensus on audio c… Monty Montgomery
- Re: [rtcweb] Confirmation of consensus on audio c… Lorenzo Miniero
- Re: [rtcweb] Confirmation of consensus on audio c… Matthew Kaufman
- Re: [rtcweb] Confirmation of consensus on audio c… Jonathan Rosenberg
- Re: [rtcweb] Confirmation of consensus on audio c… Ken Fischer
- Re: [rtcweb] Confirmation of consensus on audio c… Basil Mohamed Gohar
- Re: [rtcweb] Confirmation of consensus on audio c… Basil Mohamed Gohar
- Re: [rtcweb] Confirmation of consensus on audio c… Justin Uberti
- Re: [rtcweb] Confirmation of consensus on audio c… Peter Saint-Andre
- Re: [rtcweb] Confirmation of consensus on audio c… Richard Shockey
- Re: [rtcweb] Confirmation of consensus on audio c… Richard Shockey
- Re: [rtcweb] Confirmation of consensus on audio c… Silvia Pfeiffer
- Re: [rtcweb] Confirmation of consensus on audio c… tom harper
- Re: [rtcweb] Confirmation of consensus on audio c… stephane.proust
- Re: [rtcweb] Confirmation of consensus on audio c… Randell Jesup
- Re: [rtcweb] Confirmation of consensus on audio c… Ted Hardie
- Re: [rtcweb] Confirmation of consensus on audio c… Lishitao
- Re: [rtcweb] Confirmation of consensus on audio c… Neil Stratford
- Re: [rtcweb] Confirmation of consensus on audio c… Markus.Isomaki
- Re: [rtcweb] Confirmation of consensus on audio c… Stefan Hakansson LK
- Re: [rtcweb] Confirmation of consensus on audio c… Jean-Marc Valin
- Re: [rtcweb] Confirmation of consensus on audio c… Paul Coverdale
- Re: [rtcweb] Confirmation of consensus on audio c… Markus.Isomaki
- Re: [rtcweb] Confirmation of consensus on audio c… Stefan Hakansson LK
- Re: [rtcweb] Confirmation of consensus on audio c… Lishitao
- Re: [rtcweb] Confirmation of consensus on audio c… Olle E. Johansson
- Re: [rtcweb] Confirmation of consensus on audio c… Stefan Hakansson LK
- Re: [rtcweb] Confirmation of consensus on audio c… Harald Alvestrand
- Re: [rtcweb] Confirmation of consensus on audio c… Markus.Isomaki
- Re: [rtcweb] Confirmation of consensus on audio c… Jean-Marc Valin
- Re: [rtcweb] Confirmation of consensus on audio c… Jean-Marc Valin
- Re: [rtcweb] Confirmation of consensus on audio c… Bernhard.Feiten
- Re: [rtcweb] Confirmation of consensus on audio c… Mandyam, Giridhar
- Re: [rtcweb] Confirmation of consensus on audio c… Marc Petit-Huguenin
- Re: [rtcweb] Confirmation of consensus on audio c… Randell Jesup
- Re: [rtcweb] Confirmation of consensus on audio c… Peter Saint-Andre
- Re: [rtcweb] Confirmation of consensus on audio c… Randall Gellens
- Re: [rtcweb] Confirmation of consensus on audio c… Basil Mohamed Gohar
- Re: [rtcweb] Confirmation of consensus on audio c… Richard Shockey
- Re: [rtcweb] Confirmation of consensus on audio c… Randall Gellens
- Re: [rtcweb] Confirmation of consensus on audio c… Harald Alvestrand
- Re: [rtcweb] Confirmation of consensus on audio c… Stefan Hakansson LK
- Re: [rtcweb] Confirmation of consensus on audio c… Neil Stratford
- Re: [rtcweb] Confirmation of consensus on audio c… Randall Gellens
- Re: [rtcweb] Confirmation of consensus on audio c… Ted Hardie
- Re: [rtcweb] Confirmation of consensus on audio c… Timothy B. Terriberry
- Re: [rtcweb] Confirmation of consensus on audio c… Ron
- [rtcweb] Consensus Statement for Re: Confirmation… Magnus Westerlund