[CELT-dev] Variable frame size and API changes

[John Ridges]

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
>
>
>