Multicast Video Wall Sync

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 sync 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 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 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 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 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 player = document createelement('video'); player setattribute("x bs pcr debug file ", "tmp\ /pcr txt"); or \<video loop width="1920" height="1080" hwz="on" x bs pcr mode="1" x bs pcr debug file="tmp\ /pcr txt"> \<source src="udp\ // 239 194 0 204 5000/"> \</video> the pcr debug output will be a txt file, like the example below 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