A video wall stays in step when every screen's player shares one clock: PTP under IEEE 1588, all players on the same domain number from 0 to 127. The lead player sends the group state and start time, and a 500 ms startup delay gives followers time to prepare; loops that do not close cleanly are resynchronized on every boundary by the lead player.
A video wall that plays one video across several screens fails in a way anyone can see: the screens drift apart until the picture is a staggered set of clips. The fix is architecture, not better panels. Each screen gets its own player, all players share one clock, and one player acts as lead and tells the others what to play and when. The clock protocol is PTP, defined by the IEEE 1588 standard. Three settings decide whether the wall holds together: one PTP domain number shared by every player, a startup delay on the lead player, and a resynchronization on every loop boundary that does not close cleanly. This page explains each piece, shows the numbers a four-screen build runs on, and lists what to ask a bidder for.
What keeps a video wall's screens in step?
Every screen in the wall plays from its own player, and the wall stays in step because all the players share one PTP clock while a lead player tells each follower which file to play and when.
In step means two things at once. Every player starts the same clip at the same instant, scheduled on the shared clock. While the clip runs, each player's playback position is held against that clock, so small differences between players never grow into visible offsets. The lead player drives this with short network packets, and each follower joins the named state at the named moment from its own storage. Alignment across screens is one problem; frame timing inside one player is another, and how to synchronize video frame data during playback covers that side.
How many players does a video wall need?
Plan one player per screen, with one of them acting as lead: a four-screen wall needs four players, each holding its own copy of the content, and the lead's packets carry the group name, the current state name, and the time that state was entered.
Count screens and buy that many players. There is no shared decoder box: each player decodes and renders its own screen, which keeps the load predictable as the wall grows. The lead is designated in the content build, and its Synchronize call is what sets the state everyone else follows. Files live on each player's local storage, so a four-screen wall means four copies of the media. The players also need one switched network between them; a wall split across isolated subnets has no way to share the clock. Hardware choice per screen is its own decision, and the guide to choosing a digital signage player covers the single-screen side of it.
What is PTP and which domain do the players share?
PTP is IEEE 1588, the Precision Time Protocol: on a switched network with hardware timestamping it aligns clocks to well under 1 ms, and every player in the wall must join the same PTP domain, set to one number from 0 through 127.
IEEE 1588 defines how devices on one network exchange timestamped messages, measure the path delay between them, and correct their offsets. The standard also allows many independent timing domains on the same wire, each with its own number, so two walls in one building can run side by side without joining each other. Pick one number for the wall and set it identically on every player: on the players that ship this scheme it is written to a registry key called ptp_domain in the networking section, and a reboot starts the synchronization service. Keep the players on wired Ethernet; the wired interface, eth0, gives the tightest alignment. PTP over Wi-Fi works where a cable pull is impossible, set in the same section through the ptp_ttl key holding the Wi-Fi interface name, wlan0, but airtime delays are asymmetric and variable, and PTP measures the round trip assuming both directions match, so symmetrical wired links give the smallest errors. Run sync traffic on the wired switch and reserve Wi-Fi for the screens a cable genuinely cannot reach.
How much startup delay keeps the first frame together?
Set the lead player's startup delay to 500 ms: the ms_delay parameter on the lead's Synchronize call gives every follower half a second to load and prepare the new state before the shared clock says play, and that is usually enough.
The sequence: the lead calls Synchronize, the packets go out with the state and its entry time, and each follower uses the 500 ms window to load its file and prepare. The wall then starts the new state together, once the window closes, on the shared clock. Storage speed and heavy encodes are what move the number. The documented ceiling is 1 s, and the rule that comes with it is blunt: if the wall needs more than 1 s of delay, look for errors in the custom code, because 500 ms covers preparation on sane hardware. Decide what the wall shows first as a content question too; choosing the signage playlist first screen at startup covers that half.
Why do loops drift and how do players resynchronize?
A clip that meets the loop requirements acts like one endless file and the wall stays in step; clips that do not must be resynchronized on every loop, which the lead player does by catching the media end event and calling Synchronize to pull followers back to the boundary.
Looping cleanly is a property of the content build: matching encoding on both sides of the join and a cut that closes with no gap. Meet that and no per-loop messages are needed at all. Miss it and every pass around the loop is a new state that needs a fresh Synchronize from the lead, with every follower riding the same boundary. Loop mode must stay off in this design, because the player's own loop setting would fire at the boundary and fight the lead's resynchronization. The same boundary logic appears outside video walls; configuring looping media playback in a SCADA media player control walks one plant screen through it.
What breaks sync after the wall is running?
Seeking or pausing a synced video breaks the wall's alignment, because during playback the sync manager, not a button press, controls the file position against the PTP clock; leave loop mode off when the lead resynchronizes each loop, or you will double-handle the boundary.
Three documented special cases cover the running wall. A seek takes the position out of the sync manager's control, and the screens split. A pause during synced playback does the same. Loop mode left on while the lead drives the boundary means the player's own loop and the lead's resynchronization fight over the same cut. Build the content so nobody seeks or pauses a synced file, and strip loop mode wherever the lead handles the resync. The trap repeats wherever a SCADA HMI owns the playback position; a timeline playback fix for a SCADA HMI video player is one worked case.
What does a four-screen wall example look like in numbers?
Take a 2x2 wall above a packaging line, four 1080p screens, each fed by its own player on one switched Ethernet network in PTP domain 15: at power-up the lead waits 500 ms before play, so all four first frames land inside the same half second.
The build. Each player's ptp_domain key is set to 15 and the players reboot, so all four share one clock. Content is a 20 s status clip per screen. The clips end on a hard cut, so they do not loop cleanly; the integrator leaves loop mode off and lets the lead player resynchronize on every boundary.
The arithmetic at startup. The lead issues Synchronize with ms_delay at 500. Followers get half a second to load and prepare, then all four screens begin the clip together. Budget the clock error at 1 ms: one 60 fps frame lasts 16.7 ms, so the budget is about 6 percent of a frame (1 ÷ 16.7), invisible at normal viewing distance.
The arithmetic at each loop. The lead catches the media end event and calls Synchronize again with the same 500 ms preparation window, so each pass is 20 s of content plus a 0.5 s boundary beat: 20.5 s per loop. Over one hour, 3600 s ÷ 20.5 s = 175.6, so the wall resynchronizes about 175 times per hour, one media end event and one Synchronize call each time. The beat itself is 0.5 s ÷ 20.5 s = 2.4 percent of wall time, dark at every boundary.
The decision. If a 2.4 percent dark beat at every boundary is unacceptable, recut the four clips to loop cleanly and the beat and the per-loop messages both disappear. If the beat is acceptable at viewing distance, the leader-driven design stands as built.
What should you ask for when you buy a synced video wall?
Ask each bidder to state one player per screen, one PTP domain number from 0 through 127, wired Ethernet for the sync traffic, a 500 ms startup delay in the lead player's Synchronize call, and the resynchronization plan for every loop that does not loop cleanly.
Get the answers in writing on four points. Who builds the content per screen, because slicing one video into edge-matched files is content work, not player configuration. Which player is lead and where its Synchronize calls sit. What the domain number is and whether anything else on the network uses it. And what happens at every loop boundary, with loop mode shown off wherever the lead drives the resync.
Sync is a player capability, not a screen property. Our panel-mount players are built for offline playback from USB or microSD, and the scheme on this page is not part of their documented feature set, so a frame-accurate video wall belongs in a quote discussion about the player stack, the switch and the content. When the screens only have to show stills and status, the simpler build is an offline status board, and planning an offline sensor status display for your shop floor walks it; screens aimed at shop-floor work sit in our factory signage category.
Recommendation: Build any wall that must show one video across two or more screens as one player per screen on a single switched wired network, every player in one PTP domain, the lead's Synchronize delay at 500 ms, loop mode off, and the lead player resynchronizing on every boundary the content does not close cleanly. Treat any needed delay above 1 s as a sign to hunt for errors in the custom code, and recut the content to loop cleanly when a 0.5 s boundary beat is unacceptable.
Questions
A follower player loses power mid-loop. What happens when it boots again?
It rejoins at the correct position without a manual restart. The group's shared playback state names the current state and the time that state was entered, and the shared clock tells the returning player where in which file that moment sits, so it starts playing at the right spot in the right file. The scheme covers playback from local storage on each player.
Does the same scheme keep non-video content in step?
Yes. Any content that can read the lead's group state, with its state name and entry time, can key off it. HTML pages on the players can use that information directly, so text swaps, counters and graphics can change together even where no video plays.
Where do the video files live in this architecture?
On each player's own local storage. The synchronization scheme coordinates playback of local files only; streamed content is outside it. That is also why one player per screen works: each player holds and plays its own copy, and the lead player supplies the timing and the state, not the media.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.