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)