GNOME Bugzilla – Bug 743938
pipeline: Handle the case were we are still loading the project and the user tries to set its state to PLAYING/PAUSED.
Last modified: 2018-11-03 12:52:45 UTC
I want to use GESProject and GESPipeline to render .xges file into the .webm one. My code looks like this: ... project = ges_project_new(uri); /// URI of XGES file GESTimeline *timeline = GES_TIMELINE(ges_asset_extract(GES_ASSET(project), &error)); if (error) ... /// I handle error here ... else { pipeline = ges_pipeline_new(); ges_pipeline_set_timeline(pipeline, timeline); gchar *uri = g_strdup_printf("file://" RAMFS_PATH "t%" G_GUINT64_FORMAT ".webm", operation_identifier); /// Yet another URI: .webm file where output should be directed ges_pipeline_set_render_settings(pipeline, uri, GST_ENCODING_PROFILE(encoding_profile)); /// WebM with vp8 and Vorbis g_free(uri); ges_pipeline_set_mode(pipeline, GES_PIPELINE_MODE_RENDER); ... /// Here I attach some stuff to bus to handle errors, eos, etc. ... gst_element_set_state(GST_ELEMENT(pipeline), GST_STATE_PLAYING); ... I face a problem causing pipeline to work infinte time without sending error or EOS messages to bus. It happens first time I run pipeline. Second (and subsequent) pipelines seem to work without this error (or at least it becames rare). With gst-editing-services from git master error looks like this: ERROR nlecomposition nle/nlecomposition.c:2524:_relink_children_recursively: Not enough sinkpads to link all objects to the operation ! 1 / 0 ERROR nlecomposition nle/nlecomposition.c:2527:_relink_children_recursively: Operation has no child objects to be connected to !!! In GES 1.4.0 error looks a bit different: ERROR gnlcomposition gnlcomposition.c:2385:compare_relink_single_node: Not enough sinkpads to link all objects to the operation ! 2 / 0 ERROR gnlcomposition gnlcomposition.c:2387:compare_relink_single_node: Operation has no child objects to be connected to !!!
In some cases this problem appears on every pipeline creation. I have to restart my program and then it works without issues. Strange.
Okay, have more information regarding this intermittent bug. My app works as network daemon, it gets .xges + assets in input and generates .webm at output. So, yesterday we succeeded to have two operations for single .xges scenario: first one failed, second one worked good.
Created attachment 299447 [details] Two operations with single scenario p2.dot - failed p4.dot - works p2.xges == p4.xges
It seems that problem is lack of several NleSource elements. Symtoms: non-connected pads, no FileSrc elements, no second input to audio mixer.
The problem here seems to be a combination of GES API weirdness and how you use GES: You need to wait for the "loaded" signal before setting the pipeline to playing state. This may require a running main loop too. So it's basically a race between the asset loading and misc pipeline stuff happening. IMHO GES should at least catch this somehow and warn, but I suspect it's just not how the API is supposed to be used. I'm sure ges devs will correct me if I'm wrong.
We could warn the user when the project is still loading and pipeline state is set to > READY, or even wait for the "loaded" signal in timeline.change_state vmethod between READY and PAUSED so that it just works for the user (which might imply starting the/a mainloop ourself, maybe not ideal). I will just rename that bug and reopen.
ges_asset_extract returns a timeline and looks like synchronous method.
Unfortunately right now I'm facing that with ges-launch-1.0 again. Symptoms exactly same. I just play a video. For a small video all works good. For a huge .AVI file I have $ ges-launch-1.0 -l p25.xges -o file:///home/mdzuser1/1.mp4 Loading project from : p25.xges 0:00:00.150498948 16863 0x7f3f3c004d90 ERROR nlecomposition nle/nlecomposition.c:2529:_relink_children_recursively: Not enough sinkpads to link all objects to the operation ! 1 / 0 0:00:00.150560253 16863 0x7f3f3c004d90 ERROR nlecomposition nle/nlecomposition.c:2532:_relink_children_recursively: Operation has no child objects to be connected to !!! <position: 0:00:00.000000000 duration: 0:00:05.000000001/> with 20%-30% probability. ges-launch-1.0 hangs in eternal loop.
Heu, ges-launch does the right thing and should not be racy. Can you give use more details about what is failling?
No races today, I just made dozen of subsequent ges-launch calls.
Any information you want, Thibault. Few moments.
(In reply to Kyrylo V. Polezhaiev from comment #11) > Any information you want, Thibault. > Few moments. You should always provide us with a way to reproduce :)
Created attachment 304863 [details] minimal xges file Create required asset (66 MB): gst-launch-1.0 videotestsrc num-buffers=1325 ! video/x-raw,format=I420,width=640,height=480,framerate=25/1 ! avimux ! filesink location=/tmp/video.avi I can reproduce three issues with this and the attached xges project then in git master (these are racy, so don't necessarily happen all the time, although with the above I can reproduce with 90% reliability on my box) using ges-launch-1.0 -l min.xges -o /tmp/theora.ogg a) not-negotiated flow error (seems to be caused by a caps event being pushed on a pad that's flushing because of a seek). b) when (a) happens, GES crashes in ges-timeline.c 1048 (stop_tracking_track_element) at g_sequence_remove (iters->iter_by_layer). Sometimes it complains that it's not an end iter, sometimes it just crashes. Probably invalid memory access due to missing/broken cleanup somewhere. c) when running this in valgrind it hangs after: 0:00:03.960214385 13865 0xce22ff0 ERROR nlecomposition nle/nlecomposition.c:2537:_relink_children_recursively: Not enough sinkpads to link all objects to the operation ! 1 / 0 0:00:03.962141168 13865 0xce22ff0 ERROR nlecomposition nle/nlecomposition.c:2540:_relink_children_recursively: Operation has no child objects to be connected to !!! Just putting all the info here for now in case you want to have a look or clone separate bugs.
> gst-launch-1.0 videotestsrc num-buffers=1325 ! ... num-buffers=150 is enough, 1325 creates a ~600MB file.
Created attachment 304866 [details] Project fixing the clip overlay layer priority
Thanks @tim for that. One question, how did you produce that project file? We should not have a TextOverlay on the same layer as the source itself (overlays should always be on top of the actual source). We should probably error out detecting errors like that -> https://bugzilla.gnome.org/show_bug.cgi?id=750644 Fixing the project as attached leads to only getting the NNE issue.
Thanks Thibault! With your fixed file, I always get not-negotiated with ges-launch (no more crashes). I still get issue (c) when running it in valgrind though - can you reproduce that too?
I can reproduce, I was expecting it to be fixed by the project file fix... Also if you only want to apply an overlay on a particular source, I recommand you use a GESTextOverlay and add it directly to the GESClip (it will handle priorities for you, but won't allow you to apply a same overlay on several source / or between sources).
For the recore, the: 0:00:03.960214385 13865 0xce22ff0 ERROR nlecomposition nle/nlecomposition.c:2537:_relink_children_recursively: Not enough sinkpads to link all objects to the operation ! 1 / 0 0:00:03.962141168 13865 0xce22ff0 ERROR nlecomposition nle/nlecomposition.c:2540:_relink_children_recursively: Operation has no child objects to be connected to !!! issue was due to GstDiscoverer timeouting when running under valgrind, and us in GES not properly reporting that. I pushed those two patches to properly report that issue, and add a way to change the discoverer timeout using a env variable: commit ba25eb62a6010b9735ce0f14bb8d5c77087035fc Author: Thibault Saunier <tsaunier@gnome.org> Date: Tue Jun 9 21:00:44 2015 +0200 ges: Raise an error when the discoverer returns != RESULT_OK And do not try to run the pipeline when that happens commit 3f27fdecaadaa9cb0dc84641322bfeccb741132b Author: Thibault Saunier <tsaunier@gnome.org> Date: Tue Jun 9 20:58:00 2015 +0200 uri-asset: Add a way to control discoverer timeout through envvar Making it possible to run ges-launch test under valgrind for example
Where did you push them? :)
(In reply to Tim-Philipp Müller from comment #20) > Where did you push them? :) I( forgot to rebase so it did not work. It is now pushed in master :)
So, is it now reproducible in 100% of launches?
Can I use GES_DISCOVERY_TIMEOUT as temporary workaround?
The Not Negotiated error is now 100% reproduceable. You should use GES_DISCOVERY_TIMEOUT when running inside valgrind (outside valgrind it should never timeout).
So, is just waiting for a "loaded" signal from project being extracted is enough to forget about this?
It is the correct way to handle it yes. I agree the API should be more explicit about that, it will all be reworked for 2.0 but we should try to figure out a way to make it more obvious in the current context. Btw, are you on IRC? it would be simpler to talk live :)
(In reply to Thibault Saunier from comment #24) > You should use GES_DISCOVERY_TIMEOUT when running inside valgrind (outside > valgrind it should never timeout). Why? It can easily timeout outside valgrind.
It can falsely timeout after 1 minute? I tend to doubt it.
No, it timeouts after one GST_SECOND you set in case of errno != 0 :) http://cgit.freedesktop.org/gstreamer/gst-editing-services/tree/ges/ges-uri-asset.c#n217
which is the case if GES_DISCOVERY_TIMEOUT is not set: http://cgit.freedesktop.org/gstreamer/gst-editing-services/tree/ges/ges-uri-asset.c#n213
which is the default case :-)
Keeping opened to remind that for GES 2.0 we should make sure that API allows the user to set the pipeline state at any point in time without being racy.
Automated removal of (bad) usage of the "NONE" target milestone.
-- 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/20.