[gst-devel] Re: [gst-cvs] dolphy gstreamer: gstreamer/ gstreamer/gst/

Wim Taymans wim at fluendo.com
Tue Feb 28 03:46:03 CET 2006


On Tue, 2006-02-28 at 12:30 +0100, Andy Wingo wrote:
> Hi Julien,
> 
> On Mon, 2006-02-20 at 15:07 +0000, Julien Moutte wrote:
> > CVS Root:       /cvs/gstreamer
> > Module:         gstreamer
> > Changes by:     dolphy
> > Date:           Mon Feb 20 2006  15:07:45 UTC
> > 
> > Log message:
> >         * gst/gstpad.c: (gst_pad_set_blocked_async):
> >         * gst/gstutils.c: (gst_pad_add_data_probe),
> >         (gst_pad_add_event_probe), (gst_pad_add_buffer_probe),
> >         (gst_pad_remove_data_probe), (gst_pad_remove_event_probe),
> >         (gst_pad_remove_buffer_probe): Make those function act on the
> >         ghostpad target when it's a ghostpad. (Closes #331727)
> 
> This is probably incorrect. One of the goals when making the new ghost
> pad implementation was that it should strictly be a layer on top of the
> existing pads. With this patch the layers are now tangled again.
> 
> Probably the better way to do this would be via vmethods that the ghost
> pad implementation can override.
> 
Unfortunatly not easy. The problem is mostly for src pads that are not
linked yet. In those cases we don't link an internal element to the real
pad yet and so we have no way of knowing when the signal (probe/block)
is be fired. Maybe an overridable method that signals
installation/removal of a probe or block could be a solution.

I reopened the bug so we don't forget about this.

Wim
> Regards,
-- 
Wim Taymans <wim at fluendo.com>





More information about the gstreamer-devel mailing list