Times Square Signs in Slow-Motion

And now, by popular demand, a few high-speed captures of LED signs in Times Square:

(All videos were captured at 1000fps with a Casio Exilim EX-FS10, rendered here as 30fps video.)

When transitioning from one frame to the next, the M&M’s sign and all components of the ABC sign update all pixels on the sign at once, demonstrated here in less than one of my video capture frames, so we know it’s less than 1ms. The different components of the ABC sign seem to update at different times because of a sync issue, not an LED technology issue.

LCD displays will lock to incoming signals with a variety of timings, often anywhere from ~57Hz to ~63Hz, depending on the display. When you tell a graphics card to output at 60Hz, it is doubtful that it’s putting out a true 60.000Hz. Depending on the make of the card, the drivers installed and the phase of the moon, the actual refresh rate will vary quite a bit. LED signs tend to maintain their own clock, regardless of the video signal that might be driving it. It is likely that without a genlock signal keeping the system in sync, the source signal will not provide frames at exactly the same frame rate that the LED sign is displaying them. The more disparate the source and display refresh rates, the more dropped or doubled frames you will observe, which will be visible to the layman as stuttering.

The Reuters sign, however, DOES update one row at a time, just like an LCD. The passing of the raster takes about 14ms, as we might expect for a sign running at 60Hz:

I cannot speculate as to the implications for their sync mechanism, except to observe that the rasters of the three screen segments visible in this video seem to be in good sync, though the frames themselves do not.

Video Synchronization Testing

For a recent project, 3byte developed custom graphics software for a 36-screen video wall. This required some kind of synchronization mechanism with which to keep the various screens in sync.  There are dedicated hardware devices like the nVidia G-Sync card that make this sort of thing really simple. However, this project involved driving four video display from each of our graphics workstations, and we ran into trouble with these cards during initial testing. Instead, we developed our own sync mechanism that runs over the local network.

To test our synchronization, we loaded up a video file that would make the quality of the sync really obvious. Breaking the video vertically into four quarters, on each frame of the video we flash a white rectangle in one of the quarter regions. Like so:

Really, it works better with some good PsyTrance. But what is actually happening? Whatever it is, it’s happening too fast to determine with the naked eye. So I picked up a Casio Exilim EX-FS10 and shot the system at 1000fps:

Far more interesting. The resolution of the video is not great, but it shows us what we need to know.

First of all, you will notice the scrolling of the video from right to left. The screens are actually mounted in portrait orientation, to the motion that you see is actual a top-to-bottom scroll as far as the display is concerned. These LCD displays refresh the pixels on screen 60 times every second, but they don’t all update at the same time. The display updates the pixels line by line from top to bottom, each line updating left to right. This makes sense when we consider that analog and digital video signals order pixel data in this way, just like reading a page of a book. At regular speed, a screen refresh seems instantaneous, but at high speed, we can see the way the screen transitions from black to white one line at a time. This scrolling line across which the pixels are updated we might call the Raster, or the Raster Position.

In this system, the timing of each display’s Raster Line is determined by the graphics card in the computer. Whenever the card says “start drawing the next frame… NOW!” the monitor locks in with that signal and starts the Raster Line at the top of the screen. Had we G-Sync cards for this system, we could tell the graphics cards to chant their “NOW” mantras in unison, and in slow motion we would see the Raster Lines of all the displays being drawn in perfect synchronization. As you can see in the video above, this is not the case for our system, where the lines are updated on different displays at slightly different times. This difference between displays is so subtle that it is never noticed by a viewer. The question is, are the correct frames being drawn on each pass of the Raster?

This system supports source video playback at 30fps, but the displays update at 60fps. Each source video frame is doubled on screen, so a single frame of white flash in our source video will be drawn white in two consecutive passes of the Raster Line on the display. In the slow-motion video, we see the raster line update each screen, then a pause while the subsequent Raster pass draws another frame of white (no change) before moving on the to next source video frame.

If you look at the third and fourth columns of displays, you will see that the Raster seems almost to move straight across from the fourth to the third as it updates the two columns together. Of course this is only an illusion, as the Raster does not sync between frames. What we are actually seeing is one display in column three that seems to be lagging behind column four by almost a full 17ms Raster pass. (I say 17ms because that is just about the amount of time it takes to refresh a display at 60fps.) This is not ideal, but in a system with no dedicated sync hardware, it is not surprising, and not a deal-breaker. It means that at 30fps, these screens are within a half-frame of perfect sync, which is nearly undetectable to the eye.

In Part II, I provide an analysis of the best possible sync performance for a network-synchronized video system. I  explain why the 17ms discrepancy in the video above falls within the tolerances of this system. We are quite pleased with the performance of our synchronization mechanism, and believe that it rivals or surpasses that of other industry-standard network-sync video systems. Next chance I get, I’ll run a similar test on a Dataton Watchout system and let you all know how it goes. Stay tuned.