[CELT-dev] Variable frame size and API changes

[Jean-Marc Valin]

Quoting Torgeir Hagland <torg at gaikai.com>:
> Before we had total freedom over lag, samplerate and bitrate; we could also
> vary the bitrate at will. The new proposal would limit lag and
> samplerates... excluding the most common samplerate (at least for us and
> many devices).

OK, maybe my original email was mixing things a bit. It's not a matter of "we
have to choose between variable frame size and flexible frame size". These are
(mostly) decoupled. I added support for variable frame size already (see
exp_variable_framesize branch) and now I'm trying to see how to update the API
-- and at the same time what can be simplified.

What I'm interested in here is knowing what people really use -- as opposed what
they think is "nice to have" but have no use for. For example, I think it's
fair to say that nobody ever uses a frame size of 286 (13*11*2) samples. Now,
what else can be removed is the main question here.

> Are there any use-cases where it would be acceptable for lag
> to vary over time?

Yes, the use case here is that as network bandwidth changes, you should be able
to scale not only the quality, but also the delay.

Cheers,

   Jean-Marc

> -torg
>
> On Mon, May 17, 2010 at 8:17 PM, Jean-Marc Valin <
> jean-marc.valin at usherbrooke.ca> wrote:
>
> > 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
> >
>