----- Messaggio originale -----
> On Thu, 2010-04-29 at 20:04 +0300, Marco Ballesio wrote:
> > 2010/4/27 Olivier Crête <firstname.lastname@example.org>
> > 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).
> What about codecs like Speex that provide their own CN (possibly
> differently from G711+CN or G729 ...) ?
In this case it's up to the GStreamer wrapper to control the bin but, as you're pointing out in the next paragraph, the two architectures we're thinking about are quite similar, amd yours is more standardized from the messaging pov.
> My idea to do it in the mixer is mostly the same as your bin idea (just
> using an elemnet with events instead of a bin with messages).
Yep, I like your "eventing" more than my messaging :) .
> Olivier Crête