[CELT-dev] Variable frame size and API changes

Sat May 22 00:26:19 PDT 2010

Hej Jean-Marc,

that's great news ! Thanks for your kind approach and the great work in general. In terms of quality improvements I will hopefully revisit the older ideas on the PLC soon.

All the best

-- A l e x

Dr.-Ing. Alexander Carôt 
Email : Alexander at Carot.de 
Tel.: +49 (0)177 5719797 

Am 22.05.2010 um 04:45 schrieb 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
>> 
>> 