Handling errors in callbacks at the application level

[Tyler Compton]

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 list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Mathieu Duponchelle]

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 list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[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 <[hidden email]> 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 list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel