[CELT-dev] Variable frame size and API changes

[Torgeir Hagland]

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). Are there any use-cases where it would be acceptable for lag
to vary over time?

-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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.xiph.org/pipermail/opus/attachments/20100518/f5f1c41a/attachment-0002.htm