Synchronization precision

Nicolas Dufresne nicolas at
Mon Jul 1 20:37:08 UTC 2019

Le lun. 1 juill. 2019 15 h 40, RiccardoCagnasso <riccardo at> a
écrit :

> At gstreamer conference 2017, doctor Raghavan gave a presentation about his
> library that allowed to create simple synchronized. During his conference
> he
> did highlight something that I had encountered before: the synchronized
> playback is not really perfectly accurate.
> There's usually, an random error that is maximum less than a frame. This
> means that "sometimes", usually once in several seconds, a frame is
> rendered
> slight after or before its counterpart. This seems to happen with the same
> extent whether the two videos are played on the same computer or on two
> distinct connected via ethernet (which makes sense, since the delay of
> ethernet is sub-1ms).
> In practical scenarios, the error is unnoticeable if any kind of bezel is
> involved, e.g. any kind of video wall, but it becomes apparent on a
> continuous screen, e.g. a ledwall. It's also quite easy to spot using the
> "slow motion" feature (120 fps) of any smartphone.
> here is an example taken from a very big
> videowall.
> Is there any kind of active development trying to isolate/fix/mitigate this
> issue? With the availability of sub 1mm pitch ledwall, there's definitely a
> market for synchronized playback. It's not immediately obvious how to play
> a
> 16k video on a number of smaller, contiguous screens.

I believe some vendors have a solution, but they kept it for themselves. I
have tackled the idea, but the first thing I notice (with seperate screens)
is that I would also need to sync the display clock, and that requires more

Meanwhile I've experimented with Wayland presentation timestamp, since none
of our display sync have controllable and reliable frame scheduling. I was
told the GStreamer network clock can achieve less the 2ms sync, so far I
felt it was sufficient.

Let me know if you'd like to resurrect that wayland branch. I don't know if
it makes sense with freesync or other HW protocol, it barely existed when I
was looking at this.

> We don't have the resources nor the expertise to work on this, but we might
> be able to provide some (very, very limited. small company with a different
> core business) financial incentive to someone tackling this.
> --
> Sent from:
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the gstreamer-devel mailing list