On Sunday, August 12, 2012 14:36:34, Ron wrote:
[…]
> Celt was an entirely experimental codebase, each 'version' of it that
> was tagged existed *only* for testing the quality of the audio that it
> produced. Next to no attention was paid to the normal "release issues"
> of a piece of "production" software beyond what other people submitted
> as patches. Once the listening test results were in, code was changed,
> the bitstream broken as/if needed, and audio quality testing continued.
>
> Being free software, and an experiment conducted fully in the open,
> people were free to do with it what they wished -- but if they did,
> the onus was *entirely* on them to worry about release quality and
> maintenance issues. That's not something the upstream developers
> devoted any real attention to at all before the bitstream freeze.
>
> Opus by comparison has its C code as the normative part of an IETF
> proposed standard. An utterly insane number of hours went into
> QA testing it for "release issues" after the final bitstream freeze,
> and vetting it for precisely these sorts of problems (and that work
> is still ongoing). There are slides from one of the IETF meetings
> documenting some of that process -- and there are things that should
> be obvious from even a cursory look at the code - like Opus actually
> has a test suite, with near complete code coverage, that fuzzes the
> code intelligently on every run etc. etc.
>
> I won't go so far as to claim it's completely bug free. But people
> actually care if there is even a hint that it isn't. We're in an
> entirely different phase of the development now, where release
> polishing is at the forefront of What Matters to the maintainers.
> No version of celt had that sort of attention, especially not one
> as old as 0.7.1.
The web page for the Opus codec [1] shows that it's currently only a release
candidate. There isn't an official stable release yet; there are only
development snapshots available. That makes it seem as though Opus is still
considered experimental at this stage.
[…]
> Backing up a little bit: Assume that we all decide that it's
>okay to reintroduce celt. Do we actually have someone who is
>willing to do the work of reintroducing celt into the archive?
>I mean, is Ron willing to do that, or is someone else willing
>and capable to do it if Ron doesn't want to be stuck supporting
>it because he doesn't agree with it?
>
> We don't really want to reintroduce celt as a public package whatever
> is decided here. There really is nothing except mumble with any excuse
> to still be using this now. So the main question is, are we comfortable
> shipping mumble with it enabled as a private lib?
Shipping Mumble with CELT as a private lib is what most of the non-Debian free
distributions are doing. Interestingly, all of the non-Debian free
distributions also include an additional version of CELT over 0.7.1 as well.
Usually 0.11.0 but two distributions ship a CELT lib that Mumble reports as
"2.0.0" -- Fedora 17 and Magia 2.
> But AIUI that would involve downgrading all the clients in
> a channel to speex which might well be unacceptable to the
> userbase effectively making our version of the mumble client
> unuseable in those contexts.
>
> Talking about "downgrading" to speex is only meaningful when comparing
> it to opus. Celt isn't a speech coder, so it doesn't perform well under
> conditions where speex does, and vice versa. Neither is clearly "down"
> from the other, at least not when comparing with celt 0.7.1. They are
> different tools, specialised for different jobs.
>
> It would be just as valid to say that "downgrading to celt 0.7.1" would
> have the effect you mention. And that's empirically true because there
> are already people blocking its use on their servers, and the number of
> people doing that will only grow over the lifetime of Wheezy now that
> they can do it just by setting opusthreshold instead of hacking at the
> code to change the permitted celt versions.
If you're going to make the claim that people are blocking CELT then you need
to state who you've found doing this, becasue I've now tested the top 25 free
software distributions [as measured by distrowatch.com], and of the
distributions that ship Mumble, they all ship with CELT. Out of all of these,
only the Debian Sid version of Mumble ships with support for Opus.
I did not try to test all those distros for their version of mumble-server,
and I suspect there is not likely to be time before we need to make a decision
to allow doing so.
> Celt 0.7.1 gives poor results at bitrates where both opus and speex shine.
>
>
> dondelelcaro: I think we know that if we reenable the embedded
> celt it will work as intended with existing clients.
>
> We do gain an extra possible dimension of interoperability. Unfortunately
> that's not enough on its own to ensure it w
