GNOME Bugzilla – Bug 735404
Feature Submission: Added XSync support to xvimagesink
Last modified: 2018-11-03 11:31:05 UTC
Created attachment 284445 [details] [review] Patch to implement xsync support in xvimagesink There is an X Server extension called XSync which allows for synchronizing X operations against an external clock. Under Linux the default 'SERVERTIME' clock is a monotonic clock shared by all servers on a linux box, allowing for synchronization between independent X Servers running on a single machine. To make use of this feature, I've added 'xsync' and 'xsync-clock' properties to xvimagesink. If xsync is true, then whenever xvimagesink would normally synchronize frames, it will attempt to do so using the XSync clock named in 'xsync-clock' I've added this features in order to help support videowall software that needs multiple X Servers to show frames at the same moment. This is my first attempt at modifying the internals of a complex sink like xvimagesink, and I may have made some mistakes, but the code currently appears to operate as expected.
It would probably be cleaner to implement a GstClock around the XSync X extension and set such a clock on the pipeline to do the synchronization.
I had considered that, but the XSync clock has only millisecond resolution, while GStreamer clocks generally have nanosecond resolution. I wasn't sure that wouldn't be an issue. Besides, every time I tried setting a clock on the pipeline, it was ignored, so I went this route.
milliseconds are ok, not great but acceptable :) You have to use gst_pipeline_use_clock() not gst_element_set_clock(), in case that was the mistake.
Here's how I was attempting to set the clock in one of my experiments: Despite this, an audio clock was chosen as the clock. static GstElement * vaal_pipeline_new() { GstElement * pipeline = gst_element_factory_create (pipefactory,"pipeline"); gst_pipeline_use_clock(GST_PIPELINE(pipeline), gst_system_clock_obtain()); return pipeline; }
So, if I went back and created a new XSync clock, would folks prefer it be a patch on the current gstclock file, or a new file, and if new, where should it be in the code tree?
It should be in a separate file, just not sure where it should be located as it needs to link to libX11. A separate library seems overkill but I don't see another solution right now
Make it a property in xvimagesink/ximagesink to use that clock? Then it can be got from the pipeline/element?
Not use, propose I suppose. Or we add a clock plugin feature subclass ;)
I've always wondered about a mode where we take rate from the audio clock, but take phase from the video clock into a synthesised master clock. I think that's like Xine's metronome.
-- 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-base/issues/130.