NULL State Synchronization

[HtGst]

Hi

On gstreamer 1.4.5, running on Centos 7.2, I have a use case that I am not sure I am handling/understanding correctly:

1-      Application start a pipeline, i.e., sets the state to PLAY

2-      After an arbitrary amount of time, it sets the state to NULL

3-      Current Problem:

a.       A decoder plugin just prior to pushing its frame, after NULL state , attempts to allocate output frame, which it fails and consequently issues a GST_ELEMENT_ERROR

b.      This in turn stops the main application, as we are tripping on error messages

Question is, whether it is the plugin responsibility to block inside _stop, till current frame is processed, or gstreamer is responsible for such synchronizations.

Cheers,

 

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

[Sebastian Dröge-3]

On Thu, 2016-09-01 at 13:51 -0700, ht techdev wrote:
> Hi
> On gstreamer 1.4.5, running on Centos 7.2, I have a use case that I am not sure I am handling/understanding correctly:
> 1-      Application start a pipeline, i.e., sets the state to PLAY
> 2-      After an arbitrary amount of time, it sets the state to NULL
> 3-      Current Problem:
> a.       A decoder plugin just prior to pushing its frame, after NULL state , attempts to allocate output frame, which it fails and consequently issues a GST_ELEMENT_ERROR
> b.      This in turn stops the main application, as we are tripping on error messages
> Question is, whether it is the plugin responsibility to block inside _stop, till current frame is processed, or gstreamer is responsible for such synchronizations.

Which decoder plugin is that? That would be a bug in that decoder or
one of the base classes.

Can you send a debug log with GST_DEBUG=6 of this, but first of all try
with a newer GStreamer version? 1.4 is already quite old and this might
already be fixed.

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[HtGst]

Hi
Apologies, should have clarified it. It is a home brewed decoder, which is based on GstVideoDecoder base class. Question; however, is somewhat more generic. Specifically, is _stop callback in any way synchronized with _handle_frame callback.
Cheers,

-----Original Message-----
From: gstreamer-devel [mailto:[hidden email]] On Behalf Of Sebastian Dröge
Sent: Thursday, September 01, 2016 11:29 PM
To: Discussion of the development of and with GStreamer
Subject: Re: NULL State Synchronization

On Thu, 2016-09-01 at 13:51 -0700, ht techdev wrote:
> Hi
> On gstreamer 1.4.5, running on Centos 7.2, I have a use case that I am not sure I am handling/understanding correctly:
> 1-      Application start a pipeline, i.e., sets the state to PLAY
> 2-      After an arbitrary amount of time, it sets the state to NULL
> 3-      Current Problem:
> a.       A decoder plugin just prior to pushing its frame, after NULL
> state , attempts to allocate output frame, which it fails and
> consequently issues a GST_ELEMENT_ERROR b.      This in turn stops the main application, as we are tripping on error messages Question is, whether it is the plugin responsibility to block inside _stop, till current frame is processed, or gstreamer is responsible for such synchronizations.

Which decoder plugin is that? That would be a bug in that decoder or one of the base classes.

Can you send a debug log with GST_DEBUG=6 of this, but first of all try with a newer GStreamer version? 1.4 is already quite old and this might already be fixed.

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com

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

[Sebastian Dröge-3]

On Thu, 2016-09-01 at 23:46 -0700, ht techdev wrote:
> Hi 
> Apologies, should have clarified it. It is a home brewed decoder,
> which is based on GstVideoDecoder base class. Question; however, is
> somewhat more generic. Specifically, is _stop callback in any way
> synchronized with _handle_frame callback.

Yes, handle_frame() is called from the streaming thread and stop() is
called in the PAUSED->READY state transition after the pads were
deactivated (which blocks on the streaming thread).

However during PAUSED->READY before that, buffer allocation can fail
and you would get a GST_FLOW_FLUSHING, same if you would finish_frame()
at that time. GST_FLOW_FLUSHING is *not* an error that should result in
an error message.

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel