Walk into enough lobbies, clinic waiting rooms, restaurant queues and corporate elevator banks in Los Angeles and you start to notice the same thing: the screens are beautiful, the mounts are clean, the cabling is invisible — and the content is from last spring. A holiday message in March. An employee-of-the-month slide for someone who left. A weather widget spinning on a dead API key.
None of that is a hardware failure. The displays are doing exactly what they were told. What failed is everything downstream of the install: who makes the content, at what dimensions, approved by whom, delivered over which network, and checked by what alarm when a screen goes dark.
We've written before about which industries get the most out of signage. This one is about the half of the project that doesn't appear on the equipment list — and that decides whether the network is still earning its keep in year three.
The Player Choice Is Really a Content-Workflow Choice
Every signage display runs its content from somewhere. There are three realistic options, and people tend to pick on hardware cost when the decision is actually about what kind of content they'll be able to run for the next five years.
System-on-chip (SoC) means the player is built into the panel — Samsung's Tizen-based displays running MagicINFO, LG's webOS line running SuperSign. No external box, no extra power drop, nothing to steal. The tradeoff is that you are largely committed to that manufacturer's CMS and that generation's browser engine, and complex HTML5 dashboards or multiple simultaneous video zones will expose the limits of an embedded SoC fast.
Dedicated media players — BrightSign being the long-standing workhorse — are purpose-built appliances with no general-purpose OS to patch, hardware H.265 decode, GPIO and serial for interactivity, and an open API that most third-party CMS platforms already support. They cost more per endpoint and need a mount, a power source and a port.
Small-form-factor PCs buy you unlimited flexibility and inherit every problem of a managed Windows fleet: updates, antivirus, reboots that land on a login screen in front of customers. We spec them when the content genuinely requires a desktop application, and otherwise avoid them.
| Platform | Per-endpoint cost | Best for | Main constraint |
|---|---|---|---|
| SoC (Tizen / webOS) | $0 added | Menu boards, wayfinding, simple loops, 1–20 screens | Vendor-locked CMS; weak on heavy HTML5 and multi-zone video |
| Dedicated player | ~$300–900 | 4K video, video walls, interactive, mixed-vendor display fleets | Extra device, power and network port per screen |
| Small-form-factor PC | ~$600–1,500 | Live dashboards, custom apps, data-driven displays | OS patching, reboots, by far the highest failure rate |
The mistake: Buying SoC displays to save the player cost, then six months later wanting a live KPI dashboard, a two-zone layout with a live ticker, and a 2×2 video wall — none of which that panel generation handles well. Now the cheap decision costs a hardware refresh.
What works instead: Write down the most demanding thing the network will ever be asked to show, not the thing it launches with. If that list includes live data, multiple video zones, or a canvas spanning more than one panel, buy dedicated players from day one. If it's a menu board loop that changes quarterly, SoC is the right call and anyone selling you players is selling you parts.
Nobody Authors Content at the Size the Screen Actually Is
This is the single most common content problem we're called in to fix, and it is entirely preventable. A designer is handed "make something for the lobby screen," delivers a 1920×1080 landscape file, and the screen is portrait. The CMS scales it, the logo goes soft, the type that looked fine in Illustrator is unreadable from twelve feet, and everyone concludes the display is low quality.
A signage canvas is a hard specification, same as a pixel pitch. It has to be issued to whoever makes content before they make any.
| Deployment | Authoring canvas | Min. type size | Notes |
|---|---|---|---|
| Single landscape, 1080p | 1920 × 1080 | ~36 px | Safe default; most CMS templates assume it |
| Single portrait | 1080 × 1920 | ~36 px | Rotate in the player, not in the file |
| Single 4K | 3840 × 2160 | ~72 px | Only worth it inside ~8 ft viewing distance |
| 2 × 2 video wall (1080p panels) | 3840 × 2160 | ~72 px | Keep type and logos out of the bezel seams |
| 3-panel portrait ribbon | 3240 × 1920 | ~64 px | One canvas across all three, not three files |
Two rules travel with those numbers. Type minimums: the old print-shop rule of roughly one inch of cap height per ten feet of viewing distance translates to about 36 px on a 1080p canvas for a screen read at ten to twelve feet — and headline text wants double that. Dwell time: 7–10 seconds per slide where people are walking past, 15–20 where they're standing in a queue or a waiting room with nothing to do. Faster than seven seconds and a walk-by audience never finishes reading; slower than twenty in a corridor and most viewers only ever see one slide of your loop.
Who Owns the CMS Login
The question that decides whether a signage network stays alive isn't technical at all: whose job is it, by name, to put something new on these screens this month?
When the answer is "marketing" or "IT" or "whoever has time," the honest answer is nobody, and the network goes stale on schedule. When it's a named person with a recurring calendar entry and a short list of templates they can fill in without a designer, it stays current for years.
The mistake: Training six people on the CMS at handover so everybody can use it, with no roles, no approval step and no template lock. Within a month somebody has published a full-bleed phone photo to the lobby wall and somebody else has deleted a playlist.
What works instead: Three roles, configured at commissioning. One or two publishers who can push live. A larger group of contributors who can only drop assets into locked templates and submit for approval. Everyone else gets read-only. Then build four to six templates — promo, event, wayfinding, safety notice, menu, welcome — where the editable fields are text and one image, and the layout cannot be broken. A locked template that a receptionist can update in ninety seconds beats an open canvas nobody touches.
The Network Conversation You Need to Have With IT Before Install
Signage players are headless Linux or Android devices that live on the network for a decade. Hand IT a plan before install day, not a surprise.
Bandwidth is a sync problem, not a streaming problem — if you picked caching players. A 30-second 1080p H.264 asset at 8 Mbps is about 30 MB; the same clip in 4K H.265 at 25 Mbps is roughly 94 MB. A caching player downloads it once, overnight, and plays it from local storage forever after, so steady-state bandwidth per screen is close to zero. A 100-asset loop of 1080p clips is roughly 3 GB on disk, which is why 16–64 GB of player storage is plenty.
Live content is the opposite. Streaming a 1080p feed or an always-on web dashboard runs a sustained 5–8 Mbps per endpoint. Twenty screens on live content is 100–160 Mbps of continuous traffic, which is a real capacity conversation and a real argument for putting the players on their own VLAN.
The rest of the list is short: outbound TCP 443 to the CMS host, NTP for clock sync (scheduled dayparts drift without it), DHCP reservations or static addresses so you can find a player later, a dedicated signage VLAN, and no inbound ports — a properly designed player calls out to the CMS and never needs to be reachable from outside. Each screen also wants a dedicated data drop; if the building is still open, this belongs in the rough-in cabling scope rather than in a surface raceway later. PoE-capable players are worth specifying where you can, because one cable per screen is one failure point per screen.
What Tells You a Screen Has Gone Dark
A signage network that nobody monitors isn't a network, it's a collection of screens. Every serious CMS reports a player heartbeat; the question is whether that report reaches a human.
- Heartbeat alerting — an email or a ticket when a player misses check-in for an hour. Without it, a dead screen in a back corridor can stay dead for weeks.
- Proof-of-play logs — mandatory the moment anyone is paying for placement on your screens, including internal departments. It's also the only honest answer to "is anything actually running on screen 14?"
- A defined failure state — decide now what a player shows when it can't reach the CMS. The right answer is almost always: keep playing the last good cached loop, silently. The wrong answer is a connection-error dialog in front of guests.
- Scheduled power — on/off dayparts via CEC or RS-232. A panel running 10 hours a day instead of 24 sees less than half the duty cycle, which matters on a commercial display rated for 16/7 and matters more on the power bill.
- Content expiry dates — set an end date on every time-sensitive asset at upload. This single habit is what prevents the March holiday message, permanently.
Settle These Before the Screens Ship
Six answers, and the content side of a signage project stops being the part nobody planned:
- The most demanding content the network will ever show — which picks SoC versus dedicated players.
- The exact authoring canvas, in pixels, for every screen group, issued to whoever designs.
- The named person who publishes, and how often.
- The four to six locked templates they'll publish into.
- The VLAN, the outbound ports and whether content caches or streams.
- Where the heartbeat alert goes, and what a player shows when the network drops.
Handsome Group designs, installs and commissions digital signage across Los Angeles — and we hand over the content workflow with the hardware: canvas specs, locked templates, publisher roles, monitoring and a closeout package that documents all of it. If you have screens already up and a loop that stopped changing, that's usually a two-day fix, not a replacement.