[CELT-dev] multichannel

[Jean-Marc Valin]

OK, here's the fine print. The frames are coded independently, but
there's still a tiny bit of memory (typicaly 64 samples) that is used to
make a smooth transition between blocks (plus a single filter memory
coefficient for the de-emphasis). None of that has an impact on the
re-synchronisation, which is why I still say that the frames are
independent. Outside of PCM codecs, no codec that I know of has frames
with zero overlap and memory because that would cause artefacts at the
frame boundaries. Hope that clarifies things.

Now, if you *really* need to save space, you can always hack something
to store separately just the 65 coefficients that are really important
and different from one stream to the other and then use just one state.

	Jean-Marc

Chen-Po Sun a écrit :
> Hi,
> 
> I've been working on multichannel celt support myself for FMOD, and just
> wanted to confirm some things.
> 
> I am finding that for n channel streams, I need to have n decoder
> instances, one decoder instance for each channel.  If I try to decode
> all channels with just one decoder instance, I get audio corruption.
> 
> I always thought that each decode was completely independant and didn't
> rely on any state built up from previous decodes or anything like that
> (i have interframe prediction and pitch prediction turned off during
> encoding), but this seems to show the contrary?
> 
> 
> 
> *Chen-Po Sun* | Programmer
> Firelight Technologies Pty Ltd.
> FMOD Sound System | www.fmod.org
> PH: +61 3 96635947 Fax: +61 3 96635951
> 
> 
> Jean-Marc Valin wrote:
>> Quoting Dirk Griffioen <dirk.griffioen at barcelonamedia.org>:
>>   
>>> I would like to encode multiple channels of audio, the input being for
>>> instance
>>> - a multichannel (wav) file
>>> - n jack sources
>>>
>>> And in the end stream low latency over RTP (for instance in a Gstreamer
>>> pipeline); currently I use vorbis, and although it is very convenient
>>> channelwise, the added latency is too high to be of use and I need
>>> compression to keep the bandwith reasonable.
>>>
>>> As I understand it now I will have to write both the interleaving bit
>>> and the celt n channel rtp payloader.
>>>     
>>
>> The RTP payload format defines everything you need to do to stream multi-channel
>> CELT audio. You happen to need more than one encoder state, but that's just an
>> implementation detail. The only thing that doesn't support >2 channels (for
>> now) is the Ogg software (celtenc/celtdec), but then again they're mostly toys
>> because there's no real reason to use CELT for encoding files.
>>
>> 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