Re: [rtcweb] Confirmation of consensus on audio codecs

Stefan Hakansson LK <> Wed, 29 August 2012 09:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2F22321F85AA for <>; Wed, 29 Aug 2012 02:51:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.069
X-Spam-Status: No, score=-6.069 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bPn3VOEKQ1fv for <>; Wed, 29 Aug 2012 02:51:13 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9C27121F8610 for <>; Wed, 29 Aug 2012 02:51:12 -0700 (PDT)
X-AuditID: c1b4fb30-b7f7d6d0000042ea-10-503de60edc92
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id D9.8F.17130.E06ED305; Wed, 29 Aug 2012 11:51:11 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id; Wed, 29 Aug 2012 11:51:10 +0200
Message-ID: <>
Date: Wed, 29 Aug 2012 11:51:09 +0200
From: Stefan Hakansson LK <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Jean-Marc Valin <>
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphluLIzCtJLcpLzFFi42KZGfG3Vpf/mW2AwaqpbBb/p3JYrP3Xzu7A 5LFkyU8mj74DXawBTFFcNimpOZllqUX6dglcGRt2lxV81KnYOPMgawPjVpUuRk4OCQETiVvv z7NB2GISF+6tB7K5OIQETjFKdExbxAzhLGeUeLfgOmMXIwcHr4C2xIp2JZAGFgFVic0/J7GA 2GwCNhJru6cwgdiiAiESa75NYQSxeQUEJU7OfAJWIyKgKXHnxyp2EJtZQF3izuJzYLawgL3E xhP/weqFBKolfnQfAjuIE2jV64ldYGuZgWoebC2DaJWX2P52DjNEua7Eu9f3WCcwCs5Csm0W QscsJB0LGJlXMQrnJmbmpJeb66UWZSYXF+fn6RWnbmIEhujBLb8NdjBuui92iFGag0VJnFdP db+/kEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsaY8JUPa+Jb67hezGRsnuzBFiSxoSO9UWMd Z8rrH9cPzls9LWO3dc/irFltjsdD86e2vrFQupDO5v+O1eeORvT25TrbyibYrO2Tu2MlWvXo QmesvM2KetcNt9cVhhsGFPmUJwWbfPtRVnzhzMGApZ+uzqrtCz75IiZgS3yi6l+RY2mZRfW2 h5VYijMSDbWYi4oTAcWV8sAfAgAA
Cc: "" <>
Subject: Re: [rtcweb] Confirmation of consensus on audio codecs
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 29 Aug 2012 09:51:14 -0000

On 08/28/2012 06:30 PM, Jean-Marc Valin wrote:
> 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.

the info above goes a long way in answering my questions, thanks. I 
don't know the exact rules for IPR statements so I would like to double 
check: the fact that the RFC only defines the decoder, does that mean 
that there can be IPRs known by people in the codec WG that are not 
declared since they would apply to the encoder only (then there is the 
risk of IPRs held by those who have not participated in codec WG)?

Another question I had was if Opus is atomic, or if you can implement 
different profiles, and if so what parts should be MTI for rtcweb (and 
should the profile that is MTI be the same regardless of the device type 
- there has been issues raised regarding complexity?).

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

That is great, but sort of underlines that there would be no harm in 
delaying the decision until there are experiences made from real world 
use - 'cause it would not be that long till that experience has been 
made (Markus also brought up the IPR status as a reason for waiting - I 
have no idea how long it would take to know more about that).

> 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
> which
> summarizes the listening tests that were done on Opus. Also, I
> recommend reading
> This describes a whole series of tests we did that other SDOs
> generally don't do on their codecs.

As Paul suggested, I was referring to the lack of formal, controlled,
characterization tests. That is how other SDOs do it. I don't think that 
is the only way to do it, but I think we should at least have either 
such tests conducted or experience from deployment and use (in a wide 
range of conditions and device types) before making it MTI.

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

Especially if you draw a diagram with all the signaling paths, all 
components involved, and then make a small box for "codec" (or Opus) :-)

> Cheers,
> 	Jean-Marc
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Mozilla -
> Agyp8cyfmAREgjP5w5LZw0rmAMGfiPiWKuv7lvTgpivR3HOQbuhnMw9vdQEUJEPw
> xLHpj5SmZMggA8LFNPcWcmztkUcTnEfKCxPcdFPhA2i3b2cBR/L1b4oLRkUY706c
> p/EaBVIvOe7Uk54o13V0S671LaaJlX7qGY5Asf3BWLZlGB5xspwtOJvpQ+C6NiTD
> 94vPId9xKv1BlGIXPbWnUOb3sIAuegGbjkuM36m7DxqVH+zEiXBs8BIDDFdDVSV3
> iatsJSeRb1E11/RSEoPjQQE2oiP3R+K2jZhEZeLSfdY75mpAjE11qqfDQMUUCo0=
> =Otiw