Re: [codec] requirements #12 (closed): bit-exact vs. bit-compatible?

Jean-Marc Valin <jmvalin@jmvalin.ca> Tue, 25 January 2011 05:01 UTC

Return-Path: <jmvalin@jmvalin.ca>
X-Original-To: codec@core3.amsl.com
Delivered-To: codec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1DA73A6B72 for <codec@core3.amsl.com>; Mon, 24 Jan 2011 21:01:06 -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=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id slqvO3qWs4Zf for <codec@core3.amsl.com>; Mon, 24 Jan 2011 21:01:05 -0800 (PST)
Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by core3.amsl.com (Postfix) with ESMTP id B52E63A6A3D for <codec@ietf.org>; Mon, 24 Jan 2011 21:01:05 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 8bit
Content-type: text/plain; charset="windows-1252"; format="flowed"
Received: from [192.168.1.14] ([70.81.109.112]) by vl-mo-mrz23.ip.videotron.ca (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTP id <0LFK00KFGBE25NP0@vl-mo-mrz23.ip.videotron.ca> for codec@ietf.org; Tue, 25 Jan 2011 00:03:38 -0500 (EST)
Message-id: <4D3E598A.3010200@jmvalin.ca>
Date: Tue, 25 Jan 2011 00:03:06 -0500
From: Jean-Marc Valin <jmvalin@jmvalin.ca>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7
To: Stephan Wenger <stewe@stewe.org>
References: <C963872D.26A05%stewe@stewe.org>
In-reply-to: <C963872D.26A05%stewe@stewe.org>
Cc: codec@ietf.org
Subject: Re: [codec] requirements #12 (closed): bit-exact vs. bit-compatible?
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 25 Jan 2011 05:01:07 -0000

Hi Stephan,

I understand your concern and I'd be interested if you have alternative 
ways of handling the licensing to avoid any issue. It's not like this is 
a unique situation. As far as I know, most (all?) MPEG codecs have 
similar non-bit exact definitions. I have also heard that they also 
require some IPR licensing...

In general the issue of bit-exactness has been discussed and so far I 
don't recall many arguing in favor of a bit-exact definition. Most of 
the concerns that have been expressed are solved by considering that 
non-bitexact does not mean you cannot be bit-exact with the reference 
encoder. It merely means that you don't *have* to. So regardless of how 
conformance is defined exactly, one always has the option of being 
bit-exact with the reference implementation, which obviously guarantees 
compliance.

As for language mentioning compliance, I believe it belongs more to the 
guidelines (it's not a requirement of the codec itself), which includes 
the following text:

    4.  To reduce the risk of bias towards certain CPU/DSP architectures,
        ideally the decoder specification should not require "bit-exact"
        conformance with the reference implementation.  The output of a
        decoder implementation should only be "close enough" to the
        output of the reference decoder.  A comparison tool should be
        provided along with the codec to verify objectively that the
        output of a decoder is likely to be perceptually
        indistinguishable from that of the reference decoder.  However,
        an implementation may still wish to produce an output that is
        bit-exact with the reference implementation to simplify the
        testing procedure.



Cheers,

	Jean-Marc

On 11-01-24 11:02 PM, Stephan Wenger wrote:
> Hi all:
>
> Let me speak once more against this decision (if such a decision were
> really made; see the p.s.).
>
> There are currently three IPR disclosures against the codec draft and/or
> its predecessors.  The Xiph disclosure is at this point a placeholder
> (Xiph folks: it's time to fix that!).  However, the two other disclosures
> on file provide a patent grant only for necessary patent claims and only
> when the standard is practiced in full compliance.  These terms (in
> various formulations) are quite common.
>
> In order to ensure one has a license (or can rely on a non-assert
> covenant), one has to ensure one meets the conditions set by the
> rightholder.  On stuff such as reciprocity clauses this is simple.  On
> compliance, it's not always easy.
>
> The traditional compliance test for a media codec is a stimulus-response
> test: you feed test vectors into the codec, and you get results.  If the
> results match, you are in compliance, if not, you are not.  Simple.
>
> Without bit exactness, the compliance criteria have to be defined
> differently.  We can do so, and, indeed, I recall that this has been
> mentioned as one plan forward.  However, I have seen zero activity in this
> direction, and I have also not seen any language that mentions this in the
> requirements draft.  I think that the subject of compliance tests, at
> least in its most basic outline, needs to be documented in the
> requirements draft.  The details can be taken care of elsewhere and later,
> but not too much later.  It should be clear that a codec candidate (if
> there were more than one) needs to have compliance criteria defined before
> that codec candidate can become an RFC.  Without that, the key goal of the
> WG, a reasonably freely practicable codec, is just not achievable in the
> current legal environment (which includes, in this case, the IPR
> disclosures on file).
>
> Of course, it would be sooooo much simpler if we would mandate a bit exact
> decoder...  Is it really that restricting to require that?
>
> Stephan
>
> P.s.: for the IETF procedures newcomers: humms taken at meetings need to
> be confirmed on a mailing list, and consensus needs to be declared by the
> chairs.  On this subject, I do recall mailing list discussions after
> Maastricht, but I do not recall that consensus was reached, yet alone
> declared.  (Unfortunately, I currently don't have the time to go through
> the mailing list archives to verify my recollection; Sorry.)
>
>
>
> On 1.24.2011 16:45 , "codec issue tracker"<trac@tools.ietf.org>  wrote:
>
>> #12: bit-exact vs. bit-compatible?
>>
>> Changes (by gmaxwell@Š):
>>
>>   * status:  new =>  closed
>>   * resolution:  =>  worksforme
>>
>>
>> Comment:
>>
>> http://www.ietf.org/proceedings/78/minutes/codec.txt
>>
>> "On the topic of bit exact. Consensus was bit exactness is not required."
>>
>> I believe this issue is already closed.
>>
>> --
>> ------------------------------------+-------------------------------------
>> --
>> Reporter:  hoene@Š                 |        Owner:
>>      Type:  enhancement             |       Status:  closed
>> Priority:  minor                   |    Milestone:
>> Component:  requirements            |      Version:
>> Severity:  Active WG Document      |   Resolution:  worksforme
>> Keywords:                          |
>> ------------------------------------+-------------------------------------
>> --
>>
>> Ticket URL:<http://trac.tools.ietf.org/wg/codec/trac/ticket/12#comment:1>
>> codec<http://tools.ietf.org/codec/>
>>
>> _______________________________________________
>> codec mailing list
>> codec@ietf.org
>> https://www.ietf.org/mailman/listinfo/codec
>
>
> _______________________________________________
> codec mailing list
> codec@ietf.org
> https://www.ietf.org/mailman/listinfo/codec
>
>