[CELT-dev] Variable frame size and API changes

[Jean-Marc Valin]

Hi,

Note that what I was proposing already included 10 ms frames at any sampling
rate (as long as 10 ms is a multiple of 8 samples). So your main use case is
covered.

Seeing the comments about 44.1 and power-of-two at 48 kHz, I'll consider adding
one of those (or both) as "non-standard" modes. By that, I mean that you could
use it in your own application, but use over RTP would be discouraged. The idea
here is compatibility. You don't want to end up in a situation where only
client only speaks CELT at 44.1 kHz/512 samples and the other one only
understands 48 kHz/480 samples. Of course, you could make clients support all
of those, but then you're even worse than just supporting one. My goal here is
not to mess up people's applications, but to maximize interoperability.

Cheers,

    Jean-Marc

Quoting John Ridges <jridges at masque.com>:

> I use CELT at 32000Hz at frame sizes of 320 samples (10 ms) and 512
> samples (16 ms). I really need the 10 ms frame size, but I would be
> willing to give up the 16 ms frame size (it was chosen because I thought
> it might be faster) and change it to only use the 10 ms frame size if
> need be. Just my two cents.
>
> John Ridges
>
>
> celt-dev-request at xiph.org wrote:
> > Date: Mon, 17 May 2010 23:17:17 -0400
> > From: Jean-Marc Valin <jean-marc.valin at usherbrooke.ca>
> > Subject: [CELT-dev] Variable frame size and API changes
> > To: celt-dev <celt-dev at xiph.org>
> > Message-ID: <4BF206BD.4080307 at usherbrooke.ca>
> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> >
> > Hi everyone,
> >
> > I've recently been making various changes to the way the modes work and
> > the supported frame size. On new feature that may be of interest to some
> > is that CELT should soon support changing the frame size dynamically
> > within a stream. By that I mean varying the amount of audio (in time)
> > transmitted at once, not the compressed size -- which has always been
> > variable. That would allow dynamically trading compression efficiency
> > for delay.
> >
> > Now, one potential side effect of this work is that I may actually
> > remove some of the flexibility in the frame size. So far, CELT has
> > always been insanely flexible when it came to choosing the frame size.
> > For example, you could encode with frames of (e.g. 494 samples if you
> > wanted to). What I'm now considering is restricting the available frame
> > sizes to 2.5 ms, 5 ms, 10 ms and 20 ms. Those could be supported at any
> > sampling rate where 2.5 ms represents an even number of samples, e.g. 32
> > kHz or 48 kHz. However, that would exclude 44.1 kHz, so I'd like to know
> > if people are actually using CELT at that sampling rate? One other side
> > effect is that you would no longer have frames that are a power of two
> > in samples -- unless you use 51.2 kHz as the sampling rate (which would
> > be supported).
> >
> > Any comments on this? Anyone has major reasons not to do that?
> >
> > Cheers,
> >
> > 	Jean-Marc
> >
> >
> >
>
> _______________________________________________
> celt-dev mailing list
> celt-dev at xiph.org
> http://lists.xiph.org/mailman/listinfo/celt-dev
>
>