<div dir="ltr">Thank you Mathieu, I was not aware of gst_message_new_application. The docs are amusing as well :)</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 13, 2020 at 4:35 PM Mathieu Duponchelle <<a href="mailto:mathieu@centricular.com">mathieu@centricular.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div>
    It's completely OK for applications to post on the bus, and it's
    actually a good way<br>
    to marshall your errors to the "main thread" if that's how you
    intend to deal with them.<br>
    <br>
    I'm not entirely sure if it's considered good practice for
    applications to use the<br>
    GST_ELEMENT_ERROR convenience macro, it will work but perhaps the
    cleanest<br>
    way is for to post an application message:<br>
    <br>
<a href="https://gstreamer.freedesktop.org/documentation/gstreamer/gstmessage.html?gi-language=c#gst_message_new_application" target="_blank">https://gstreamer.freedesktop.org/documentation/gstreamer/gstmessage.html?gi-language=c#gst_message_new_application</a><br>
    <br>
    Another solution to the potential for deadlocks you mentioned, which<br>
    does exist, is to use gst_element_call_async.<br>
    <br>
    For your purpose of tearing down the entire pipeline, I think going
    through<br>
    the bus is more adapted, but it is useful in some situations, such
    as dynamically<br>
    modifying the pipeline from pad probe callbacks.<br>
    <br>
    <div>On 4/14/20 1:16 AM, Tyler Compton
      wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">I'm hoping to get some insight about what
        applications are expected to do when they encounter an error
        while running within a signal callback.
        <div><br>
        </div>
        <div>For example, let's say I've created a demuxer and attached
          a callback to the "pad-added" signal. Now, when that callback
          is run I find that the pad is for a video format that my
          application doesn't support. I want the pipeline to be brought
          down as a result of this. What is the best way to signal to
          GStreamer my intentions?</div>
        <div><br>
        </div>
        <div>My first guess was to send an error message on the pipeline
          with "pipeline.message_full". Then I could have my watcher set
          the pipeline's state to NULL when it receives an error.
          However, documentation about error messages makes it sound
          like only elements are expected to create them, making me
          wonder if that's the right choice. Another option would be to
          call "pipeline.set_state(Gst.State.NULL)" directly, but my
          understanding is that using set_state in callbacks can result
          in deadlocks if the callback happens to be run in a streaming
          thread.</div>
        <div><br>
        </div>
        <div>Thanks for the help!</div>
      </div>
      <br>
      <fieldset></fieldset>
      <pre>_______________________________________________
gstreamer-devel mailing list
<a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</a>
<a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a>
</pre>
    </blockquote>
  </div>

</blockquote></div>