Multicast Video Wall Sync

1 Stream Requirements
2 Additional Information
- 2.1 PCR Jitter
- 2.2 Content vs. Video Mode Frame Rate
- 2.3 Known Limitations
- 2.4 How to Set PCR Mode
- 2.5 Testing
3 Troubleshooting
- 3.1 PCR Analysis
- 3.2 PCR Debug Output
- 3.3 Troubleshooting Reference Flowchart
4 Contact Information

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 https://brightsign.atlassian.net/wiki/spaces/DOC/pages/423035878.

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:

player = document.createElement('video');
player.setAttribute("x-bs-pcr-mode", "1");

Or:

<video loop width="1920" height="1080" hwz="on" x-bs-pcr-mode="1">
     <source src="udp:// 239.194.0.204:5000/">
</video>

Or appended to the URL (this lets you try the feature without changing your JavaScript):

"udp:// 239.194.0.204:5000/?pcrmode=1

Testing

To test, move to the BrightSign 8.2 OS, 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:

Different encoder sources such as Harmonic, Technicolor etc. with a vector-quality stream.
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 (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 Mac OS X:

Download this repo 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:

or:

The PCR Debug output will be a txt file, like the example below:

Troubleshooting Reference Flowchart

Contact Information

If you have completed the troubleshooting flowchart and have not gotten the expected results, submit a Zendesk ticket using the intake form and providing the requested details so we can provide further support.