---
title: Sync Multicast Video Walls
slug: hardware/sync-multicast-video-walls
docTags:
createdAt: 2025-03-11T07:10:25.852Z
---
Synchronous stream playback requires a transport stream with an embedded *Program Clock Reference* (PCR) sent as multicast. The PCR from the playing stream is used as the common clock (the *System Time Clock* or STC) and the video player's STC is locked to the incoming PCR, so the server must send this clock at the correct time. This document is an overview - for additional information about videowall synchronization, see [Video Wall Synchronization Architecture](docId:2Tw5hFK9U5TjdWF8X-1s3).
# Stream Requirements
- The multicast stream must contain well timed PCRs. This means that:
- PCRs are regular (for example, every 50ms)
- PCRs must accurately represent the time that they appear on the network.
- There must be a maximum of one PCR value per network packet. Not all servers can manage this.
- The stream has to be a resolution and frame rate that is supported by the player.
- A high-quality commercial encoder is required. BrightSign is not suitable as an encoder.
# Additional Information
## PCR Jitter
PCR Jitter is the variability between the actual PCR arrival time and the correct arrival time: You must have low jitter in the PCR to have good sync. Although jitter shouldn't be a property of the stream, almost all servers add large amounts of jitter to the PCR before they appear on the network. When PCR arrival time varies, it will always lag the correct arrival time (unless the server sends the PCR ahead of time).
## Content vs. Video Mode Frame Rate
When referring to matching these frame rates, all components of the frame rates are relevant. So 29.97p (progressive) is not identical to 29.97i (interlaced).
## Known Limitations
During the first minute or so of stream playback, the HDMI**®** output clock will be slewing at \~240ppm to align its VSYNC with the PCR. With some displays this may cause HDMI issues while the locking occurs. After this locking period, the VSYNCs of players playing the same multicast stream should be aligned and the screens in total sync.
Note that the video mode frame rate affects the speed of lockup, because the maximum clock slew speed is 240ppm and the lower the frame rate the more the time of the VSYNCs may have to be adjusted. For example, 25p video has a 40ms period, so to align the VSYNC, it might have to be adjusted by 20ms at 240useconds/second but for 60p video, the VSYNC will have to only travel a maximum of 8ms.
## How to Set PCR Mode
The default behavior for the firmware is to run old PCR locking code. To enable the new code, the pcr-mode parameter must be set to one:
```text
player = document.createElement('video');
player.setAttribute("x-bs-pcr-mode", "1");
```
Or:
```text
```
Or appended to the URL (this lets you try the feature without changing your JavaScript):
```text
"udp:// 239.194.0.204:5000/?pcrmode=1
```
## Testing
To test, move to BrightSignOS 8.2, use PCR mode on the video element (either on the roVideoPlayer or HTLM5 Video tag with PcrMode:1 or x-bs-pcr-mode='1), and call `SetSyncDomain` to enable VSYNC locking across the video wall. The expected behavior is that the units in the wall will be perfectly in sync. The VSYNC from each player will be synchronized, meaning that the displays will all be receiving frames from the separate BrightSign players in sync. The content is synchronized to the PCR which is also the same across all players, so the frames being output from each separate player will be the same.
To resolve any jitter issues (for network streams, not local content), test:
1. Different encoder sources such as Harmonic, Technicolor etc. with a vector-quality stream.
2. Long term behavior (sync drift)
See the section below for more information about debugging sync issues.
# Troubleshooting
## PCR Analysis
*pcapreport* captures a PCAP of the video stream with PCR and compares the wall time on the PCAP and the PCR value to see the difference between the two clocks. If the PCAP is recorded on the server, this should result in close to 0 slew as the clocks are likely the same. If the PCAP is recorded on another device, then a slew would be expected which reflects the difference in clock speeds between the device and the server. *pcapreport* is from a suite of transform stream tools (tstools), and has multiple [flags](https://manpages.debian.org/testing/tstools/pcapreport.1.en.html) (for example, *pcapreport -t* can generate a test stream from any PCAP).
Note that *pcapreport* will indicate PCR problems, but additional tools may be needed to further analyze the *pcapreport* output.
To install *pcapreport* on macOS X:
- Download [this repo](https://github.com/sepkooo/tstools-for-macos) as a zip and unzip on your Mac.
- In your terminal, go to the directory that you just unzipped.
- Run `sudo make install` on the command line (you may need to enter your password).
The *pcapreport* output will be a .csv Excel file.
## PCR Debug Output
PCR Debug output should only be used in debugging.
To enable PCR Debug output, set the *x-bs-pcr-debug-file* attribute:
```text
player = document.createElement('video');
player.setAttribute("x-bs-pcr-debug-file ", "tmp:/pcr.txt");
```
or:
```text
```
The PCR Debug output will be a txt file, like the example below:
::Image[]{src="https://api.archbee.com/api/optimize/511c8QBH-VHiwWnyzIwUb/AN8aqI3uxLJ-4mVXiV_uT_7pcrtxtnew.png" size="50" width="1144" height="1361" position="center" darkWidth="1144" darkHeight="1361" showCaption="false"}
## Troubleshooting Flowchart
# Contact Info
If you have completed the troubleshooting flowchart and have not gotten the expected results, submit a [Zendesk ticket](https://brightsign.zendesk.com/) using the intake form and providing the requested details so we can provide further support.