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

[Erik Norvell <[e-mail]>]

Hi Jean-Marc,

Defining the bit stream does not require a normative decoder. It is defined by the encoder and decoder specification, regardless of whether they are normative or informative. Yes, G.729 could decode whatever raw data you input to some nonsense audio, but I cannot see why anyone would do that and call it Opus. It is not more likely than anyone using the G.729 encoder and calling the output an Opus bitstream, which the current setup permits in the same line of argumentation. What will count in the end on the marketplace is the quality of specific encoder and decoder implementations a provider can offer. If this quality is not limited since there is still the implementation freedom it will just be a plus.

One problem with the proposed way of conformance testing with normative decoder becomes already apparent with the separate test vectors for the FIXED and FLOAT implementations. At least for the mono test vectors 3 and 4, the FIXED implementation fails when comparing to the FLOAT test vector and vice versa. How could we define conformance in such a way that two different but definitely valid implementations fail meeting the conformance criterion of the respective other implementation? 

If already the difference between FIXED and FLOAT is enough to make the conformance test fail, it definitely shows that the proposed way of conformance verification needs to be revised.

Best regards,
Erik 

> -----Original Message-----
> From: Jean-Marc Valin [mailto:[e-mail]] 
> Sent: den 9 november 2011 21:11
> To: Erik Norvell
> Cc: [e-mail]
> Subject: Re: [codec] WGLC #2 for draft-ietf-codec-opus-10
> 
> Hi Erik,
> 
> With respect to IPR, I'd like to refer you to the statement 
> made by Monty on the rtcweb mailing list:
> http://www.ietf.org/mail-archive/web/rtcweb/current/msg02646.html
> 
> Now, I do agree in principle with the idea of "ensuring the 
> largest possible freedom in the implementation" and that's 
> certainly what we've done for the encoder. Now, when it comes 
> to the decoder, it's a different matter because it's what 
> defines the bit-stream. If you remove any requirements based 
> on test vectors, then the spec becomes meaningless. Even a 
> G.729 decoder would produce some audio output when sent an 
> Opus bit-stream. What would prevent someone from saying it 
> implements the Opus specification?
> 
> In general, considering the fact that the decoder is fairly 
> straightforward with little room for alternate 
> implementations (unlike the encoder), the space of changes 
> which change the output but which remain usefully compatible 
> is fairly small and probably not useful for patent avoidance. 
> But if the issue was ever to arise, the IETF could easily 
> publish an updated spec with new test vectors that remains 
> compatible with the original spec.
> 
> Cheers,
> 
> 	Jean-Marc
> 
> On 09/11/11 07:30 AM, Erik Norvell wrote:
> > Hi all,
> > 
> > I am not in any way against the use of patented technology 
> in IETF in general, but I think many people agree that this 
> is not the expected outcome of this WG. The main arguments 
> for starting this WG is that it should produce an 
> unencumbered codec. Still, there is an opportunity in trying 
> to achieve an unencumbered codec by ensuring the largest 
> possible freedom in the implementation. For this reason, I 
> suggest the standard compliance defined in terms of closeness 
> to the test vectors should be removed. In consequence, this 
> will render the specified OPUS encoder and decoder c-code to 
> informative only. 
> > 
> > I would like to note in this context that other standards 
> bodies often apply the criterion of compliance to test 
> vectors not with the only objective of ensuring a defined 
> quality level but also to have means of enforcing the use of 
> the IPRs of a reference implementation. Given the original 
> goal of the codec WG of providing an unencumbered codec, this 
> latter aspect should be irrelevant in the context of our group.
> > 
> > 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. This means the only constraint 
> for both the encoder and the decoder would be that they can 
> write and read the bit stream format, respectively.
> > 
> > With regards to the desire to achieve the best possible 
> quality when 
> > using the IETF codec, I think that - given that there was 
> in any case 
> > no plan to have strong encoder compliance criteria - there 
> is no loss 
> > in relaxing the compliance criteria even for the decoder. 
> Rather, it 
> > can be foreseen that the market will choose the best performing 
> > implementation and we can be sure that especially for the 
> decoding end 
> > that it will be in the biggest interest of providers of a 
> product to 
> > use an implementation that guarantees the highest quality. 
> It might be 
> > that implementers have less incentive of providing the best 
> possible 
> > encoders since this will actually not impact the directly perceived 
> > quality of the product (it would only hurt someone else on the far 
> > end). However, we would in any case have had this potential problem 
> > and even here I believe that the market mechanisms will 
> work leading 
> > to the use of high-quality implementations. On a general 
> perspective, 
> > specifying only the bit
> st
> >  ream in a normative fashion will allow to continuously 
> improve both encoders and decoders over the 
> (informative-only) reference implementations of the standard. 
> > 
> > Best regards,
> > Erik
> > 
> >> -----Original Message-----
> >> From: [e-mail] [mailto:[e-mail]] On 
> >> Behalf Of Jonathan Rosenberg
> >> Sent: den 1 november 2011 01:58
> >> To: [e-mail]
> >> Subject: [codec] WGLC #2 for draft-ietf-codec-opus-10
> >>
> >> The chairs would like to initiate a ~3-week WGLC on 
> >> draft-ietf-codec-opus-10
> >> (http://datatracker.ietf.org/doc/draft-ietf-codec-opus/)
> >> which will end November 19, coincident with the conclusion of the 
> >> Taipei IETF.
> >>
> >> Please note that this document has several IPR claims against it:
> >>
> >> Xiph.org:    https://datatracker.ietf.org/ipr/1524/
> >> Broadcom:    https://datatracker.ietf.org/ipr/1526/
> >> Skype:       https://datatracker.ietf.org/ipr/1602/
> >> Qualcomm:    https://datatracker.ietf.org/ipr/1520/
> >>
> >> The IETF cannot take a position on validity of these claims. 
> >> It is up to IETF participants to make their own decisions. 
> >> Participants are encouraged to form an opinion about whether you 
> >> would like to proceed with publication of this document 
> under these 
> >> declarations, or whether you would like to suggest 
> changes, which you 
> >> should do during the last call period. As always, we will proceed 
> >> based on consensus of the working group.
> >>
> >> Thanks,
> >> Jonathan R.
> >>
> >>
> >> -- 
> >> Jonathan D. Rosenberg, Ph.D.                   SkypeID: jdrosen
> >> Skype Chief Technology Strategist
> >> [e-mail]                              http://www.skype.com
> >> [e-mail]                            
> http://www.jdrosen.net
> >>
> >> _______________________________________________
> >> codec mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/codec
> >>
> > _______________________________________________
> > codec mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/codec
> 
>