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. […] > <rra> 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. > <Diziet> 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. > > > <Diziet> 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 will work with other existing > clients and servers - either at all, or with acceptable results. Of the 19 other distributions that ship Mumble, all of them are compatible with CELT 0.7.1 (or will be -- Magia 2 has a bug because of library name mangling, so even though they ship a CELT 0.7.1 bundled library Mumble can't find the file -- this is being worked on to fix it) and I tested that (all but Magia 2) are currently interoperable. […] > And the SECCOMP sandboxed version of celt has been pushed upstream now. > The guy who worked on that sounds like he's pretty happy with it, but I > looked at the code and do worry that it's probably too big a change to > push into a stable release without more live testing, and probably a > few other pairs of eyes auditing it. It seems to be a good answer that > I don't totally want to take off the table, but probably not something > that could seriously be considered for wheezy proper without more people > taking an intense interest in it very soon. I also saw that show up in the upstream repo a couple of days ago, and it looks interesting. I've been too busy with Mumble testing to look at it closely, though. [1] http://opus-codec.org/ -- Chris -- Chris Knadle Chris.Knadle@coredump.us
Attachment:
signature.asc
Description: This is a digitally signed message part.