<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le lun. 1 juill. 2019 15 h 40, RiccardoCagnasso <<a href="mailto:riccardo@phascode.org">riccardo@phascode.org</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">At gstreamer conference 2017, doctor Raghavan gave a presentation about his<br>
library that allowed to create simple synchronized. During his conference he<br>
did highlight something that I had encountered before: the synchronized<br>
playback is not really perfectly accurate.<br>
<br>
There's usually, an random error that is maximum less than a frame. This<br>
means that "sometimes", usually once in several seconds, a frame is rendered<br>
slight after or before its counterpart. This seems to happen with the same<br>
extent whether the two videos are played on the same computer or on two<br>
distinct connected via ethernet (which makes sense, since the delay of<br>
ethernet is sub-1ms).<br>
<br>
In practical scenarios, the error is unnoticeable if any kind of bezel is<br>
involved, e.g. any kind of video wall, but it becomes apparent on a<br>
continuous screen, e.g. a ledwall. It's also quite easy to spot using the<br>
"slow motion" feature (120 fps) of any smartphone.<br>
<br>
<a href="https://youtu.be/-1EhKn8E5zY" rel="noreferrer noreferrer" target="_blank">https://youtu.be/-1EhKn8E5zY</a> here is an example taken from a very big<br>
videowall.<br>
<br>
Is there any kind of active development trying to isolate/fix/mitigate this<br>
issue? With the availability of sub 1mm pitch ledwall, there's definitely a<br>
market for synchronized playback. It's not immediately obvious how to play a<br>
16k video on a number of smaller, contiguous screens.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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 hardware.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
We don't have the resources nor the expertise to work on this, but we might<br>
be able to provide some (very, very limited. small company with a different<br>
core business) financial incentive to someone tackling this.<br>
<br>
<br>
<br>
--<br>
Sent from: <a href="http://gstreamer-devel.966125.n4.nabble.com/" rel="noreferrer noreferrer" target="_blank">http://gstreamer-devel.966125.n4.nabble.com/</a><br>
_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank" rel="noreferrer">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a></blockquote></div></div></div>