[CELT-dev] Variable frame size and API changes

[Feilen, Michael]

Hi Jean-Marc.

We've implemented CELT in a Digital Radio Mondiale Plus (DRM+) transceiver chain using v0.7.1 with a framesize of 960 samples per frame. We are VERY glad that it was possible to choose a somewhat uncommon framesize as for now CELT seems to be the only open-source alternative to the proprietary AAC+ encoder from Dolby. For DRM+ and probably also for the DAB guys keeping a preset of 960 samples per frame would be great!

Cheers,
Michael

-----Ursprüngliche Nachricht-----
Von: celt-dev-bounces at xiph.org [mailto:celt-dev-bounces at xiph.org] Im Auftrag von Jean-Marc Valin
Gesendet: Donnerstag, 20. Mai 2010 02:59
An: Alexander Carôt
Cc: celt-dev
Betreff: Re: [CELT-dev] Variable frame size and API changes

Hi (responding to everyone, not just you Alex),

The thing is that "flexibility" is quite vague. What I'm after here are 
the actual use cases. What frame size and bitrate are people using and 
why. I want to support what people actually use, not what they think 
could be useful for others. So far a bunch of people have replied with 
their actual use cases, which I'll try not to break. Are there any other 
setting *actually* being used?

Cheers,

	Jean-Marc

On 10-05-19 07:12 AM, Alexander Carôt wrote:
> Hello again,
>
> I actually think that the flexibility CELT offers by providing any
> desired framesize is a great feature, which IMHO should be
> maintained. I understand your point as an interesting approach,
> however I'd rather vote for having it as an additional feature, which
> does not violate the existing implementation (if possible at all).
>
> Best regards
>
> -- A l e x
>
> Dr.-Ing. Alexander Carôt Email : Alexander at Carot.de Tel.: +49 (0)177
> 5719797
>
> Am 18.05.2010 um 05:17 schrieb Jean-Marc Valin:
>
>> 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
>
>
>
_______________________________________________
celt-dev mailing list
celt-dev at xiph.org
http://lists.xiph.org/mailman/listinfo/celt-dev