<br><br><div class="gmail_quote">2010/4/27 Olivier Crête <span dir="ltr"><<a href="mailto:olivier.crete@collabora.co.uk">olivier.crete@collabora.co.uk</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div class="im">On Mon, 2010-04-26 at 18:49 -0500, pl bossart wrote:<br> > > Oops, I though rtpjitterbuffer would generate a lost packet message<br> > > after a certain amount of time, but it seems to only generate it on the<br> > > next packet after a gap. So you are right, it is not a good solution.<br> ><br> > I am not sure if this is the same mechanism, but the g72xdepay<br> > elements mark the first buffer after a talk burst as DISCONT as per<br> > the RTP spec. However this is somewhat unusable for the decoder since<br> > there are no indicators of the start of the silence part...<br> <br> </div>I don't think the decoder should be generating CNG without getting a SID<br> frame, otherwise we may end up getting CN when we really had packet<br> loss.</blockquote><div><br>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.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">So the start isn't too hard to guess. The problem is that the<br> every decoder then needs to have a thread started when a CN packet is<br> received that will generate the frames until it is stopped. And then the<br> decoder may not know it should really stop if the use switched codecs<br> during a silence period.<br></blockquote><div><br>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).<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div class="im"><br> ><br> > > I still think we need some kind of arbitration to not have more than one<br> > > decoder produce silence since Farsight2 will keep the previous decoders<br> > > if the sender starts sending on a new PT. That's why I wanted to do it<br> > > as late as possible (in the mixer).<br> ><br> > Comfort Noise is generated mainly so that the receiver doesn't think<br> > the line is dead. Granted, if this is a multi-party call the need for<br> > CNG is less important. Chances are someone will be talking.<br> > Nevertheless, the decision to go to SID frames is made by each<br> > transmitter, the receiver can't do much in terms of arbitration:<br> > either you support CNG or you don't....<br> <br> </div>I guess maybe the decoder could just set GST_BUFFER_FLAG_GAP<br> on the CNG buffers. Then the mixer can be made to ignore buffers that<br> have this flag set.<br></blockquote><div><br>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.<br> <br>Regards<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div><div></div><div class="h5"><br> <br> --<br> Olivier Crête<br> <a href="mailto:olivier.crete@collabora.co.uk">olivier.crete@collabora.co.uk</a><br> </div></div><br>------------------------------------------------------------------------------<br> <br>_______________________________________________<br> gstreamer-devel mailing list<br> <a href="mailto:gstreamer-devel@lists.sourceforge.net">gstreamer-devel@lists.sourceforge.net</a><br> <a href="https://lists.sourceforge.net/lists/listinfo/gstreamer-devel" target="_blank">https://lists.sourceforge.net/lists/listinfo/gstreamer-devel</a><br> <br></blockquote></div><br>