Rendered video either plays or it does not. Real-time content is different. A scene that looked fine in the studio can drift after a long run, or leak memory on a cue nobody rehearsed. Some faults appear only once a live camera input is attached. Most of them surface late, on site, when there is no time left to fix them properly. The harness exists to move that discovery earlier. It is internal tooling for our own work, not a client project and not a product.

What it checks

The harness loads a scene and drives it from a saved cue list. It feeds the scene stand-in input: recorded sensor data, a looping camera file, dummy show control messages. While it runs it logs frame times, memory use and output resolution for every canvas. It then writes one timeline with the missed frames marked. We leave soak runs going overnight and read the timeline the next morning. Most of what it catches is dull. A canvas quietly rendering at the wrong size. A shader that only becomes expensive once several layers are live. A scene that behaves until the cue list loops back to the start.

The first version tried to do more and failed at it. The plan was to capture reference frames and compare every run against them, so any change in the visuals would fail the check. That does not survive contact with real-time work. Noise fields, particle systems and anything driven by a clock never repeat exactly, so every run failed. We started ignoring the result, which is worse than having no check at all. The harness now measures behaviour rather than appearance and leaves the looking to a person. It cannot tell us how a scene reads on an LED wall at show brightness, or how it feels in the room. So it sits in front of a site test rather than replacing one. The interface is a command line and a log file. That is enough for now.