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

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 stream 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: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] 
> On Behalf Of Jonathan Rosenberg
> Sent: den 1 november 2011 01:58
> To: codec@ietf.org
> 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
> jdrosen@skype.net                              http://www.skype.com
> jdrosen@jdrosen.net                            http://www.jdrosen.net
> 
> _______________________________________________
> codec mailing list
> codec@ietf.org
> https://www.ietf.org/mailman/listinfo/codec
> 