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

[Jean-Marc Valin <[e-mail]>]

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