Synchronization precision

[RiccardoCagnasso]

Nicolas Dufresne-5 wrote
> Le mar. 2 juill. 2019 06 h 10, RiccardoCagnasso <

> riccardo@

> > 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 .freedesktop

>> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> 
> _______________________________________________
> gstreamer-devel mailing list

> gstreamer-devel at .freedesktop

> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

What I meant is that I recorded my laptop screen with a 120 fps camera (my
smartphone). Crude but effective, the desync shows up nicely. 

What you are saying about vsync makes perfectly sense to me. If a screen is
60hz you have a vblank every 16 ms. If two processes write images on the
screen, without any synchronization with the vsync and with a error of about
2 ms between their own clocks, there will be a certain probability that two
matching frame will be rendered after different vblanks. Which is perfectly
consistent with what we see on camera. 

I don't know much about wayland and freesync, but sure. If you can guarantee
that the frame is rendered right after the vblank, this should work just
fine. How can I help? 





--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/