[FFmpeg-devel] Important: upcoming CELT bitstream freeze!

[Jason Garrett-Glaser]

To all ffmpeg devs,

The CELT audio codec will soon have its bitstream permanently frozen
and standardized.  For those unaware, CELT is a next-generation audio
codec with a whole host of extremely unusual and powerful compression
features.  It's MDCT-based and is built around low latency (~5ms)
operation.  Despite the compression impact of much smaller frame
sizes, it easily outperforms MP3 and, at very low rates, can beat
aoTuv Vorbis on many samples.

The primary target of CELT is low-latency audio applications.  CELT's
compression capability is particularly incredible at high frequencies
-- as a result, it's also being combined with Skype's SILK codec to
create Opus, a hybrid codec with CELT handling high frequencies and
Opus handling low ones, for extremely scalable and low-latency audio
compression.  Despite the lack of a bitstream freeze, CELT is
*already* being used in large-scale commercial low-latency
applications, as there is quite literally no other audio format that
serves quite the same niche.

ffmpeg will some day end up implementing a decoder for CELT.  And when
you do, you probably don't want to be spending half the time thinking
to yourself "what in God's name were the people writing this
thinking?!?!"  So, with about 1-2 months left until the bitstream
freeze, CELT wants *you* to tell them how they can make things better
and/or less braindead.  This is extra-important for CELT, as CELT (due
to its design and to limit signalling overhead) hardcodes far more
information into the bitstream format than most audio codecs, making
it more difficult to change things later.

In short: we need your comments!  Bitch about the design, bitch about
the code, bitch about the features, and tell the Celt devs what's
wrong, because there's not much longer before it can no longer be
fixed!

Note there is not currently a full spec -- this will be written at
some point, but the bitstream freeze will (obviously) have to be done
before then!

Some useful links:

Website: http://celt-codec.org/

git: git://git.xiph.org/celt.git

IRC: #celt on Freenode (feel free to drop by at any point to ask
questions or clarifications -- or tell people they're incredibly
stupid).

Journal paper describing 0.3.2: http://jmvalin.ca/papers/celt_tasl.pdf

Conference paper describing 0.5.1: http://jmvalin.ca/papers/celt_eusipco2009.pdf

A high level description of the codec as of 0.7/0.8. Some things have
been added/removed since then (and the side information is fairly
different) but things like the binary packing, vector quantizer, etc
have not changed. It also includes a copy of the codec with all the
fixed point macros stripped:
http://tools.ietf.org/html/draft-valin-celt-codec-02

High level overview presentation: http://www.celt-codec.org/presentations/

Some comments from dev jmspeex:

In the end, there are two things that are useful:
1) People listening to samples, comparing to other codecs, pointing
out anything that really stands out.
2) People looking at the code, seeing bits that don't make sense.
Several people have already found issues in the code despite not
understanding all of it.

Some comments from dev gmaxwell:

As far as reading the code. The signal processing parts have a great
deal of macros used so that the same code base is both fixed and
floating point code. In floating point the macros are almost all
no-ops. So it takes a little getting used to but it's not actually
hard to read.
One challenge is that everyone here working on the code more or less
understands it. So there may be some idiot mistakes that we're blind
to because we 'understand' what it does.

Jason