Handling GStreamer used by another application

[jmz]

Hi

I am developing a streamer application (as a library) based on GStreamer to provide some multimedia services such as playback and recording. A user application (app) can use the library to start, pause, and stop the services.

To start services, user app asks the library to create a streamer object. The object's construction process creates a context and main loop. Then a thread is created and it runs the main loop. Finally, a pointer to the object is returned to the app.

To stop services, user app calls g_object_unref() to destroy the streamer object. The object's destruction process calls g_main_loop_quit(), the thread frees the pipeline, and then the main loop (as well as the thread) is stopped. The context is also freed.

When an error occurs in the pipeline (for example, output window was closed), on_error callback in the streamer application is invoked to handle it without notifying the user app of the error (this may not be recommended). Shall I do any of the following in the on_error callback?

(a) do nothing
(b) change the pipeline state to NULL (or others?)
(c) invoke g_main_loop_quit()

If (a) or (b), a gst_element_get_state() called after gst_element_set_state(pipeline, GST_STATE_PAUSED) will block. Why?
If (c), further changes made on the pipeline (requested by user app) may fail because the streamer object has been destroyed.

Is it proper to use (c)?

Thanks for any suggestions or help.

[Nicolas Dufresne-5]

Le jeudi 06 juillet 2017 à 05:18 -0700, jmz a écrit :

> Hi
>
> I am developing a streamer application (as a library) based on GStreamer to
> provide some multimedia services such as playback and recording. A user
> application (app) can use the library to start, pause, and stop the
> services.
>
> To start services, user app asks the library to create a streamer object.
> The object's construction process creates a context and main loop. Then a
> thread is created and it runs the main loop. Finally, a pointer to the
> object is returned to the app.
>
> To stop services, user app calls g_object_unref() to destroy the streamer
> object. The object's destruction process calls g_main_loop_quit(), the
> thread frees the pipeline, and then the main loop (as well as the thread) is
> stopped. The context is also freed.
>
> When an error occurs in the pipeline (for example, output window was
> closed), on_error callback in the streamer application is invoked to handle
> it without notifying the user app of the error (this may not be
> recommended). Shall I do any of the following in the on_error callback?
>
> (a) do nothing
> (b) change the pipeline state to NULL (or others?)
> (c) invoke g_main_loop_quit()
>
> If (a) or (b), a gst_element_get_state() called after
> gst_element_set_state(pipeline, GST_STATE_PAUSED) will block. Why?
> If (c), further changes made on the pipeline (requested by user app) may
> fail because the streamer object has been destroyed.
>
> Is it proper to use (c)?

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.

>
> Thanks for any suggestions or help.
>
>
>
> --
> View this message in context: http://gstreamer-devel.966125.n4.nabble
> .com/Handling-GStreamer-used-by-another-application-tp4683710.html
> Sent from the GStreamer-devel mailing list archive at Nabble.com.
> _______________________________________________
> 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

[jmz]

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 <[e-mail]> 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.

[Nicolas Dufresne-5]

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