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

Erik Norvell <erik.norvell@ericsson.com> Thu, 17 November 2011 13:21 UTC

Return-Path: <erik.norvell@ericsson.com>
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 2C61011E8121 for <codec@ietfa.amsl.com>; Thu, 17 Nov 2011 05:21:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.328
X-Spam-Level:
X-Spam-Status: No, score=-6.328 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 TPXCAuSuvF0v for <codec@ietfa.amsl.com>; Thu, 17 Nov 2011 05:20:59 -0800 (PST)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id BD6E911E811F for <codec@ietf.org>; Thu, 17 Nov 2011 05:20:58 -0800 (PST)
X-AuditID: c1b4fb39-b7b3eae00000252a-f8-4ec50a395390
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 51.52.09514.93A05CE4; Thu, 17 Nov 2011 14:20:57 +0100 (CET)
Received: from ESESSCMS0351.eemea.ericsson.se ([169.254.1.130]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Thu, 17 Nov 2011 14:20:57 +0100
From: Erik Norvell <erik.norvell@ericsson.com>
To: Ron <ron@debian.org>, "codec@ietf.org" <codec@ietf.org>
Date: Thu, 17 Nov 2011 14:20:56 +0100
Thread-Topic: [codec] WGLC #2 for draft-ietf-codec-opus-10
Thread-Index: AcyklIIoniaTh5LHTyCHOr9zzb7mkAAlx7Zw
Message-ID: <027A93CE4A670242BD91A44E37105AEF3BB9FEF1D2@ESESSCMS0351.eemea.ericsson.se>
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> <20111116191814.GF765@audi.shelbyville.oz>
In-Reply-To: <20111116191814.GF765@audi.shelbyville.oz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
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: Thu, 17 Nov 2011 13:21:00 -0000

Ron,

You are talking about interoperability guarantees and that the IPRs in the codec would serve the purpose to offer these guarantees rather than to protect a revenue stream garnered from unwitting users of the technology. 
 
I don't believe that the threat of potential litigation is the only way to maintain interoperability between implementations. Further, I would regard any discussion about the purpose of IPRs in OPUS as useless. In general terms it is however an undisputable fact that OPUS is not as unencumbered as it was the original desire of the group. Hence, please respect that every implementer may want to make his own balance of the quality of his product using OPUS on the one hand and the licensing cost/risk stemming from the encumbrance of the codec on the other hand. With this background I simply request to respect that implementers may want to have their implementation freedom.

Concerning interoperability itself you seem to confuse this term with a guarantee to offer the best possible quality. I don't think that we can go that far. It is definitely not logical given that the encoder would in any case only be informative. So even if you are using a bit exact decoder implementation you have no quality guarantees because the encoder might be crappy. (In fact, you don't even have interoperability guaranteed.) Hence, it makes no sense to be extremely relaxed on the encoding end and at the same time to be very restrictive on the decoding end. A reasonable definition of the term interoperability would be required first. In my view interoperability of a given encoder/decoder pair can only mean that the decoder can produce a 'useful output' from any bitstreams produced by the encoder operated in any possible setting. The term useful output should relate to intelligibility, but quality expectations should not be associated with interoperability.

Finally, you seem certain that decoder enhancements are not possible while encoder enhancements would be. I think there are numerous examples where the decoding end of existing (speech) codecs were enhanced. Such enhancements would be disqualified by a too narrow conformance test even though the decoder should be considered interoperable.
 
Best regards
Erik 

> -----Original Message-----
> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] 
> On Behalf Of Ron
> Sent: den 16 november 2011 20:18
> To: codec@ietf.org
> Subject: Re: [codec] WGLC #2 for draft-ietf-codec-opus-10
> 
> 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
> 
> 
> _______________________________________________
> codec mailing list
> codec@ietf.org
> https://www.ietf.org/mailman/listinfo/codec
>