[gst-devel] comfort noise generation bin

[Marco Ballesio]

2010/4/27 Olivier Crête <olivier.crete at collabora.co.uk>

> On Mon, 2010-04-26 at 18:49 -0500, pl bossart wrote:
> > > Oops, I though rtpjitterbuffer would generate a lost packet message
> > > after a certain amount of time, but it seems to only generate it on the
> > > next packet after a gap. So you are right, it is not a good solution.
> >
> > I am not sure if this is the same mechanism, but the g72xdepay
> > elements mark the first buffer after a talk burst as DISCONT as per
> > the RTP spec. However this is somewhat unusable for the decoder since
> > there are no indicators of the start of the silence part...
>
> I don't think the decoder should be generating CNG without getting a SID
> frame, otherwise we may end up getting CN when we really had packet
> loss.


The effect may not be that bad, but what to do in case of packet loss is
generally unspecified. In a sci-fi scenario we could even generate in such a
case a comfort noise with a spectrum similar to the one of the last n
packets received (so that for a 10ms loss the user will not even perceive a
loss of quality). Indeed it's definitely OT with the current thread and in
some cases it's not something we really want in.


> So the start isn't too hard to guess. The problem is that the
> every decoder then needs to have a thread started when a CN packet is
> received that will generate the frames until it is stopped. And then the
> decoder may not know it should really stop if the use switched codecs
> during a silence period.
>

I would like to move the feature outside the decoder, as I was proposing in
my original email I was thinking to something like the dtmf generator.  The
bin can be controlled from the depayloader / decoder through well defined
APIs (properties? events?). This way we have a unique control point for the
extra-source with all the benefits coming from that like e.g. code
re-usability (and we know a bad implementation may make the thread run
forever, using unexpected CPU/power, etc).


>
> >
> > > I still think we need some kind of arbitration to not have more than
> one
> > > decoder produce silence since Farsight2 will keep the previous decoders
> > > if the sender starts sending on a new PT. That's why I wanted to do it
> > > as late as possible (in the mixer).
> >
> > Comfort Noise is generated mainly so that the receiver doesn't think
> > the line is dead. Granted, if this is a multi-party call the need for
> > CNG is less important. Chances are someone will be talking.
> > Nevertheless, the decision to go to SID frames is made by each
> > transmitter, the receiver can't do much in terms of arbitration:
> > either you support CNG or you don't....
>
> I guess maybe the decoder could just set GST_BUFFER_FLAG_GAP
> on the CNG buffers. Then the mixer can be made to ignore buffers that
> have this flag set.
>

The external bin may act as a control point here: given n "registered"
decoders/depayloaders it may be coded to generate CN only when they've all
received the SID packet sending it the appropriate message.

Regards


>
>
> --
> Olivier Crête
> olivier.crete at collabora.co.uk
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20100429/692bf36a/attachment.htm>