Re: [rtcweb] Confirmation of consensus on audio codecs

Jean-Marc Valin <jmvalin@mozilla.com> Wed, 29 August 2012 13:11 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 89E1121F8578 for <rtcweb@ietfa.amsl.com>; Wed, 29 Aug 2012 06:11:04 -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 wiF8kztZS1Bm for <rtcweb@ietfa.amsl.com>; Wed, 29 Aug 2012 06:11:03 -0700 (PDT)
Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id 9E67E21F8566 for <rtcweb@ietf.org>; Wed, 29 Aug 2012 06:11:03 -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 C95F5F2454; Wed, 29 Aug 2012 06:10:58 -0700 (PDT)
Message-ID: <503E14E1.6000401@mozilla.com>
Date: Wed, 29 Aug 2012 09:10:57 -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> <503CF224.5050609@mozilla.com> <503DE60D.2060706@ericsson.com>
In-Reply-To: <503DE60D.2060706@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: Wed, 29 Aug 2012 13:11:04 -0000

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

On 08/29/2012 05:51 AM, Stefan Hakansson LK wrote:
> 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)?

The RFC includes and describes both the encoder and the decoder. What
I was saying is that only the decoder was described normatively, while
the encoder was allowed to change. So the IPR rules apply to both the
encoder and the decoder.

> 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 does not have profiles. That's what ensures that any Opus
bitstream can be decoded by any compliant decoder. And that can happen
*before* the decoder has even seen the SDP.

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

As Harald is pointing out, rtcweb implementations are going to ship
pretty soon. I don't see a reason to postpone decisions that can be
made now. Are you expecting *another* single, standardized,
royalty-free codec that operates over vast ranges of bitrates and
operating conditions, from narrowband speech to stereo music, all with
low delay, coming out in the next year? If not, what are you really
waiting for?

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

Opus has had "ITU-style" testing on English (
http://www.opus-codec.org/comparison/GoogleTest1.pdf ) and Mandarin (
http://www.opus-codec.org/comparison/GoogleTest2.pdf ). And if you
don't trust Google on the tests I linked to, it's also been tested by
Nokia:
http://research.nokia.com/files/public/%5B16%5D_InterSpeech2011_Voice_Quality_Characterization_of_IETF_Opus_Codec.pdf

Now, unlike other SDOs, the testing did not stop there. ITU-T codecs
generally end up being testing with something in the order of tens of
minutes worth of audio. In *addition* to that kind of testing, Opus
also had automated testing with hundreds of years worth of audio. If
anything, I think other SDOs should learn something here.

	Jean-Marc

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

iQEcBAEBAgAGBQJQPhThAAoJEJ6/8sItn9q9nAcH/0BsXl/FBgMhbYWVALpNmIYi
Yj1ezyW8JVSv4io1YIozucl6KiDVi3LwYFteYgl78PlQ7o2muv/lJP9VswRHooH5
Gax+aJUZkz7SlKxn+25wUlLgKQw6GAcUID5sJ0ewWdGOrwZu+SlZgYF3egYmmwyL
pEl8BFj7wu3uakRm/BE9LsUDPFdCoZS6uXqXRJOy9P1dZ25edvgaymQvOwhEcXu9
xMq82YPNU2CZpfb88ew/l+U9FjW8c4iGkZYiu+VzmBL8wYOFP5pBhBhWc/bEb0WX
8IUC5PJ0MMp49kb7/kfQj65/Py7u6ytYaO4PA0rjMHJ2V1PzH4EuqtNweYXVzNI=
=nwlD
-----END PGP SIGNATURE-----