GNOME Bugzilla – Bug 796770
compositor: transition output frame looks ugly
Last modified: 2018-11-03 14:27:39 UTC
Dynamic layout change (e.g., g_object_set(GstCompositorPad, ...)) produces ugly frame(s) since GstCompositorPad's member variables might be modified while aggregate_frame() is running.
Created attachment 372983 [details] [review] videoaggregator: Add "foreach-sink-pad" signal action Used for protected access to sinkpads while GstVideoAggregator::aggregate_frames() virtual method is not running.
I wonder if this wouldn't be better handled more generically e.g. by adding something like gst_object_queue_set_property() that would be done atomically when the next sync is called (possibly something that works with multiple objects too), or something in aggregator at least? I might be misunderstanding the exact problem though.
(In reply to Tim-Philipp Müller from comment #2) > I wonder if this wouldn't be better handled more generically e.g. by adding > something like gst_object_queue_set_property() that would be done atomically > when the next sync is called (possibly something that works with multiple > objects too), or something in aggregator at least? > > I might be misunderstanding the exact problem though. I was trying to formulate something around those lines, I agree with you though I am not sure how the API should look like as in this case it would require properties from several object (sinkpads) to be "comited" at once.
Maybe we can use some special GstController for this? It seems that pretty much what this API was designed for. So you could do a gst_manual_controller_set_property_at (obj, time, "prop", value);
Yeah, but I was more thinking of a special one-shot-at-next-opportunity thing, that's something that's generally needed I think. Multiple objects could be accommodated via a helper object that's passed, or API like queue_set_multiple_objects (obj1, prop, value, obj2, prop, value); In any case, I feel like we should come up with something related to controller if these are controllable properties.
(In reply to Tim-Philipp Müller from comment #2) > I wonder if this wouldn't be better handled more generically e.g. by adding > something like gst_object_queue_set_property() that would be done atomically > when the next sync is called (possibly something that works with multiple > objects too), or something in aggregator at least? > > I might be misunderstanding the exact problem though. As you mentioned, we need some nice API(s) to solve this problem. I think this is generic problem of Gstreamer. Since "setting multiple properties (and maybe multiple objects' properties also) at once" is not supported yet, some elements such as videocrop, videomixer, compositor, etc seems to generating weird frame sometimes.
For simple element, like videocrop, we workaround by using a pad probe on the sink pad. I bet setting the property within a probe callback on the src pad of an aggregator would work (except you are already 1 frame late). It boils down to setting the properties while the thread using these properties is blocked. It's ugly though, I agree we need something nicer.
-- 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-plugins-bad/issues/748.