Re: [Jack-Devel] Switch from CELT to Opus in JACK1/JACK2 sources

PrevNext  Index
DateFri, 07 Sep 2012 20:20:38 -0500
From Jack O'Quin <[hidden] at gmail dot com>
ToRobin Gareus <[hidden] at gareus dot org>
CcAdrian Knoth <[hidden] at drcomp dot erfurt dot thur dot de>, JACK <[hidden] at lists dot jackaudio dot org>
In-Reply-ToRobin Gareus Re: [Jack-Devel] Switch from CELT to Opus in JACK1/JACK2 sources
On Sep 7, 2012 7:45 PM, "Robin Gareus" <[hidden]> wrote:
>
> On 09/08/2012 01:36 AM, Jack O'Quin wrote:
> > Some naive questions come to mind:
> >
> >  * Why did Debian decide to stop packaging CELT?
>
> - celt is no longer maintained and has been deprecated upstream.
> - opus is the successor of CELT. CELT has been merged into Opus.
>
> (CELT was likely dropped early to force people to adopt Opus)
>
> >  * What are the advantages and disadvantages of CELT vs. Opus?
>
> The problem we have is that libcelt comes with "--enable-custom-modes"
> by default, but libopus does not -- Otherwise there are no disadvantages
> of using Opus.
>
> re "custom modes": https://wiki.xiph.org/OpusFAQ#What_is_Opus_Custom.3F
> (they allow block-sizes other than multiples of 2.5 ms)
>
> The main disadvantage of CELT is its limited bitrate range:
> CELT: 32 kb/s to 128 kb/s
> Opus:  6 kb/s to 510 kb/s
>
> Opus adds support for VBR.  Bitrate, bandwidth and frame-sizes can call
> be adjusted dynamically. The quality has apparently improved, too, but I
> have not done direct comparisons nor measurements on that myself.
> http://opus-codec.org/comparison/quality.svg
> I only checked out the examples at http://opus-codec.org/examples/ --
> well actually I attended Tim's presentation of it at FOMS earlier this
> week where he played them.
>
> >  * If JACK ends up packaging and distributing the library, anyway, is
> > it an option to continue using CELT?
>
> It is an option, but there is no gain - except that there'd be no new
> code needed. Yet /upgrading/ from CELT to Opus is pretty much a
> s/celt_/opus_/g and Opus performs much better (less CPU, better
> compression or better quality at same bitrate).
>
> robin

OK, thanks Robin.

That's what I figured, but didn't know.
PrevNext  Index

1347067243.6761_0.ltw:2,a <CAB6SgyU=t4tSqmd2qPYUk2QOV_DXOAZTDYndYfvNBcWMWWi_Xw at mail dot gmail dot com>