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

[Ron <[e-mail]>]

Hi Erik,

On Thu, Nov 17, 2011 at 02:20:56PM +0100, Erik Norvell wrote:
> 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.
 

I think you give an excellent meta-example here of the dangers inherent
to "enhanced decoding".  You seem to have extrapolated quite broadly
from the bitstream I presented you, and I declare your output to be
clearly non-conformant to the reference :)

I didn't say anything about guaranteeing absolute quality.  That's a
function of the encoder.  In order to be able to optimise that function
though we need a decoder that is deterministic.

The reference encoder is Free, both in licence and royalty terms, and
is basically transparent over a wide range of bitrates.  I don't think
we need to worry about the people who might write crappy encoders.
Nobody will use them, or nobody will listen to their content if they
do.  That's quite a different issue from people selling hardware with
crap decoders in their firmware, or people publishing listening tests
with the crap but conformant decoder they wrote over the weekend.


If you really can't live without distorting 'decoder enhancements' like
bass boost or whatever, you can always add that as a post processing
stage.  Defining compliance in terms of "my mom thinks it sounds ok"
or something similarly handwavy is not good engineering.

I agree with Koen that we should not preclude things which reasonable
people, with an interest in the codec actually succeeding, would
consider an acceptable implementation.  I strongly disagree with the
attempts to define "I could understand 5 out of the 7 words" as being
within that bound of acceptable.  I'm pretty sure you'll still be able
to do that without treading on anyone's IPR.


So let's just let Koen and Jean-Marc find a middle ground, shall we.
I'm pretty sure they'll do as good a job on that as they have with
the codec to date.

Faithfully

 Ron