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

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.

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. 

With best regards,

 Christian Hoene

> -----Original Message-----
> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf
> Of Erik Norvell
> Sent: Wednesday, November 16, 2011 9:38 AM
> To: bens@alum.mit.edu
> Cc: codec@ietf.org
> Subject: Re: [codec] WGLC #2 for draft-ietf-codec-opus-10
> 
> 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:bmschwar@fas.harvard.edu]
> > Sent: den 15 november 2011 16:39
> > To: Erik Norvell
> > Cc: codec@ietf.org
> > 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
> >
> >
> _______________________________________________
> codec mailing list
> codec@ietf.org
> https://www.ietf.org/mailman/listinfo/codec