Re: [Ekiga-devel-list] ekiga 3.2 on windows

[Gregory Maxwell <gmaxwell gmail com>]

Michael Rickmann wrote:
> Actually I hooked in CELT because there was no problem cross compiling it from the latest git.
> As to the build you have used, it must have been very close to CELT 6.0.
> CELT 5.2 is the latest of the 5.x series. May be, keeping backwards compatibility is
> not that easy for the CELT developers when they have to keep an eye on forwards compatibility
> of their prior versions as well.
> What shall I do? Leave it out, no.


It's not that its difficult. It's a complete non-goal at this point in time.

As it is written on bold text on the webpage: CELT is actively under
development.  While the software is feature complete, reliable, and
very thoroughly tested the format itself is still evolving.  This will
stop when CELT reaches 1.0 and the format will forever be fixed.

The nature of the CELT design means that most of the codec behaviour
is normative: I.e. the decoder and encoder mutually assume that each
knows exactly what processing steps are being undertaken. This
eliminates a lot of overhead that would be needed to signal behaviour
to the remote side.  This is also true to a lesser extent for other
formats, but since other formats are finalized the developers take
care to avoid format impacting changes.

Right now CELT is the only publicly available codec in its performance
group (decent music quality @ 64kbit/sec plus very low latency), so we
feel like we should take advantage of our lead to further improve the
performance. As a codec primarily intended for realtime use early
adopters can deal with incompatibility by negotiating.  We're also
trying to get CELT brought in as a standards track RFC in the IETF, so
we're keeping development open so that the bitstream can be enhanced
in the standards process. (Although some vendors of patent encumbered
codecs as well as participants from other standards bodies are
fighting pretty aggressively to keep royalty free codecs out of the
IETF)


I do not recommend shipping code from CELT git to third parties. It's
fairly likely that what you distribute will only be compatible with
itself.

There are already quite a few groups using CELT in production and its
perfectly reasonable to do so as long as you manage the fact that the
bitstream changes from version to version.

If you use CELT you should either standardize on a single supported
version I.e. "MyApp is used with 0.5.2"  or you need to signal the
version in use I.e. treat CELT052 and CELT061 as distinct codecs.
Applications can use multiple versions of the CELT lib by dlopening
the right one, though that requires a bit of development (and is
probably a pain to do cross platform).

For something like Ekiga, I'd recommend at least signalling the
version and offering CELT if both sides have matching versions. This
is much better than disabling it since it will just work if it can.