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(_at_)bogus(_dot_)com>
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf