Email one, from the client
"The camera image on the wall is behind the presenter. When he waves, the wall waves a moment later. Is the screen slow?" We asked for a phone video of the presenter and the wall in the same frame. The delay in the clip was about 180 ms, which is enough to feel wrong but not enough to look broken.
Email two, from our engineer
"The screen is not slow. An LED wall adds 8 to 16 ms of processing. The delay is upstream. Please send the model of the camera, the switcher, and the processor, and tell me whether the camera is set to 25 or 30 fps." The reply: IP camera at 25 fps, a hardware switcher, an HDBaseT extender, and a video wall processor with scaling enabled.
Email three, the budget
| Stage | Delay |
|---|---|
| IP camera encode + network | 80 – 120 ms |
| Switcher | 16 ms |
| HDBaseT extender | 8 ms |
| Processor with scaling | 33 ms |
| LED wall | 12 ms |
| Total | 149 – 189 ms |
What we changed
The camera was the biggest single item. We switched it from IP streaming to SDI output, which removed the encode and network hop. We also disabled scaling on the processor by feeding it the native canvas resolution. Total delay dropped to about 45 ms, which nobody notices.
The pattern to remember
A video wall is never the slowest part. Cameras, encoders, and scalers are. If a client complains about delay, measure the chain in order from source to screen and do not start by blaming the panel. In nine cases out of ten the fix is upstream and costs nothing.
One thing worth writing into the design
If the wall will ever show a live presenter, specify the total latency budget in the AV drawing: for example, under 60 ms from camera output to screen. That single line prevents the argument later, because every vendor knows what they have to deliver.