Re: [codec] Format for the codec specification

["Benjamin M. Schwartz" <[e-mail]>]

On 09/29/2010 01:03 AM, Stephan Wenger wrote:
>  As a result, a non bit-exact
> decoder design has to be much more conservative in exercising technology (as
> more claims may be swept in by advanced designs) than a bit exact decoder
> design, neutralizing, IMO, most of the positive effects a non bit-exact
> design may have from a performance viewpoint.

Surely the converse logic also applies.  A non-bitexact decoder can more
easily be modified to dodge any unexpected patent claims brought against
it, because its designers are not restricted to alterations that do not
affect the output.

Personally, I favor the following:  We should produce a fixed-point
reference decoder, specified bit-exactly in code and text.  We should
indicate that implementors who require a guaranteed level of service
should follow this bit-exact specification.  We should _not_ set any
limits on the deviation of other decoders from this bit-exact specification.

Reasoning:
We should provide a bit-exact decoder specification because otherwise it
is unclear how to optimize the encoder later.

A codec with no licensing restrictions has no gatekeeper, so any
restrictions on performance would be unenforceable in practice.  The lack
of restrictions also means that the codec can easily be extremely widely
implemented, enabling commodity competition between different
implementors.  Competition can keep quality high.

Large single-vendor deployments, without internal competition, are likely
to have a contractually required level of service, in which case the RFC
would direct the implementor to remain bit-exact.

One option we have would be to specify the decoder under two different
names: "$CODEC" and "Bit-Exact $CODEC".

--Ben