Bug#603699: Unbundling obsession
Greetings. I'm one of the developers of CELT.
Paul Wise recently joined our IRC channel on Freenode (#celt), pointed
out some bugs, fired off some barbs and then departed. I thought I'd
come here and leave a comment.
Each version of the CELT bitstream can be regarded as a distinct
codec. This is the case for two reasons: One, CELT is still under
development and two, the low latency requirement leaves no room for
extensive signaling of behavior by the encoder— so when the format is
frozen the room for quality improvements will be very limited.
(At the moment it's unclear if there ever will be a 1.0 version of
CELT however, We're currently merging the codec with Skype's SILK
codec as part of an IETF process. Unless some important CELT
functionality is lost in the merging process there should be no reason
for CELT to continue to exist independently)
SPICE is using CELT because CELT offers a combination of features
which is not available in any other published codec, though there are
some closed source and patent encumbered codecs which come close—
there is noting even close which was suitable for SPICE. These
features— very low latency, reasonable bitrate, high quality are all
critical to SPICE. There was no way a 1.0 CELT would be ready in time
for SPICE so the next best thing was done: A line in the sand was
drawn establishing the CELT 0.5.1 bitstream as standard for SPICE.
Subsequently we have done a couple of bug-fix releases compatible with
0.5.1. Though it would appear that the current code on that branch is
now BugFree™.
I mean that only half in the sense of "all bugs are features". The
CELT codebase has been mature and stable for a long time long time.
It's only the codec which is changing.
We could have simply called each and every version of CELT a new
codec/library name: CELT->BLOOP->PLORT->GARBAM->ZINGABAR->TOOT. If
we'd done this we almost would have certainty escaped the attempts of
GNU/Linux distributions to force all users onto the single most recent
version, but— frankly— coming up with names is hard. Constant
renaming would be a lot of work just to appease obsessive rule-bound
packagers who are behaving in a manner unrelated to reality.
I strongly support the general principle of avoiding bundling. It
makes a ton sense not ship ten copies of the same thing— but in this
case different versions of CELT are not the same thing. They are
functionally different. Refusing to include the copy of CELT that
SPICE needs is basically equivalent to refusing to include CELT
because the distribution already has Vorbis.
The CELT library itself is now only about 10kloc (comments,
whitespace, and all). The amount of code which is logically sharable
between the 0.5.1 package and 0.9.1 package is probably only a little
greater to the amount of code which could be logically shared between
CELT and libvorbis (not much, mostly core DSP routines). Meanwhile
many C applications ship their own complicated associative array and
hash table implementations with comparable complexity. Distributors
don't mind this duplication because no one was foolish enough to stick
a name on some of this internal code and reuse it with modifications
in a few places.
The howling at SPICE here is really intolerable. I would rather debian
not package our software at all than engage in this sort of behavior.
CELT 0.7.1 was shipped over a year after 0.5.1, much too late for
SPICE. As far as I'm aware the only big users of CELT in debian is
mumble, and the overwhelming majority of the mumble users are on other
platforms using bundled versions. As far as I can tell the interest in
0.7.1 comes not from any great meeting of the minds— 0.7.1 is simply
what was out when Mumble fixed on a version and they had no
requirement to be compatible with what SPICE was using. Had you
brought the spice developers to the table instead of the mumble ones
you probably would have decided on 0.5.1.
Fortunately it isn't all that difficult to link to multiple versions—
the Mumble codebase now supports doing that. It's a reasonable
solution for applications making a transition from one version to
another. As is sticking with an old version.
Reply to: