Tom Grandgent
2005-Jul-12 13:22 UTC
[Speex-dev] sharing a decoder between 2 inbound speex streams?
You definitely need to have separate decoders for separate streams. It has been mentioned before that inter-frame state is critical to achieving the level of quality for bandwidth that Speex offers. This differentiates it from iLBC, a codec whose claim to fame is that it treats each frame independently. I'm not sure what's hard about maintaining multiple decoder states, unless you are extremely resource-constrained or doing something unusual. Normally all you have to do is create a decoder state for each new client and free it when the client is gone.>---- Original Message ---- >From: tone@mailblocks.com >To: speex-dev@xiph.org >Subject: RE: [Speex-dev] sharing a decoder between 2 inbound speex >streams? >Date: Tue, 12 Jul 2005 16:03:02 -0400 > >>This is a hard one to search for in the archives, and I checked the >FAQ >>and the PDFs. >> >>If a VOIP application wants to support the ability to output >multiple >>inbound streams (from separate senders who happened to choose the >same >>moment to start speaking), is it a requirement to have separate >>decoders for each, or could one be used in a round-robin manner to >>service packets from the multiple senders? >> >>I am guessing that I should use a separate decoder for each inbound >>stream of frames, and that there is significant inter-frame state >>maintained by the decoder, but the convenience of not having to have >a >>decoder free pool to dynamically allocate/deallocate these is >>motivation enough to ask! >> >>Tony Lovell >>http://dreadnoughtproject.org >>tone@dreadnoughtproject.org >>AIM: StupidLagger >> >> >>_______________________________________________ >>Speex-dev mailing list >>Speex-dev@xiph.org >>http://lists.xiph.org/mailman/listinfo/speex-dev
Matt DeMoss
2005-Jul-17 09:44 UTC
[Speex-dev] sharing a decoder between 2 inbound speex streams?
What does it sound like if you try to use only one decoder state for multiple streams? Tom Grandgent wrote:>You definitely need to have separate decoders for separate streams. >It has been mentioned before that inter-frame state is critical to >achieving the level of quality for bandwidth that Speex offers. This >differentiates it from iLBC, a codec whose claim to fame is that it >treats each frame independently. > >I'm not sure what's hard about maintaining multiple decoder states, >unless you are extremely resource-constrained or doing something >unusual. Normally all you have to do is create a decoder state for >each new client and free it when the client is gone. > > > >>---- Original Message ---- >>From: tone@mailblocks.com >>To: speex-dev@xiph.org >>Subject: RE: [Speex-dev] sharing a decoder between 2 inbound speex >>streams? >>Date: Tue, 12 Jul 2005 16:03:02 -0400 >> >> >> >>>This is a hard one to search for in the archives, and I checked the >>> >>> >>FAQ >> >> >>>and the PDFs. >>> >>>If a VOIP application wants to support the ability to output >>> >>> >>multiple >> >> >>>inbound streams (from separate senders who happened to choose the >>> >>> >>same >> >> >>>moment to start speaking), is it a requirement to have separate >>>decoders for each, or could one be used in a round-robin manner to >>>service packets from the multiple senders? >>> >>>I am guessing that I should use a separate decoder for each inbound >>>stream of frames, and that there is significant inter-frame state >>>maintained by the decoder, but the convenience of not having to have >>> >>> >>a >> >> >>>decoder free pool to dynamically allocate/deallocate these is >>>motivation enough to ask! >>> >>>Tony Lovell >>>http://dreadnoughtproject.org >>>tone@dreadnoughtproject.org >>>AIM: StupidLagger >>> >>> >>>_______________________________________________ >>>Speex-dev mailing list >>>Speex-dev@xiph.org >>>http://lists.xiph.org/mailman/listinfo/speex-dev >>> >>> > > >_______________________________________________ >Speex-dev mailing list >Speex-dev@xiph.org >http://lists.xiph.org/mailman/listinfo/speex-dev > > >
SteveK
2005-Jul-17 13:30 UTC
[Speex-dev] sharing a decoder between 2 inbound speex streams?
On Jul 17, 2005, at 12:44 PM, Matt DeMoss wrote:> What does it sound like if you try to use only one decoder state > for multiple streams?Assuming they are set up to use the same format (i.e. narrowband vs wideband), each time you switch streams, there will be some residual excitation from the previous stream. It will probably recover completely in a couple of seconds at most. However, if you try to simultaneously decode two streams with one decoder state, you'll get terrible results. -SteveK> > > Tom Grandgent wrote: > > >> You definitely need to have separate decoders for separate >> streams. It has been mentioned before that inter-frame state is >> critical to >> achieving the level of quality for bandwidth that Speex offers. This >> differentiates it from iLBC, a codec whose claim to fame is that it >> treats each frame independently. >> >> I'm not sure what's hard about maintaining multiple decoder states, >> unless you are extremely resource-constrained or doing something >> unusual. Normally all you have to do is create a decoder state for >> each new client and free it when the client is gone. >> >> >> >>> ---- Original Message ---- >>> From: tone@mailblocks.com >>> To: speex-dev@xiph.org >>> Subject: RE: [Speex-dev] sharing a decoder between 2 inbound speex >>> streams? >>> Date: Tue, 12 Jul 2005 16:03:02 -0400 >>> >>> >>> >>>> This is a hard one to search for in the archives, and I checked the >>>> >>>> >>> FAQ >>> >>>> and the PDFs. >>>> >>>> If a VOIP application wants to support the ability to output >>>> >>>> >>> multiple >>> >>>> inbound streams (from separate senders who happened to choose the >>>> >>>> >>> same >>> >>>> moment to start speaking), is it a requirement to have separate >>>> decoders for each, or could one be used in a round-robin manner >>>> to service packets from the multiple senders? >>>> >>>> I am guessing that I should use a separate decoder for each >>>> inbound stream of frames, and that there is significant inter- >>>> frame state maintained by the decoder, but the convenience of >>>> not having to have >>>> >>>> >>> a >>> >>>> decoder free pool to dynamically allocate/deallocate these is >>>> motivation enough to ask! >>>> >>>> Tony Lovell >>>> http://dreadnoughtproject.org >>>> tone@dreadnoughtproject.org >>>> AIM: StupidLagger >>>> >>>> >>>> _______________________________________________ >>>> Speex-dev mailing list >>>> Speex-dev@xiph.org >>>> http://lists.xiph.org/mailman/listinfo/speex-dev >>>> >>>> >> >> >> _______________________________________________ >> Speex-dev mailing list >> Speex-dev@xiph.org >> http://lists.xiph.org/mailman/listinfo/speex-dev >> >> >> > > _______________________________________________ > Speex-dev mailing list > Speex-dev@xiph.org > http://lists.xiph.org/mailman/listinfo/speex-dev > >