[CELT-dev] Variable frame size and API changes

[Jean-Marc Valin]

Hi everyone,

So for the time being, I'm keeping support for other frame sizes. I 
might eventually drop support for the ones that aren't composed of 
powers of 2, 3 and 5, but I don't think anyone uses that (and the 
quality of those is already bad).

As some of you may have noticed, I just pushed about 30 commits to the 
master branch, so I might have broken a few things. Please let me know 
if that's the case. I'm also interested in comments on any quality 
improvement or degradation. There's also a minor API change in there, 
where the frame size needs also be specified for the encode/decode call.

Cheers,

	Jean-Marc

On 10-05-20 04:22 AM, Feilen, Michael wrote:
> 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
>
>