Dynamic pipelines: how to remove sinks?

Tim-Philipp Müller t.i.m at zen.co.uk
Sun Dec 30 14:53:16 PST 2012


On Sun, 2012-12-30 at 01:32 -0600, Tal Liron wrote:

Hi,

> I have implemented a dynamic pipeline with GStreamer 1.0, and it seems 
> quite stable! (Had lot of problems with this in 0.10). However, I have 
> two questions, regarding the documentation available here:
> 
> http://gstreamer.freedesktop.org/data/doc/gstreamer/head/manual/html/section-dynamic-pipelines.html
> 
> 1) How do I safely remove sink elements? I understand the neat trick of 
> sending an EOS at the sink pad and waiting for it to arrive at the src 
> pad on the other end, effectively "draining" all data from the element. 
> A sink, however, by definition does not have a src pad on the other end. 
> So far, I've just ignored that part of the guide when dealing with 
> sinks: I send an EOS at the sink pad, and immediately remove the element 
> without waiting for it to "drain." It works and is stable... but I can't 
> help thinking that this is a fluke. Is there another way to wait for a 
> sink element to "drain"?

What's the context here? What kind of sink is it?

Perhaps it's enough to just unlink it, then set it to NULL state and
remove it from the pipeline?

Draining is only required if you need to make sure that e.g. muxers
finalize headers and everything gets written to disk properly etc.


> 2) This is a smaller detail, but in the example code in the page above, 
> there's this:
> 
> gst_pad_add_probe (blockpad, GST_PAD_PROBE_TYPE_BLOCK_DOWNSTREAM, 
> pad_probe_cb, user_data, NULL);
> 
> Now, I am using the Vala "bindings" (actually through Genie), where the 
> PadProbeType.BLOCK_DOWNSTREAM constant does not exist. Am I right in 
> assuming that PadProbeType.BLOCK has the same function? I'm wondering if 
> the code in example is from a pre-1.0 GStreamer and this enum const was 
> deprecated.

This should be fixed in version 1.0.4. Some of the pad probe constants
were defines instead of being part of the GstPadProbeType enum, which
means they don't get picked up by g-i/bindings. You should still be able
to construct the value yourself using

GST_PAD_PROBE_TYPE_DATA_DOWNSTREAM =
  GST_PAD_PROBE_TYPE_BUFFER | GST_PAD_PROBE_TYPE_BUFFER_LIST
    | GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM;

and

GST_PAD_PROBE_TYPE_BLOCK_DOWNSTREAM =
  GST_PAD_PROBE_TYPE_BLOCK |GST_PAD_PROBE_TYPE_DATA_DOWNSTREAM;

Cheers
 -Tim



More information about the gstreamer-devel mailing list