Handling errors in callbacks at the application level

[Tyler Compton]

Thank you Mathieu, I was not aware of gst_message_new_application. The docs
are amusing as well :)

On Mon, Apr 13, 2020 at 4:35 PM Mathieu Duponchelle <mathieu at centricular.com>
wrote:

> It's completely OK for applications to post on the bus, and it's actually
> a good way
> to marshall your errors to the "main thread" if that's how you intend to
> deal with them.
>
> I'm not entirely sure if it's considered good practice for applications to
> use the
> GST_ELEMENT_ERROR convenience macro, it will work but perhaps the cleanest
> way is for to post an application message:
>
>
> https://gstreamer.freedesktop.org/documentation/gstreamer/gstmessage.html?gi-language=c#gst_message_new_application
>
> Another solution to the potential for deadlocks you mentioned, which
> does exist, is to use gst_element_call_async.
>
> For your purpose of tearing down the entire pipeline, I think going through
> the bus is more adapted, but it is useful in some situations, such as
> dynamically
> modifying the pipeline from pad probe callbacks.
>
> On 4/14/20 1:16 AM, Tyler Compton wrote:
>
> 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.
>
> 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?
>
> 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.
>
> Thanks for the help!
>
> _______________________________________________
> gstreamer-devel mailing listgstreamer-devel at lists.freedesktop.orghttps://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20200413/876f5e93/attachment-0001.htm>