[CELT-dev] Variable frame size and API changes

[Pascal Charest]

Hi Jean-Marc,

As you will recall, at CRC we use the CELT codec as a proof of concept
for building a digital radio royalty-free stack based on DAB,
including codecs. Interestingly, DAB is about to become a royalty-free
broadcast technology (soon older than 20 years).

DAB frame size is based on MPEG1/2 audio, which is 24ms. As such, any
24ms compatible frame size would keep the CELT over DAB framing easier
(e.g. 24, 12, 8, 6, ... ms).

To be fair with you, the project has not gained serious attention yet.
But we like to demonstrate CELT over DAB at broadcasting conferences
such as IBC and NAB to promote the use of RF codecs in the context of
digital radio broadcasting. We realize that the IETF effort does not
target broadcast systems but keeping compatibility with DAB could be
of interest... at least from our perspective... for what it is worth!

Right now, we have CELT over DAB demos that work on Linux, Openmoko
and Android. Here are some links to our open source transmitter and
receiver that implement CELT over DAB:

<http://mmbtools.crc.ca/content/view/38/64/>
<http://mmbtools.crc.ca/content/view/42/68/>
<http://openmokast.org/>
<http://openmokast.org/android.html>

Regards,

Pascal Charest

On Mon, May 17, 2010 at 11: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
>