One Processor for Three Screens: Independent Video, Resolution and Signal Architecture

“One processor controls three screens” can mean that all three screens show the same content, or that each screen plays a different video. These are different requirements. A project with a 3.2 × 1.92 m centre screen and two 1.92 × 1.92 m P2.5 side screens is a useful example: if 640 × 640 mm cabinets are used, the centre screen can be planned as 5 × 3 cabinets and each side screen as 3 × 3 cabinets. The three areas should remain independent in both the mechanical drawing and the control plan.

Calculate the resolution of each zone first. With a P2.5 cabinet whose theoretical unit is approximately 256 × 256 pixels, the centre screen is about 1,280 × 768 pixels and each side screen is about 768 × 768 pixels. These are engineering estimates based on cabinet and pitch assumptions; the final reference is the actual cabinet drawing and receiving-card configuration. The processor must have enough input/output cards, windows, layers and output capacity to map those pixels to separate zones. A single continuous output cannot automatically guarantee three independent videos.

Draw the system in four layers: content computer or media server, video processor, sending/output cards and receiving cards. The content computer can use one large canvas or multiple playback windows. The processor handles window position, scaling, cropping and switching. The output/sending layer transports each zone to the relevant cabinets. The receiving card handles cabinet-level pixel distribution. RACE RESULT, a browser, an event-data application or a customer’s own software is a content/data source; it does not replace the LED sending and receiving chain.

For independent content, name three coordinate systems such as CENTER, LEFT and RIGHT. Set the output window, aspect ratio, black field and test pattern for each zone. Avoid building one ultra-wide canvas and relying on last-minute cropping if the screen sizes are different. When a screen dimension changes, a three-window layout is easier to review and maintain.

Acceptance should be performed by zone. Confirm that each screen can show a test pattern by itself, confirm simultaneous playback, then test switching, power recovery, input loss, source switching and content scaling. If the customer asks for different videos from one processor, the proposal should specify the processor model, input/output cards, window or layer count, output resolution, sending ports, screen-zone resolutions and playback software. “Supports three screens” is not enough detail for a reliable handover.

The content workflow should be designed with the processor rather than after it. Define whether the operator will use three independent playback windows, a single canvas with fixed coordinates, processor scenes, a media server or a browser/venue application. Decide where scaling occurs and where cropping occurs. Two systems may both claim to support three screens while one uses independent outputs and the other uses a single wide raster. Their content files, failure modes and recovery steps are different.

Plan the failure behaviour as well. If one input computer restarts, should all three screens show a standby slide or should the other zones continue? If one screen is powered down, should its processor window be blank, frozen or routed elsewhere? If an event operator changes a source, how do they know which zone is affected? Write these decisions into the operating guide and test them with the customer’s actual operators.

Finally, keep one scene file for commissioning and one approved scene for daily use. The commissioning scene should expose grid, labels and test colours. The daily scene should be clean and easy to recall. A named backup scene gives the after-sales engineer a safe starting point if a customer accidentally moves a window or changes the output route.

During operator training, ask the operator to recall each scene without changing the underlying configuration. Show how to identify the active input, selected screen zone and output status. If a scene is changed, the operator should know how to return to the approved file and who must be informed. Simple labels and a controlled scene list reduce the chance that a well-intentioned operator will “repair” a mapping problem by creating a new undocumented layout.

Frequently Asked Questions