How to unlink elements from inside probes?

Application Development
1

There is an error message if you use a probe to catch an eos event in order to stop and unlink an element. That you cannot join a task from inside itself. The suggested practice is to send eos to the element, wait for eos to exit with a probe, then stop and unlink.

2

You can’t set an element’s state from inside its streaming thread. One way around that would be to use gst_element_call_async() from inside the probe to do the work from a different thread after the probe has returned.

Please provide more details about the pipeline in question and what the probe is supposed to do.

3

Thank you for the response. I am following the example of
https://gstreamer.freedesktop.org/documentation/application-development/advanced/pipeline-manipulation.html?gi-language=c#changing-elements-in-a-pipeline

Where unless i am mistaken, it is shown that the way to dynamically change elements is to add a probe and stop the element when you get an eos from its src pad.

What my pipeline is supposed to do is have a pad of constantly changing caps (custom element), and with an event (non blocking) probe link that pad to another chain of element depending on the caps. First i have to unlink the previous chain.

So my process is

  1. probe got caps
  2. caps are let’s say VP8, previous were VP9
    //unlinking here
  3. add an eos probe to vp9dec
  4. push eos event to vp9dec
  5. wait for a g_cond that means the previous chain was unlinked
  6. when probe in 3. gets the eos, set vp9dec state to null, unlink my pad from vp9dec, and signal cond
    //linking here
  7. code passes the condition, now link vp8dec to the pad and sync its state
  8. pad probe exits
  9. next buffer will go to vp8dec
4

I am trying to understand how the example works by stopping elements inside their pad probe and i cannot because of the 'cannot join task … ’ message. I am definitely missing something.

5

I don’t have time to look into this in detail now, but for that message you’re probably changing element states from inside the streaming thread (i.e. inside the pad probe). Use something like gst_element_call_async() to do the state changes from a different thread. Doing so might require blocking the pad from inside the probe.

6

Looked into the example and it seems it’s because all effect elements are in push mode. Most of mine are too, with the exception of a queue. Because the queue has a task in the src pad, when the pad is deactivated, the task is joined and there is the error. Adding the queue as effect in the example can confirm this.

So i will use your advice and find a way to set the state in another thread while keeping the pad blocked until the queue emits EOS. Thanks.