GNOME Bugzilla – Bug 753883
GESPipeline fails to change state in case of errors in timeline
Last modified: 2018-11-03 12:53:01 UTC
Created attachment 309729 [details] empty project If GESProject contains some specific errors or is empty (like in attachment), and on project "loaded" I say GESPipeline (which should play Timeline I extracted) to change state to PLAY, it only changes state to READY and then no action is performed asynchronously (thread pool relaxing). gst_element_get_state, however waits infinitely (in case timeout is -1).
I have neither GST_MESSAGE_STATE_CHANGED nor GST_MESSAGE_ASYNC_DONE, not even a GST_MESSAGE_ERROR.
I mean after GESPipeline is _READY.
Reproducible via: ges-launch-1.0 -l empty.xges
Also appears when trying to specify start time of still image. Pipelines fails to asynchronously change it's state to _PAUSED without sending any errors / warnings to bus.
Or after putting text overlay over nothing. All this cases should cause GES to post error message to bus instead of just leaving pipeline in _READY state without any further actions.
Created attachment 310656 [details] [review] timeline: Fail trying to set empty GESTimeline state to PAUSED When a GESTimeline is empty (meaning no active GESSource is in the timeline so no stream can be outputed.
I am not sure at all I want that patch in, being able to just get the timeline in READY state while not having anything inside and just let it go to PAUSED when something is added is more a feature than a bug fmpov (it is quite usefull, and if the user want to check if the timeline is empty before using it, there is a method for that) Concerning > Or after putting text overlay over nothing I tend to think you are right.
Review of attachment 310656 [details] [review]: Why do we want to _quit from g_application?
Will this _FAILURE cause GStreamer to report error to GstBus or return error synchronously from gst_element_set_state?
(In reply to Kyrylo V. Polezhaiev from comment #8) > Review of attachment 310656 [details] [review] [review]: > > Why do we want to _quit from g_application? Because g_error was doing that but then we were no properly getting status report from GstValidate (In reply to Kyrylo V. Polezhaiev from comment #9) > Will this _FAILURE cause GStreamer to report error to GstBus or return error > synchronously from gst_element_set_state? Both
(In reply to Thibault Saunier from comment #10) > Because g_error was doing that but then we were no properly getting status > report from GstValidate Sorry, I thought that _quit was somewhere in GESTimeline :-) I just don't want some of my GESTimelines to have an ability to quit my entire Application. It has a lot of GESTimelines inside. It's GApplication's heir / controller duty to decide how to react and what to do if GESPipeline doesn't want to work. (In reply to Thibault Saunier from comment #10) > Both Thanks, nice, will test tomorrow :-)
(In reply to Kyrylo V. Polezhaiev from comment #11) > (In reply to Thibault Saunier from comment #10) > > Because g_error was doing that but then we were no properly getting status > > report from GstValidate > > Sorry, I thought that _quit was somewhere in GESTimeline :-) > > I just don't want some of my GESTimelines to have an ability to quit my > entire Application. It has a lot of GESTimelines inside. It's GApplication's > heir / controller duty to decide how to react and what to do if GESPipeline > doesn't want to work. Obviously, that change was only about ges-launch
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-editing-services/issues/23.