Handling GStreamer used by another application

jmz jmzheng at gmail.com
Fri Jul 7 06:31:49 UTC 2017


Hi Nicolas,

Thank you for your comments. With (a) or (b) used in on_error callback, I
have a blocking issue on using gst_element_get_state ().

On Thu, Jul 6, 2017 at 11:16 PM, Nicolas Dufresne <nicolas at ndufresne.ca>
wrote:
>> (a) do nothing
>> (b) change the pipeline state to NULL (or others?)
>> (c) invoke g_main_loop_quit()
>
> All choices are valid. It depends on how you want you application to
> recover from an error ? With (c), recovery will likely be slow, as you
> will have to re-create a thread, context, mainloop etc.

For example, after on_error callback with (a) is invoked,
GST_STATE_CHANGE_ASYNC is returned on a  gst_element_set_state(pipeline,
GST_STATE_PAUSED) called later by user app. As I saw in a state_chage
callback, all elements within the pipeline changed their states to PAUSED,
but the pipeline element did not. Therefore, a next
gst_element_get_state(pipeline, &state, &pending, GST_CLOCK_TIME_NONE) will
block! Is this due to that the pipeline element has not completed state
change yet?

What should I do if I want to use gst_element_get_state() with infinite
timeout? Shall I change GST_CLOCK_TIME_NONE to a specified timeout value? 

Thanks for any suggestions.





--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/Handling-GStreamer-used-by-another-application-tp4683710p4683724.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.


More information about the gstreamer-devel mailing list