Re: [codec] WGLC #2 for draft-ietf-codec-opus-10

Ron <ron@debian.org> Wed, 16 November 2011 19:18 UTC

Return-Path: <ron@debian.org>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3335111E80DF for <codec@ietfa.amsl.com>; Wed, 16 Nov 2011 11:18:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v+jp5Ty6aaca for <codec@ietfa.amsl.com>; Wed, 16 Nov 2011 11:18:19 -0800 (PST)
Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [150.101.137.141]) by ietfa.amsl.com (Postfix) with ESMTP id 1FBC311E80C9 for <codec@ietf.org>; Wed, 16 Nov 2011 11:18:18 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAOILxE55LS0m/2dsb2JhbABDqgKBBoFyAQEEATocKAsLGC4UGA2IObkyiTRjBI0QhyMBkg8
Received: from ppp121-45-45-38.lns20.adl2.internode.on.net (HELO audi.shelbyville.oz) ([121.45.45.38]) by ipmail04.adl6.internode.on.net with ESMTP; 17 Nov 2011 05:48:16 +1030
Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 083844F8F3 for <codec@ietf.org>; Thu, 17 Nov 2011 05:48:15 +1030 (CST)
X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz
Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id DDgTPrNqqTsI for <codec@ietf.org>; Thu, 17 Nov 2011 05:48:14 +1030 (CST)
Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 4559F4F8FE; Thu, 17 Nov 2011 05:48:14 +1030 (CST)
Date: Thu, 17 Nov 2011 05:48:14 +1030
From: Ron <ron@debian.org>
To: codec@ietf.org
Message-ID: <20111116191814.GF765@audi.shelbyville.oz>
References: <4EAF4419.3000502@jdrosen.net> <027A93CE4A670242BD91A44E37105AEF3BB9CEAE91@ESESSCMS0351.eemea.ericsson.se> <4EC28796.5090502@fas.harvard.edu> <027A93CE4A670242BD91A44E37105AEF3BB9FEEC3F@ESESSCMS0351.eemea.ericsson.se> <011701cca44b$b525d640$1f7182c0$@uni-tuebingen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <011701cca44b$b525d640$1f7182c0$@uni-tuebingen.de>
User-Agent: Mutt/1.5.20 (2009-06-14)
Subject: Re: [codec] WGLC #2 for draft-ietf-codec-opus-10
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: Wed, 16 Nov 2011 19:18:20 -0000

On Wed, Nov 16, 2011 at 11:37:12AM +0100, Christian Hoene wrote:
> Hi,
> 
> I would suggest to split two things: 
> 
> First, we need a notion for standard conformance because of the legal IPR
> requirements (can be more relaxing). 
> Second, we need some tests in respect to interoperability (should be more
> straight).
> 
>  Both tests need to fulfill different requirements.

I don't see these as different requirements at all.

The IPR in this case is not being used to protect a revenue stream garnered
from unwitting users of the technology - it is being used to protect the
interoperability guarantees that can be offered to end users.

Separating these two things, and watering down the protection offered by
the IPR does not offer any benefit to users, only to implementers who might
be tempted to compromise on interoperability.  Possibly for 'practical'
reasons, and possibly for 'commercial' reasons of their own - but their
reasons don't matter, only the end effect, a degraded user experience, is
the important consideration (to avoid) here.

There is one requirement.  Good interoperability.  IPR grant conformance
is the only binding method we have of ensuring this.  As heretical as it
may seem to the FRAND profit seekers - the real profit to be made here
from patents is an enhanced and assured user experience.

Of course, since I don't actually own any of the IPR, I can't speak for
the people who do, or for their motives - but this is what I see as their
most valuable gift to us, above and beyond the actual technology itself.


> Also, I like Erik's idea to allow for algorithms to replace patented stuff
> in the codec - even if the quality is a bit worse.

I think this is a fallacy.  It was argued that this extra freedom might
allow people to produce a 'better' decoder.  That seems like nonsense to
me, the decoder is never going to be able to recover information that
simply isn't there - the best it can do is recover all of it with tight
fidelity.  Which is what the current conformance test tries to measure.

It was also argued that this freedom might allow people to produce a
worse decoder.  That seems like something we should strongly avoid.
There seem to be only three reasons to do this:

 - Save cycles on underpowered systems.
   But the requirements already include assessing complexity guarantees
   are within reasonable bounds.

 - Sidestep the IPR to produce systems that are not fully interoperable
   but can still claim (some semblance of) conformance.

 - Provide distortive 'enhancements' that some users may assess as being
   pleasing on a first brief listen, but which reduce the real fidelity
   of the output.   (eg. simulate mp3 distortion for the people who
   listening tests actually prove like that more than lossless original)

Both those latter cases carry a danger of sounding like crap if future
(real) enhancements are made to the encoder which actually does increase
the real fidelity and information content of the encoded signal.

The likelihood of such improvements being made to the encoder is high,
so I think this is a real jeopardy which we should not inflict upon
end users or limit future encoder work by.

The decoder should decode the bitstream accurately.  If it cannot, then
it should not claim to decode Opus.  People are always free to sidestep
the IPR and make something that sounds worse.  They just shouldn't be
encouraged or allowed to then also misrepresent that as Opus and mislead
the users that this group set out to serve.  As some of the liaisons
have reminded us, we're here because we wanted to *raise* the bar, not
to just continue Business As Usual in patented codec proliferation.
So we should do just that.  And make everyone happy :)

IMO

 Ron