By David
The screen is only half of an LED display system. What an audience actually sees, and what an operator has to touch every week, is produced by the content pipeline: the tools that design the media, the playback hardware and software that run it, and the schedules and permissions that decide who can change what, and when. Buyers who choose the panel carefully and then treat software as an afterthought tend to discover the mistake on cutover day, because the content layer outlives the hardware and shapes every routine task.
This guide merges the design side and the management side of that pipeline into a single reference. It covers how to design to a real pixel map, how to choose playback hardware and a content management system, how scheduling, version control and multi-site rollout behave in practice, and which failure modes actually take screens dark. It is written for technical buyers, integrators and facility managers who have to commit to a configuration and then live with it for years.
Designing for an LED display is not the same as editing video. A wall is a grid of physical pixels, and content has to map onto that grid exactly, or it scales, blurs and shimmers. A video editor works in a canvas of a chosen resolution; an LED designer works in a pixel map that already exists on the hardware and cannot be redefined at will.
The pixel map is the bridge between the two. It records how many pixels wide and high the wall is, how the receiving cards are addressed, where each cabinet boundary falls, and the signal path from the processor to each output port. Every content brief should begin there. Ask the manufacturer for the pixel map of your exact cabinet layout rather than a generic datasheet, because two walls of the same physical size can map differently. A mismatch of even a few pixels forces the processor to rescale the whole image and softens every edge.
This is also where the hardware and the software decisions meet. The pixel count you order determines what content is possible later, so the screen specification and the content brief should be written together rather than months apart. If the canvas is not fixed yet, the LED display media specification guide explains how source material is prepared once the map is known.
Once the map is fixed, design in the native resolution. Content authored at the native pixel count fills the wall one to one, with no scaling and no interpolation. If the wall is very large, design at a clean fraction such as half or a quarter and let the processor scale up by a whole number, which stays sharp. Fractional scaling is what produces the softness buyers later blame on the panel.
Aspect ratio is the trap most projects fall into. A wall that is 6 by 3 metres is a 2 to 1 shape, close to but not the same as 16 to 9. Stretching standard video into it distorts faces and turns circles into ovals. Design for the true wall ratio, or letterbox deliberately against a branded background, instead of letting the processor stretch the picture to fit. A designer who starts from the pixel map avoids this entirely.
A versioned master file keeps the canvas stable. Once the pixel map and safe area are agreed, freeze them as the project template so every future creative uses the same dimensions. Templates prevent the slow drift that happens when each designer begins from a slightly different resolution, and they make the handover to a new creative team painless. The content version control guide covers how to name and store those masters.
Safe areas protect important elements from cabinet seams and from the physical obstructions nobody remembers until install day: doors, columns, handrails and support posts. A logo placed exactly on a seam looks split, and a headline sitting behind a post is half hidden. Mark the safe area on the pixel map and treat it as the real canvas, not the outer pixel boundary.
On curved and wrap-around screens the safe area also has to account for pre-distortion. Text that reads cleanly on a flat wall can compress at the curve or stretch across the wrap. Build that distortion into the template once, rather than correcting it campaign by campaign and hoping each designer remembers the rule.
Viewing distance sets how much detail the content can carry, and it is the number the content team and the screen designer have to agree on before anyone picks a font size. A wall viewed from three metres can show fine type and subtle gradients; the same wall viewed from thirty metres cannot. Detail that is invisible at distance is wasted production effort, while type sized for close viewing becomes unreadable across a plaza.
Pitch and content design are locked together. A fine-pitch wall viewed closely carries detailed graphics and small text; a coarse-pitch screen viewed from a distance needs bold shapes and large type. The content team should know the pixel dimensions and viewing distance of every screen in the network before designing a campaign that has to run across all of them. If you are still weighing the screen technology itself, the comparison in LED versus LCD digital signage explains why the viewing model differs from an LCD panel.
Formats that the receiving hardware decodes in hardware are preferable, because software decoding adds latency and can stutter on high-pixel-count screens. The hardware decode list should be checked against the content pipeline before the screen is specified, not after the first campaign fails to play. The safest approach is to standardise on one or two well-supported codecs and refuse ad hoc formats that one editor happens to prefer.
Bitrate matters as much as codec. A file that plays smoothly on a desktop can drop frames on a player if the bitrate is high or the video carries many alpha layers. Where alpha overlays are needed, plan for a media server rather than a basic player. Live feeds and data feeds each have their own path and their own failure behaviour, so treat them as separate inputs in the design.
| Source type | Typical use | Watch-out |
|---|---|---|
| H.264 / H.265 video | Promo loops and general video | Confirm hardware decode support on the chosen player |
| Still images | Menus, prices, static offers | Author at native resolution; avoid upscaling small files |
| Alpha-channel video | Overlays and compositing | Many alpha layers can stutter on a basic player |
| Live input (SDI or HDMI) | Events and broadcast feeds | Requires a media server, not a playback stick |
| Data feed (text or JSON) | Prices, scores, transit times | Define what the screen shows when the feed goes stale |
Playback range runs from free vendor tools that push a single file to a player, through players with a built-in scheduler, up to full media servers that composite multiple layers in real time. The right choice depends on how the content is used. A store rotating a handful of promo clips needs a scheduler player; a live event with multiple layers and live inputs needs a media server.
Match the software to the resolution and frame rate you actually intend to run. A player that advertises 4K playback may still drop frames when the content uses high bitrate or many layers, so check codec support and the decoding method before committing. Buying one tier above the launch requirement is usually cheaper than replacing players across a live network later.
| Capability | Basic player | Scheduler player | Media server |
|---|---|---|---|
| Single-file loop | Yes | Yes | Yes |
| Day-parting schedule | No | Yes | Yes |
| Multi-layer compositing | No | No | Yes |
| Live input capture | No | No | Yes |
| Remote monitoring | Limited | Yes | Yes |
| Geometry mapping | No | Basic | Advanced |
A content management system sits between the creative files a designer produces and the playback hardware connected to the screen. The features that matter in daily operation are rarely the ones that look impressive in a demo. Remote scheduling, multi-screen synchronisation, live data feeds and clear proof of play are the capabilities that reduce staff time week after week. A platform that is easy to operate is worth more than one with a longer feature list that nobody uses.
One practical question decides a lot of purchases: can the CMS drive controllers from different manufacturers? Systems built on standard protocols can often run compatible controllers from other brands, but deep features such as cabinet-level diagnostics usually require matching hardware. That question has to be answered before the hardware is chosen, not after. The content workflow guide walks through how the pieces connect end to end.
| Feature | What it does | Operational benefit |
|---|---|---|
| Remote scheduling | Assign content to a screen, group or zone by time and date | Content changes without a site visit |
| Multi-screen sync | Frame-locked playback across players | Clean video walls without tearing |
| Emergency override | Priority content that interrupts the schedule | Safety and urgent announcements |
| Live data feeds | Real-time inputs such as prices or transit times | Content stays current automatically |
| Role-based access | Per-user permissions and approved templates | Safe publishing by non-technical staff |
| Proof of play | Logs of what ran and when | Evidence for advertisers and internal audits |
| Remote diagnostics | Player and cabinet health reporting | Faults found before the audience sees them |
Scheduling is the core of an operational network. Content should be assignable to a screen, a group, or a zone within a screen, with time and date rules and day-part switching that changes brightness and content together. Day-part switching matters for LED in particular, because a cabinet running at full brightness in a dark lobby is uncomfortable and wastes power.
Triggers extend the schedule beyond the clock. A trigger can fire a playlist from a sensor, a point-of-sale event, a calendar feed or a manual override. Triggers are powerful but easy to leave undocumented, so every active trigger should be written down with its owner and its fallback state. An untriggered screen that nobody can explain is the most common scheduling fault in a mature network.
Design the schedule as a cycle, not a launch. Operators who rotate a new hero clip each month and keep a set of evergreen brand loops in between rarely have an empty screen, whereas a network built around a single campaign goes stale the day the campaign ends. The content scheduling guide covers day-parting and refresh cycles in more depth.
Video walls and clustered screens must play in frame-accurate sync, which means the players have to be time-locked rather than simply started together. Systems that lack time-locking produce a visible tear across cabinet boundaries that no amount of hardware alignment can fix. Sync is one of the few software features that has no workaround, so it should be verified with a test pattern before a wall goes live.
Synchronisation also affects how content is authored. A moving object that crosses a seam has to be positioned in one master file that the players slice between them, not assembled from separate files per cabinet. When sync and file structure are planned together, a large wall behaves as one canvas; when they are not, the same wall betrays every join on every fast pan.
Refresh rate is the number of times per second the screen redraws the image. A low refresh rate is invisible to the eye but appears as moving dark bands on a phone or broadcast camera. Any screen that will be filmed should use a high refresh rate and be tested with the actual camera and shutter speed before an event, because the setting that looks perfect live can still band on camera.
Grayscale processing determines how many brightness steps the driver can produce. Low grayscale makes a fade look like a series of visible jumps and makes dark areas band. High grayscale, combined with high refresh, keeps gradients smooth and gives slow motion a clean look. Content motion should respect the panel too: very fast cuts and strobing effects look aggressive on a bright wall and are harder for a camera to resolve.
Colour management closes the loop. Content authored in a standard colour space should be mapped to the screen calibration so brand colours look correct, and every screen across a network should share one calibration target, otherwise the same logo looks slightly different on each wall. Always test on the real screen: a proof on a desktop monitor tells you almost nothing about how content reads on a bright LED wall at the intended distance.
The most common operational failure in a signage network is not a hardware fault: it is a screen running the wrong file because nobody knew which version was current. A predictable folder structure, consistent codecs and a written naming rule prevent this before it happens. Version the media the way you version software, with a clear current release and dated archives.
Approvals turn version control into governance. An approval step between the person who builds content and the person who publishes it keeps a network consistent across sites and stops an un-reviewed file from appearing on a public screen. Where several stakeholders share a screen, agree in advance who holds final sign-off, because a workflow with two approvers and no tie-breaker stalls at the worst moment. The version control guide sets out a naming and approval scheme that scales.
Non-technical staff can run a network safely, provided the platform supports role-based permissions and templates. Restricting users to approved layouts prevents accidental layout breaks, and scheduled publishing plus an approval step keeps every site on message. The goal is to let a store manager update a price without letting them accidentally move a logo off the safe area.
Templates are what make that possible. Once a layout is designed, staff update the text, images and prices inside it, and a designer is needed only for a new campaign concept rather than for routine maintenance. Treat the template as a product with its own owner and change history, not as a disposable file, because every screen in the network inherits its rules.
Cloud systems allow updates from anywhere and simplify managing many sites, while on-premise systems keep all media inside your own network. Most commercial networks choose cloud for reach, and on-premise where the content is sensitive or connectivity is unreliable. The decision is less about software fashion than about where the operator physically is and how much the network can tolerate being offline.
Whichever model you pick, insist that the player caches content locally. A dropped connection should never blank a screen; the player should keep running its last downloaded schedule and resynchronise when connectivity returns. Local caching is the single design choice that turns a network outage from a black screen into a non-event.
| Consideration | Cloud CMS | On-premise |
|---|---|---|
| Updating content | From anywhere with a connection | From inside the own network |
| Content control | Media held by the platform provider | All media stays on site |
| Network dependency | Benefit falls away when offline | Keeps running without internet |
| Best fit | Many dispersed sites, small local teams | Sensitive content or unreliable links |
A single screen is a project; a fleet is a system. Standardising on one content platform and one playback tier across a mixed fleet is what keeps a network cheap to run, because operators learn one interface and spare players are interchangeable. Standardising the pixel-map templates across sites matters just as much, since a campaign that runs everywhere should be built once and distributed, not rebuilt per site.
Roll out in phases. Bring a pilot site live, confirm the content path from design to playback, then replicate the configuration as a documented standard. Networks that grow site by site, each configured slightly differently, accumulate hidden inconsistency that surfaces as support calls years later. Buyers planning a retail rollout can weigh the practical requirements in the retail digital signage guide and the market-specific notes in the digital signage buyer's guide.
Most outages are not exotic. They fall into a short list that recurs across otherwise well-built networks, and almost all of them are cheaper to prevent at design time than to diagnose at 2am. The patterns below are the ones worth writing into the operations runbook before the screen goes live.
| Symptom | Likely cause | First response |
|---|---|---|
| Screen stuck on an old clip | Player frozen or last upload never completed | Check player status remotely, reboot, re-push the schedule |
| Wrong version playing | No naming rule; two files share a name | Adopt versioned filenames and one master folder |
| Dark bands on camera | Refresh rate clashing with the camera shutter | Raise refresh and re-test with the actual camera |
| One cabinet looks dim or wrong | Module, power or calibration drift | Display a grey ramp and white slide to isolate it |
| Visible tear across a wall | Players not time-locked | Enable frame-accurate sync, not a simultaneous start |
| Black screen after a network drop | No local content cache on the player | Enable local caching and last-known-schedule playback |
Build a test pattern set alongside the creative and keep it on every player: a full white slide, a full black slide, a grey ramp and a set of colour bars. When a cabinet looks wrong, a grey ramp immediately shows whether the fault is a dead module, a dim cabinet or a colour calibration issue, and it saves a service visit. The set costs nothing to make and pays for itself the first time a screen develops a fault in the middle of a campaign.
Software support differs from hardware support, and buyers should be clear about which one they are purchasing. Hardware is covered by the panel maker's warranty on modules, power supplies, receiving cards and cabinet structure; software features, updates and licensing are governed by the platform vendor's own terms. The practical question is where the boundary sits, because when a screen fails to display the content it was sent, the cause could be the player, the network, the receiving card or the platform.
A supplier who can diagnose across that boundary saves the buyer from being passed between vendors, which is the most common frustration in signage support. Asia Vision Technology, an LED display manufacturer based in Shenzhen, China, manufactures SMD and GOB as well as COB products on its own production lines, runs 8 IC production lines and 7 LED SMT production lines, and has its COB range at P0.93 in mass production. That in-house control over the hardware side is what lets the content path be verified at commissioning rather than guessed at later. You can review the production setup on the factory page and the fine-pitch options on the COB CV-PRO page.
Documentation matters here as much as in any other part of the system. Network topology, player configuration and cabinet addressing should be recorded and kept with the installation, because the person who commissions the network is rarely the person who maintains it. Cabinet customisation, ageing tests, QC and export delivery are part of the hardware programme; see the full product range for how the lines map to different content roles, and reach the team through contact with your pixel map in hand.
Commissioning is the last cheap moment to catch a content problem. Once the screen is public, every fault is an audience-facing fault. Work through the list below with the actual creative on the actual screen, not with a test clip that everyone knows plays well.
The content layer and the display are one decision, and the projects that run smoothly are the ones where the pixel map, the pitch, the viewing distance and the playback tier were agreed before the order was placed. A screen specified in isolation becomes a screen whose content never quite fits, and the gap is expensive to close after the cabinets are on the wall.
Bring the content brief to the hardware conversation. If you know what will run on the screen, the pixel dimensions, the refresh requirement and the playback tier follow naturally, and the commissioning checklist turns from a wish list into a weekend's work. That is the whole argument of this guide: on an LED display, the software is not an accessory to the panel, it is the other half of the system.
For this requirement our range covers it directly: the X Series (front/rear service, common parts across platforms) and the series overview for spare-part lists.