[CELT-dev] Variable frame size and API changes

[Jean-Marc Valin]

Indeed, considering that 9*2.5 != 24, it's even more unlikely! I'm starting to
see a lot of configurations I thought nobody was using. This needs more
thought.

   Jean-Marc

Quoting Pascal Charest <c.lacsap at gmail.com>:
> 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
> >
>
>