Synchronization precision
Nicolas Dufresne
nicolas at ndufresne.ca
Tue Jul 2 12:22:23 UTC 2019
Le mar. 2 juill. 2019 06 h 10, RiccardoCagnasso <riccardo at phascode.org> a
écrit :
> Nicolas Dufresne-5 wrote
> >
> > This last sentence surprise me. I did quite some test, and on the same
> > monitor, I have never seen a de-sync. But the was not with Arun library
> > though. Maybe you need a bit of a debugging sessions.
>
> I don't use Arun library, but my own code is very similar. There might be a
> bug, yes, but I don't think this is the case. For two reasons.
>
> First the code is very simple.
> Second, I routinely use a single video played on a borderless window that
> spans across multiple outputs on big led walls and there's no perceivable
> de-sync.
> This means that the de-sync that you see across different monitors, is not
> caused by the "multiple monitors".
>
> I have somewhere a video of two synchronized playbins, one next to the
> other, on my laptop screen. The video is recorded in 120 fps slow motion
> and
> the de-sync every couple of second is quite clear.
>
At 120fps, I wonder if the normal Linux scheduler can work. Just to remind,
what we do in sink is simply wait on the pipeline clock and render.
Whenever you are on the edge of the vblank, even if you have perfect clock,
a slight scheduling jitter will lead to the image being rendered on
unpredictable vblank.
What my waylandsink experiment was about, was to use the presentation
timestamp to predict the effective vblank time (on the pipeline clock) and
initiate the render right after that vblank. This way the renderer could
tolerate as much jitter as the vblank interval, hence would lead to a much
more predictable render. To me what you observe at high framerate seems to
match, but it's always hard to be certain.
P.s. Right now this would work with freesync or other tech as long as your
compositor rendering is paced. If the compositor was pacing the render
based on app activity, the stats would end up unstable.
>
>
> --
> Sent from: http://gstreamer-devel.966125.n4.nabble.com/
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20190702/0f8a5557/attachment.html>
More information about the gstreamer-devel
mailing list