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

[Erik Norvell <[e-mail]>]

Dear Ben,

I am afraid but I strongly disagree with your logic.

Interoperability is given through the definition of the meaning of each bit of the bitstream.  

One way of achieving such a definition is to require
- for an(y) encoder to interoperate with the specified (reference) decoder and vice-versa
- for an(y) decoder to interoperate with the specified (reference) encoder.

While such a definition obviously relies on a reference encoder and a reference decoder, it is by no means necessary to make any of them normative. 

Best regards,
Erik

> -----Original Message-----
> From: Benjamin M. Schwartz [mailto:[e-mail]] 
> Sent: den 15 november 2011 16:39
> To: Erik Norvell
> Cc: [e-mail]
> Subject: Re: [codec] WGLC #2 for draft-ietf-codec-opus-10
> 
> On 11/09/2011 07:30 AM, Erik Norvell wrote:
> > The current situation is that there are no constraints on 
> the encoder other than that it should produce a readable 
> bitstream. It may change the quality in any direction. In the 
> interest of maximizing the implementation freedom, the same 
> should apply for the decoder.
> 
> The above suggestion is impossible as a matter of logic, 
> because our purpose is interoperability.
> 
> If the decoder is normatively specified, then an encoder may 
> be designed so that the output of a compliant decoder sounds 
> like the original input audio.  This is our current situation.
> 
> If the encoder is normatively specified, then a decoder may 
> be designed so that its output sounds like the original input 
> audio encoded by a compliant encoder.
> 
> If neither the encoder nor the decoder is normatively 
> specified, then neither can be designed with any expectation 
> of what sort of output will be produced.
> 
> Without any normative specification, it would be trivial to 
> build a compliant but non-interoperable encoder-decoder pair. 
>  Such an encoder would write valid Opus bitstreams, but these 
> bitstreams would only sound like the original input audio 
> when played through the corresponding decoder.  Similarly, 
> the decoder would not produce correct audio output when 
> connected to other encoder implementations.
> 
> Of course, this is all old news.  We have already reached 
> consensus on this issue, which is why it is all explicitly 
> built into the document that guides our process here:
> 
> http://datatracker.ietf.org/doc/draft-ietf-codec-guidelines/?i
nclude_text=1
> 
> See Sections 4.1 and 4.3.
> 
> --Ben
> 
>