One x86 box can feed three screens three camera streams only when two gates open at once: the signage software drives three independent HDMI outputs and decodes each stream in fixed-function silicon. The protocol matters too: desktop builds commonly take HLS and need an RTSP-to-HLS conversion server, while some Android builds take RTSP directly. For a wall whose content never changes, three single-stream players, one per screen, is the dependable answer.
You want three security camera streams on three screens, from one box, each screen starting its own feed at power-on and never being touched again. The short answer: one box can do it only when two gates open at the same time. The signage software has to drive three independent HDMI outputs, and it has to decode each stream in hardware-accelerated decoding blocks. Most signage players are built one output per machine, and several desktop builds accept the camera's RTSP feed only after another server converts it to HLS. For a wall whose layout never changes, three single-stream players, one per screen, stays the dependable answer. The one-box route earns its place only when rack space or switch ports are the binding constraint. The numbers below show which gate actually fails, and the table gives the decision for each way of building the wall.
Three gates decide it: outputs, decode, protocol
Outputs. The graphics chip must support three independent displays, and the player software must pin a stream to each output and start it unattended at power-on. A graphics chip that drives two screens cannot put three different pictures up, however many connectors are on the case. This is where most signage software stops: the common builds assume one display per machine. If the software's own documentation does not name multi-display output, plan one player per screen. Driving several screens from one player is a documented pattern for content walls, and one Android signage player driving multiple displays shows how each output gets its own playlist.
Decode. One 1920 x 1080 stream at 30 fps is 62.2 million pixels per second; three together are about 187 million. Recent integrated graphics decode that with fixed-function video blocks and room to spare. On the CPU it is different: as a planning figure, software decode of 1080p H.265 wants roughly one fast core per stream, so three streams want three cores plus operating-system headroom, which a small low-power box rarely has. Insist on hardware-accelerated decoding for the codec your cameras output.
Protocol. Cameras speak RTSP. Desktop and web-based player builds commonly accept HLS, and their vendors document that an RTSP feed must first be converted by an encoding server; some Android builds take RTSP directly. The split is explained in why an RTSP stream will not play on an Android signage player. If your route needs a conversion server, that server is one more device with its own power feed and switch port, and when it stops, every screen fed from it goes dark together.
Four ways to feed three screens
| Route | What it needs to work | Decode load | If one device fails | Rack cost | Verdict |
|---|---|---|---|---|---|
| General-purpose x86 mini PC with multi-display software | Graphics chip documented for 3 independent displays; software that pins each output and auto-starts at power-on | 3 streams, about 187 Mpx/s | All three screens | 1 switch port, 1 power feed | Only with both gates documented |
| Industrial multi-output signage player | Datasheet names independent displays and hardware-accelerated decoding; the class is published up to nine displays from one box, with 4K-class graphics | 3 streams in silicon | Every screen on the box | 1 switch port, 1 power feed | The consolidation path when rack space is binding |
| Three single-stream players, one per screen | Each player set up once | 1 stream, about 62 Mpx/s | One screen | 3 switch ports, 3 power feeds | Dependable default for a wall that never changes |
| HDMI splitter | Nothing; it repeats one output | 1 stream | All screens keep the same feed | 1 switch port, 1 power feed | Cannot do this job |
A splitter repeats one feed on several screens. A video wall processor composes several feeds into one canvas. Neither puts three different full-screen streams on three screens from one output; HDMI splitter or video wall processor for two screens walks through where each belongs.
Example: three 1080p cameras on one mini PC
Scenario: three cameras, each sending 1920 x 1080 at 30 fps, H.264 main stream. Typical main-stream settings for a 1080p H.264 security camera land between 2 and 6 Mbps, so 4 Mbps is a fair planning number. One small x86 PC with a 1000 Mbps LAN port feeds three 1920 x 1080 screens.
Network. 3 × 4 Mbps = 12 Mbps. Against a 1000 Mbps port that is 12 ÷ 1000 = 1.2% of line rate, and even a 100 Mbps link carries it at 12%. The network never decides this job.
Decode. One frame is 1920 × 1080 = 2,073,600 pixels. At 30 fps that is 2,073,600 × 30 = 62,208,000 pixels per second, about 62.2 Mpx/s per stream, and 3 × 62.2 = 186.7 Mpx/s for the wall. Hardware-accelerated decoding on recent integrated graphics handles that. Software decode of the same three streams as H.265 wants roughly three fast cores plus headroom.
Codec switch. If the cameras output H.265, the same picture rides on about half the bitrate, roughly 6 Mbps total, and the network figure drops again. Software decode gets heavier, not lighter; hardware-accelerated decoding is indifferent to the switch.
Outputs. The case needs three connectors, and the graphics chip must document three independent displays. Most small x86 boxes ship with two. The software must also start each output on its assigned stream at power-on, with no login in the path.
Verdict: the network gate passes with a factor of about 80 in hand, decode passes with hardware-accelerated decoding, and the output-plus-software gate is where one-box plans usually die. Fail any gate and the answer is three players, one per screen.
Where each option wins
A multi-output industrial player wins when the rack is the constraint. The class is published up to nine displays from one box, and its datasheet names independent display counts and codec support. The trade: the whole wall is one failure domain, so it suits walls where someone notices a dark screen and swaps the unit.
A general-purpose x86 PC wins when you already own it and the software documents both gates. It saves two switch ports and two power feeds. If the software needs an RTSP-to-HLS conversion server, that server takes a port and a power feed back, and it becomes the single point that darkens the whole wall.
Three single-stream players win on isolation. Each decodes one stream, one port and one power feed each, and a failed player darkens one screen. For a camera wall whose layout never changes, nothing needs touching again.
A splitter wins nothing here. It exists to repeat one feed on several screens, and three different pictures on three screens is exactly what it cannot do.
The screens are the easy half of this job; they are chosen by viewing distance and brightness, not by streaming. If the same building also needs a notice or status screen that plays its own files from a card, that is a different device: see the panel-mount display range.
The decision
Recommendation: Keep one player per screen. Three camera streams are three light single-stream jobs, not one hard three-stream job: each screen starts its own feed at power-on, and a failure takes down one screen. Consolidate only when rack space or switch ports are the binding constraint, and then buy a multi-output signage player whose datasheet names the number of independent displays and hardware-accelerated decoding for H.264 and H.265 at 1920 x 1080, and bench-test that every output starts its assigned stream at power-on before mounting day. A general-purpose mini PC earns its place only when its software documents both gates. The same one-player-versus-many decision for ordinary content walls is worked through in one signage player or one per screen for four TVs.
Questions
Will three HDMI ports on one mini PC give three different pictures?
Only if the graphics chip supports three independent displays. Mirrored ports repeat one picture on every screen, so the independent-display count in the graphics specification is the number to read. Then confirm the player software can pin a different stream to each output and start it at power-on. If any part is missing, three separate players is the fix.
What do I check in a multi-output player's datasheet?
Five lines. The number of independent displays, not mirrored outputs. Hardware-accelerated decoding for H.264 and H.265 at 1920 x 1080 and 30 fps. Per-output content assignment with auto-start at power-on. Which stream protocols the build accepts: RTSP native, or HLS only with a conversion server. And the network and power connections the box needs in the rack. If a line is not printed, treat the feature as absent.
Can an IMD Signage display take the camera stream directly?
No. These panel-mount units play images and video from microSD or USB, and the HDMI port is an output, so there is no video input for a camera feed. Put a dedicated stream player in front of whichever screen you choose. Where our displays fit is the other screens in the building: notice boards, menus and status pages playing their own files, offline, with no subscription.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.