Re: [codec] Next Steps for WG

[Roman Shpount <[e-mail]>]

My question was not as much about the VAD, as about multiple stream
combining. What I want is to implement is switching between multiple talker
based on VAD (computation of which is done by some external methods). In
this case we need to indicate to the remote party that this is a new stream
and ideally get the remote decoder in such a state that it can immediately
start correctly decoding the new audio without a glitch. So, the minimum
requirement would be to have a flag or a packet that indicates the decoder
that it needs to reset its state. Ideally, we need an algorithm to get the
proper decoder state based on some audio history stored on the conferencing
server, and to send this decoder state to the remote party so that it can be
synchronized. I don't think this should affect the codec performance. This
is just something that needs to be accommodated in the bitstream by adding a
packet type which either resets the decoder state or sets it to some
specified value.

I would also prefer if this was working across all the codec modes and did
not require the conferencing server from restricting what kinds of encoded
audio it can accept.
_____________
Roman Shpount


On Fri, Jan 14, 2011 at 4:41 PM, Koen Vos <[e-mail]> wrote:

> Even without DTX, the Voice modes will expose a Voice Activity flag in the
> decoder API. This will reveal without any decoding whether a payload
> contains active speech.
>
> And all decoder modes have low CPU demands, so decoding all streams to
> determine which ones are most active is relatively cheap.
>
> koen.
>
>
> ----- Original Message -----
> From: "Christian Hoene" <[e-mail]>
> To: "Jean-Marc Valin" <[e-mail]>, "Roman Shpount" <
> [e-mail]>
> Cc: [e-mail]
> Sent: Friday, January 14, 2011 12:27:02 AM
> Subject: Re: [codec] Next Steps for WG
>
> The easiest way to mix the multiple streams is to take advantage of the DTX
> feature, which is available in the Silk and hybrid mode. However, I am not
> aware whether DTX or VAD is supported in the CELT mode.
>
> Christian
>
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On Behalf
> > Of Jean-Marc Valin
> > Sent: Friday, January 14, 2011 3:51 AM
> > To: Roman Shpount
> > Cc: [e-mail]
> > Subject: Re: [codec] Next Steps for WG
> >
> > Hi Roman,
> >
> > We believe that we meet all requirements that were identified. As for
> mixing
> > multiple encoded streams, that was marked as desirable in the draft
> because
> > it's very hard to achieve without sacrificing efficiency.
> > To some extent, if you constrain the Opus encoder to a subset of the
> > available options (CELT only without short blocks or post-filter), then
> you can
> > create streams that can be mixed at roughly half the normal complexity. I
> > think that's about as much as we can do here.
> >
> > Cheers,
> >
> >       Jean-Marc
> >
> > On 11-01-13 07:34 PM, Roman Shpount wrote:
> > > Just out of curiosity, have the OPUS codec been review against the
> > > list of requirements that we put together?
> > >
> > > In particular, I raised the requirement that multiple encoded streams
> > > form different sources can be efficiently combined. Is it possible
> > > with OPUS? If it is, then how?
> > > _____________________________
> > > Roman Shpount - www.telurix.com <http://www.telurix.com>
> > >
> > >
> > > On Thu, Jan 13, 2011 at 5:29 PM, Cullen Jennings <[e-mail]
> > > <mailto:[e-mail]>> wrote:
> > >
> > >
> > >     The OPUS draft authors believe the bitstream for OPUS will be ready
> > >     to be "frozen" by the end of the month. At that point we plan to
> > >     spend the following month testing and, baring any surprises, will
> > >     likely go to WGLC after that.
> > >
> > >     There has been some questions about what "frozen" means in IETF
> > >     context. The bitstream could change any time up to when the IESG
> > >     approves it which is after Working Group Last call and after IETF
> > >     Last Call so there is no guarantee that nothing will change but ...
> > >       by "frozen" we mean that we believe no changes are needed and
> > >     don't plan to make changes unless some significant problem is
> found.
> > >
> > >     Thanks,
> > >     Cullen, Jonathan, and Mike
> > >
> > >
> > >     _______________________________________________
> > >     codec mailing list
> > >     [e-mail] <mailto:[e-mail]>
> > >     https://www.ietf.org/mailman/listinfo/codec
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > codec mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/codec
> > _______________________________________________
> > codec mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/codec
>
> _______________________________________________
> codec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/codec
>