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. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimgvi8qkpq3q+t=bke7kdu_wqy+zde4qzghc...@mail.gmail.com