I analyzed a video synchronization test from a recent video installation, and suggested that although the synchronization between screens was not perfect, it was certainly satisfactory, and as good as might be expected given the design of the system. Now, lets see why.

When a multi-screen video system is in proper sync, each video frame begins at exactly the same time. A system that draws at 60fps will draw each frame in approximately 16.67 milliseconds. During those 16ms, an LCD display will update all of the pixels on screen from top to bottom. We will call the moving line across which the pixels are updated the Raster Line. In this slow-motion test video, you can see video frames alternating between full black and full white, updated from top to bottom. The screens are mounted in portrait orientation, which is why the updates happen right to left:

‍

‍

Many of the screens seem to be updating together, but some do not. This is because the system does not include dedicated hardware to ensure that the signals are in sync, so many of the displays begin their updates at different time. The system is frame-synchronized, meaning that all displays begin a raster sync within one raster-pass of each other. It just isn’t raster-synchronized.

If the displays were indeed raster-synchronized, we might represent their signals like so:

‍

‍

Many of the screens seem to be updating together, but some do not. This is because the system does not include dedicated hardware to ensure that the signals are in sync, so many of the displays begin their updates at different time. The system is frame-synchronized, meaning that all displays begin a raster sync within one raster-pass of each other. It just isn’t raster-synchronized.

If the displays were indeed raster-synchronized, we might represent their signals like so:

‍

Many of the screens seem to be updating together, but some do not. This is because the system does not include dedicated hardware to ensure that the signals are in sync, so many of the displays begin their updates at different time. The system is frame-synchronized, meaning that all displays begin a raster sync within one raster-pass of each other. It just isn’t raster-synchronized.

If the displays were indeed raster-synchronized, we might represent their signals like so:

‍

In the case of Displays 1 and 4, we have a point in time, Time X, at which both displays are entirely black. In the case of Displays 2 and 3, at Time X we see both displays entirely white. We still consider them to be in sync, and we should not consider these anomalies to indicate a failure of the synchronization mechanism.

There is a minor issue in the test video that does bear mentioning. The flashes move through four rows of white in each column. There are extremely brief moments during which you might notice a touch of white that is visible in the first and third row. This should be obvious after repeated viewing. I leave it as an exercise for the reader to demonstrate why, even in a worst case scenario, this should not be observed if the frame synchronization mechanism is working properly. (<sarcasm>Yeah, right.</sarcasm>) So why am I not concerned? Because it is the nature of LCD display pixels to take some time to switch from full white to full black. Typical response times for the particular displays in this system are specified as 9ms, which means that after the raster line passes and updates a pixel from black to white, it may take an average of 9ms (more than half a raster pass) for that pixel to fully change. I say “Average” because white-to-black and black-to-white transitions are usually slightly different, and the spec will mention only the average of the two. If the response time was an ideal zero ms, our raster line would be crisp and clear in our slow-motion capture, but in reality it is not. The raster line is blurry because after it passes, the pixels take time to change between black and white. We can expect that some pixels might remain white for a brief time after we expect them to go dark, resulting in this subtle observable discrepancy.

What does all this mean? It means that in a slow-motion test video of 24 synchronized displays, we observe nothing to suggest that the synchronization mechanism isn’t performing as well as we could hope for. To the viewer, the synchronization is true, and we deem the project a success.

‍