As I've said before, there is a high cost to service providers every time a new codec is introduced operationally, at the very least in the form of full-mesh transcoding. Thus, new codecs should not be developed lightly. The world already has enough encumbered codecs, and there's no point in adding yet another. However, the draft charter states: > Although this preference cannot guarantee that the working > group will produce an unencumbered codec, the working group shall > attempt to adhere to the spirit of BCP 79. This preference does not > explicitly rule out the possibility of adapting encumbered technologies; > such decisions will be made in accordance with the rough consensus of > the working group. I appreciate the potential difficulty of guaranteeing the unencumbered status of any output of this group. However, I would like this statement to be stronger, saying that this group will only produce a new codec if it is strongly believed by WG rough consensus to either be unencumbered, or freely licensed by the IPR holder(s), if any. Thanks, Andy On Tue, Jan 5, 2010 at 11:45 PM, Joel Jaeggli <joelja@xxxxxxxxx> wrote: > Peter Saint-Andre wrote: >> But I don't think we can say that relevent members of the IETF community >> do *not* have the competence to work on an audio codec or that they are >> *not* willing to listen to technically competent input from any source >> when it comes to codec technologies. Indeed, the two BoFs at Stockholm >> and Hiroshima would lead, I think, to the opposite conclusion: the >> people who want to do this work appear to be competent (they have >> already developed codecs like Speex, CELT, SILK, IPMR, BV16, and BV32) >> and to be quite committed to rough consensus and running code, we have >> some precedent for doing work of this kind within the IETF (e.g., RFC >> 3951), several longtime IETF participants have experience with digital >> signal processing and similar technologies, a codec working group would >> attract new participants with relevant areas of expertise, and people at >> the BoFs appeared to be quite open to input from the IETF community or >> any interested individual. > > +1 > > This is work we've done before and there seems to be no particular > reason that it should not be done here again. > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf