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
Jean-Marc, I hate to see the loss of flexibility (ie 44.1). How about a CFR/VFR switch so that you accommodate both variable and fixed frame sizes? Or does this complicate the code too much? MikeH -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/opus/attachments/20100518/fc7487bc/attachment-0002.htm
Hello Jean-Marc, I appreciate you taking our feedback in this change. I would be against this new input frame size change as I am developing on the TI 55x platform. On this platform it benefits to use the DSPLIB which REQUIRES a power of 2 frame size. My current setup is using a 48kHz sample rate and a 128 sample frame size (~2.5ms). Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/opus/attachments/20100518/92e7f099/attachment-0002.htm
Hi Jean-Marc, Having variable audio frame size will be very helpful, but I think still celt needs to support radix-2 frame sizes. - standard high quality sample rate 48k, 44k1 and 32k, it's very hard to find a sound system to have buit-in 51k2 sampling - software resampling is too costly, also when it comes to fractional resampling it's always adds some distortion due to interpolation. For dynamic frame sizes I suggest that in addition to those mentioned in your email, supporting another set of frame sizes regardless of sample rate, and that is: 64, 128, 256, 512 samples. Thanks, Hamid On Tue, May 18, 2010 at 4:17 AM, 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 >
I use CELT at 32000Hz at frame sizes of 320 samples (10 ms) and 512 samples (16 ms). I really need the 10 ms frame size, but I would be willing to give up the 16 ms frame size (it was chosen because I thought it might be faster) and change it to only use the 10 ms frame size if need be. Just my two cents. John Ridges celt-dev-request at xiph.org wrote:> Date: Mon, 17 May 2010 23:17:17 -0400 > From: Jean-Marc Valin <jean-marc.valin at usherbrooke.ca> > Subject: [CELT-dev] Variable frame size and API changes > To: celt-dev <celt-dev at xiph.org> > Message-ID: <4BF206BD.4080307 at usherbrooke.ca> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > 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 > > >
Hi Bob, A few questions/comments: 1) It may be possible to use the TI DSP for all of the radix-2 steps in the FFT and then only apply the radix 3 and 5 in C. 2) I assume that the sampling is done on the TI chip, so couldn't you just configure it to work at 51.2 kHz? This would produce frames that are powers of two and the resulting bit-stream would be perfectly compatible with a decoder running with the same frame duration (hence 15/16 the actual number of samples) at 48 kHz. Cheers, Jean-Marc Quoting Bob Bang <bob.bang2 at gmail.com>:> Hello Jean-Marc, I appreciate you taking our feedback in this change. > > I would be against this new input frame size change as I am developing on > the TI 55x platform. On this platform it benefits to use the DSPLIB which > REQUIRES a power of 2 frame size. > > My current setup is using a 48kHz sample rate and a 128 sample frame size > (~2.5ms).
Before we had total freedom over lag, samplerate and bitrate; we could also vary the bitrate at will. The new proposal would limit lag and samplerates... excluding the most common samplerate (at least for us and many devices). Are there any use-cases where it would be acceptable for lag to vary over time? -torg On Mon, May 17, 2010 at 8: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 >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/opus/attachments/20100518/f5f1c41a/attachment-0002.htm
Quoting Torgeir Hagland <torg at gaikai.com>:> Before we had total freedom over lag, samplerate and bitrate; we could also > vary the bitrate at will. The new proposal would limit lag and > samplerates... excluding the most common samplerate (at least for us and > many devices).OK, maybe my original email was mixing things a bit. It's not a matter of "we have to choose between variable frame size and flexible frame size". These are (mostly) decoupled. I added support for variable frame size already (see exp_variable_framesize branch) and now I'm trying to see how to update the API -- and at the same time what can be simplified. What I'm interested in here is knowing what people really use -- as opposed what they think is "nice to have" but have no use for. For example, I think it's fair to say that nobody ever uses a frame size of 286 (13*11*2) samples. Now, what else can be removed is the main question here.> Are there any use-cases where it would be acceptable for lag > to vary over time?Yes, the use case here is that as network bandwidth changes, you should be able to scale not only the quality, but also the delay. Cheers, Jean-Marc> -torg > > On Mon, May 17, 2010 at 8: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 > > >
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 >
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