Handling GStreamer used by another application

[Nicolas Dufresne]

Le jeudi 06 juillet 2017 à 23:31 -0700, jmz a écrit :
> > 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?

After an error, only NULL state is guarantied to work. If you know the
error (by handling the enum), you can probably recover by replacing the
element that produced an error. Be aware that on errors element will
send an EOS downstream, so you mean need to flush.

> 
> 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? 

I bet you wanted to ask if you don't want infinit timeout. Yes, just
set a valid duration (in nanosecond). With 0, it won't wait at all.

Nicolas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20170707/01dc7acd/attachment.sig>