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