Re: [codec] Testing: A Novel Proposal
Monty Montgomery <xiphmont@gmail.com> Tue, 19 April 2011 07:47 UTC
Return-Path: <xiphmont@gmail.com>
X-Original-To: codec@ietfc.amsl.com
Delivered-To: codec@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 79675E0665 for <codec@ietfc.amsl.com>; Tue, 19 Apr 2011 00:47:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Y6tZlp0gQMl for <codec@ietfc.amsl.com>; Tue, 19 Apr 2011 00:47:32 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfc.amsl.com (Postfix) with ESMTP id 8E310E0655 for <codec@ietf.org>; Tue, 19 Apr 2011 00:47:32 -0700 (PDT)
Received: by wwa36 with SMTP id 36so4425017wwa.13 for <codec@ietf.org>; Tue, 19 Apr 2011 00:47:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=7gkH0wJ0wRK0YgQVIEQhfpKrAsqo1tvXb1a+nUzgpuY=; b=Gw0cTXXBHMKYsnT87EHGR6GCRYQEy9Xx3Xs8TFxWjT2tlGeTrWr/p1yP+X7gJijJV+ 8oIRmv0ZUc5qqdVBIatoaJxDAU2MALgySmi1vzo7L9FEfzCQ1WbkROEQPZZcPg9B4+t7 vcvSu1wuI05e8R/AN6Y3Z0p1fVu5IW/loKbzQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=hnX4ZMvymp0s/UkBTGg0/2F2mY9WQ1WnZcAw7HBnseSkgqHbVtgq6kboeAIp+QMvZB sCxkMHZwP9nRbkXYRSeTCYrFwK1bfOoH1MSsv6zydXt1LBChN2jru/8ud4ukB+vsYfcr dBab5U+GHdEgTQwEt2qSdhHRJ3rSWHyLb6Lig=
MIME-Version: 1.0
Received: by 10.227.39.92 with SMTP id f28mr5938462wbe.153.1303199251771; Tue, 19 Apr 2011 00:47:31 -0700 (PDT)
Received: by 10.227.144.69 with HTTP; Tue, 19 Apr 2011 00:47:31 -0700 (PDT)
Date: Tue, 19 Apr 2011 03:47:31 -0400
Message-ID: <BANLkTindFywD--4RP8GdKjEMzyQxHx2zLA@mail.gmail.com>
From: Monty Montgomery <xiphmont@gmail.com>
To: Anisse Taleb <anisse.taleb@huawei.com>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: "codec@ietf.org" <codec@ietf.org>
Subject: Re: [codec] Testing: A Novel Proposal
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Apr 2011 07:47:33 -0000
> The results presented so far are good, the actual tests however are debatable. So far, the people who want to use the codec have been testing it the way they'd want to use it. That's not complete use case testing, but I wager it covers the most likely uses. > Testing is not delaying the process, it is part of the process. That is the form of testing that has been and is being performed; lean and targeted in-process testing that immediately feeds back into further perfection of the codec at hand. Results have been used progressively and immediately. I can't agree with halting development for years of distributed testing across dozens of officially accredited labs. This form of testing is welcome as well, but it will not produce a better codec. It will merely provide bullet points for subsequent marketing materials down the road (as well as inform development of the next generation of codecs of course; it is a mistake to be too short-sighted. But it won't improve Opus.) >> 4) perfection is the enemy of good >> > So is imperfection. I have an interesting proposal. By way of grandiose schoolyard bravado, in the interests of sparking a more productive direction of debate: "If it isn't good enough... Prove it." The group of proponents actively participating in the development of Opus have test results showing that so far Opus is doing very well indeed. A group of skeptics that happen to be outside the development process are calling for a halt to give time for further evaluation. Testing is important OF COURSE, but so far the abstract test plans suggested, as opposed to the tests actually being performed, are calls for a complete and indefinite halt to progress (with the side effect that it will lead to a delay of wider real-world testing as favored by the proponent faction). On which side is the burden of proof at this point? The proponents with good data or the more cautious faction with an abstract five year plan? Both sides favor testing. The skeptics simply want a different process that the proponents see as directly harmful to progress... and actual testing. So here's a Novel Idea: Perhaps what we really need to move things forward is a 'Devil's Advocate' office, a blessed and fully _parallel_ testing 'faction' that is out to make Opus look as bad as possible (in the name of progress) and has a responsibility of keeping up with development. This will be immensely useful. It also solves the problem of "I think it isn't good enough, but it's up to you to prove it for me." Any takers? I have a hat with little horns on it. Monty (Individual)
- Re: [codec] Testing: A Novel Proposal Koen Vos
- Re: [codec] Testing: A Novel Proposal Monty Montgomery
- Re: [codec] Testing: A Novel Proposal Anisse Taleb
- Re: [codec] Testing: A Novel Proposal Ron
- Re: [codec] Testing: A Novel Proposal Stephen Botzko
- Re: [codec] Testing: A Novel Proposal Monty Montgomery
- Re: [codec] Testing: A Novel Proposal Monty Montgomery