A SMIL digital signage player builds its show from a SMIL file, an open W3C playlist standard, instead of a vendor app or cloud account. The file sets zones, order and timing in plain XML, so one index runs on any player that implements the standard and the show plays with no account. It fits offline and technician-run signs; daily editing by non-technical staff calls for an app-built or cloud player.
A SMIL digital signage player is a player that takes its playlist from a SMIL file: an open W3C standard that spells out, in plain XML, which media plays in which zone of the screen, in what order, and for how long. The player reads that file, fetches the media it names and runs the show on the device, with no cloud account and no vendor-owned playlist format. Because the format is a published standard, one index can drive any player that implements it, which is why SMIL keeps turning up in technician-run installs, offline screens and mixed fleets. It is the wrong tool when content changes daily and the people making the changes need a drag-and-drop app; there, an app-built or cloud player is the better buy.
What SMIL is
SMIL stands for Synchronized Multimedia Integration Language. It is a recommendation of the W3C, the body that publishes the web's core standards: the first version appeared in 1998, and SMIL 3.0, published in 2008, is the version in force today. The language describes a complete presentation: text, images, video, audio, links to other SMIL presentations and files served by several different web servers can all appear in one show.
It helps to fix what SMIL is not. SMIL is not a codec, so it says nothing about how a video is compressed. It is not a screen, a network protocol or a content editor. It is the playlist layer between them: a small text file in XML, readable in any text editor, which the signage trade usually calls the index.
A SMIL player is any device or app whose playback engine reads an index and renders what it describes. The engine does the hard work: decoding the media, scaling it into the zones the layout defines and holding the timing the markup sets.
How the markup describes a show
The index separates layout from timing, and each half is a short list of elements.
Layout. A root-layout element fixes the canvas size in pixels, for example 1920 x 1080. Each region element defines one zone with left, top, width and height values. A fit attribute on the region decides what happens when a piece of media and the zone have different shapes: meet scales the media down until it fits inside and leaves bars, slice fills the zone and crops the overflow, fill stretches the media out of shape to cover the zone.
Timing. Children of a par element play at the same time, which is how zones run side by side. Children of a seq element play one after another, which is how a loop of slides works. A dur attribute sets a duration in seconds, such as dur="10s", and repeatCount="indefinite" tells the player to keep the block looping. The timing language also accepts clock values as start times, so the markup can hand over from a morning playlist to an evening one at a set hour, computed on the device.
Media paths. The show names its files by path or URL, and the standard allows media from multiple web servers in one presentation. Slides can come from a memory card, video from USB storage and a text feed from your own web server, all listed in one index.
Worked example: zoning a 1920 x 1080 screen
Inputs. The canvas is 1920 x 1080 px, landscape: the native size of a standard full-HD panel, and the case this article follows. The show carries one 16:9 video of 1920 x 1080 px, one headline column and one text strip. The canvas is the fixed fact; the region sizes are this example's choices, and the arithmetic below checks them.
Rule in words. Set root-layout to the panel's native pixels. Give every region a left, top, width and height in pixels, keep the regions inside the canvas and out of each other's way, and shape every video region like the video it will hold, because meet and slice only manage the damage once the shapes disagree.
Arithmetic.
- Video region: left 0, top 0, width 1280 px, height 720 px. Shape check: 1280 / 1920 = 0.667 and 720 / 1080 = 0.667, the same 16:9 shape, so the video fills the zone edge to edge with no bars and no crop.
- Text strip: left 0, top 720, width 1280 px, height 360 px. Height check: 720 + 360 = 1080, so the strip closes to the bottom edge.
- Headline column: left 1280, top 0, width 640 px, height 1080 px. Width check: 1280 + 640 = 1920, so the three zones tile the full width with no gap and no overlap.
- Cost of a mismatch: put the same video in a 1280 x 1080 zone instead. Scaled to fit the 1280 px width it stands 720 px tall, so meet leaves 1080 - 720 = 360 px of bars, 180 px above and 180 px below, and slice fills the 1080 px height but crops 1920 - 1280 = 640 px off the picture's width.
Result. Three regions tile the 1920 x 1080 canvas exactly: video 1280 x 720 px, strip 1280 x 360 px, column 640 x 1080 px, with the 16:9 video sitting in a matching 16:9 zone.
Decision. Shape each video region like its video and nothing is lost; once the shapes disagree, meet adds bars and slice crops, in proportion to the mismatch, here 360 px of height or 640 px of width. Use meet when no pixel of the picture may be lost, slice when the zone must look full and cropped edges are acceptable. Text zones take whatever shape is left over, because the player renders text at playback, while video is fixed pixels.
When a SMIL player fits
| Situation | Does a SMIL player fit? |
|---|---|
| Sign runs offline with no account | Yes: index and media live on a memory card, USB storage or a server on your own network |
| Someone technical can own an XML file | Yes: a content change is a file edit |
| The fleet mixes player hardware | Yes: one standard index serves every player that implements the same profile |
| The screen needs timed zones | Yes: regions and par timing exist for exactly this |
| Staff edit content daily and want drag and drop | No: an app-built or cloud player gives them editing and previews |
| You want dashboards and fleet-wide remote updates | Not from the file alone: management platforms for SMIL fleets exist, self-hosted or paid, layered on top |
The underlying choice is the offline-versus-cloud question, and offline or cloud signage: how to choose walks through it. For the wider software map, free digital signage software: freemium, open source or DIY sorts the options, and SMIL players are the open-standard corner of that map.
What it changes on a real sign
Content files. The index names files by path, so keep file names short, lowercase and free of spaces, and keep every file it names where the paths point: the card, the USB storage or your server.
Resolution and orientation. Set root-layout to the panel's native pixels and to the way the screen hangs. When size or orientation disagree, the faults are specific: a portrait show on a player that scales wrong can come up as a quarter-size thumbnail, covered in why a 4K portrait signage player shows a quarter of the layout, and some players report a framebuffer size that disagrees with the panel, covered in why a portrait signage player reports a 720p framebuffer. Check both against the player's documentation before you write the layout.
Starting up. A sign nobody tends should come up straight into the show after power returns. The autostart recipe is the same idea across players: set up offline playlist autostart on a signage screen walks through one, and a locked-down signage player build shows the pattern carried down to the hardware.
Readability. Readability is a viewing-distance question; the zone's pixel width only decides how much text fits. The FHWA planning figure is 30 ft of viewing distance per inch of capital letter height, and 20 ft per inch when people must read fast. The 640 px side column from the example carries headlines read from across a counter; a sign read from across a 30 ft lobby needs capitals around 1 in tall on the panel, which a narrow column rarely holds.
Where you see it. Zone layouts appear wherever one screen must carry a video, a price list and a message at the same time: above counters, in elevator lobbies, at reception desks. Our pages on elevator screens that play with no signal and digital menu boards with no monthly fee cover the hardware side of those two places.
Quoting our screens. If a SMIL project lands on our hardware, put SMIL support in the requirements when you ask; a quoted model's software is confirmed in its quote. The player included with the panel-mount series builds shows in its own app and can pull a playlist from your own web server on a timer; that playlist is the app's own format, not SMIL.
The decision
Recommendation: Choose a SMIL player when the sign must run with no account, someone technical can own the index file and the fleet may mix player hardware. Write the index to SMIL 3.0, set root-layout to the panel's native resolution and hanging orientation, give every video region the same shape as its video, and keep media to H.264 MP4 with JPG or PNG slides, the pairing nearly every player decodes. Choose an app-built or cloud player instead when content changes daily and non-technical staff make the changes; there the editing workflow decides the purchase, and the playlist format is a detail.
Questions
Can a SMIL player box drive one of your screens over HDMI?
No on the panel-mount series: its HDMI port is an output, so the unit drives another screen and does not take a video input. A SMIL player box pairs with a screen that accepts an input, such as a TV or a commercial monitor. On a current-range model, ports are confirmed in the quote.
Which media formats work in a SMIL show?
The index only names files, so decoding is the player's job and the player's codec list is the authority. H.264 MP4 video with JPG or PNG slides is the pairing most players decode; heavier codecs such as H.265 or VP9 depend on the hardware. Test one file on the player you own before you cut a whole show.
Is SMIL the same as HTML5 signage?
No. SMIL is a timing and layout description that the player's engine executes, while HTML5 signage is a web page that a browser on the device renders. SMIL brings a portable file-based playlist with zones and timing; HTML5 brings app-like interactivity and live data. The two can sit side by side in one building on different devices.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.