Meine erste Digital-Signage-Erfahrung hatte ich Ende der 90er in ein paar Discotheken, in denen ich auflegte und nebenbei IT-mäßig aushalf. Seit 2012 betreibe ich eine eigene Firma, inzwischen mit einem kompletten Open-Source-Stack.
Bei Digital Signage geht es darum, Informationen über Bildschirme anstatt über Papier zu verbreiten. In den 90ern und frühen 2000ern gab es meistens Einzelplatzinstallationen, manche nutzten gar PowerPoint. Inzwischen dominieren zentral administrierbare Netzwerke und eine unglaublich hohe Anzahl an SaaS-Lösungen.
Die Branche ist extrem vertriebsorientiert und es gibt kaum bekannte Tech-Nerds oder Influencer. Fachpodcasts und Branchenmedien existieren, aber meist Werbe- und sponsoringfinanziert. Eine kritische technische Auseinandersetzung findet dort eher nicht statt.
Entsprechend wird alles dafür getan, Kunden so eng wie möglich zu binden. Mediaplayer und CMS kommunizieren miteinander, aber die Kommunikationssprache ist in der Regel proprietär. SaaS macht es obendrein noch intransparenter. Wir haben also eine Branche mit klassischem Vendor-Lock-in und all den nachteiligen Konsequenzen für die Kunden: Cloud-Zwang, monatliche Abrechnung, langfristige Bindungen mit hohem Investitionsrisiko, Wechselkosten und so weiter.
Der Markt ist zugleich stark fragmentiert. Kleinere Anbieter wie Agenturen scheuen die Kosten und bauen lieber eigene Software anhand konkreter Kundenanfragen. Jeder erfindet das Rad neu und glaubt dann, selbst etwas vom SaaS-Kuchen abzubekommen.
Das wäre Stoff für eine antike griechische Tragödie. Die Großen wollen keinen Standard, weil er ihre Kunden befreien würde. Die Kleinen bauen lieber ihr eigenes Ding und wissen noch nicht mal, dass es was gibt. Eine Lobby für einen gemeinsamen Standard gab es deshalb nie ernsthaft.
Dabei existiert er seit über 25 Jahren: SMIL, seit 2008 stabil in Version 3.
Was ist SMIL?
SMIL ist seit 1998 ein W3C-Standard für die Synchronisierung von Medieninhalten. Version 2.0 brachte eine Modularisierung, die es erlaubt, nur einzelne Teile wie das Timing-Modul in andere Formate zu übernehmen, statt die komplette Spezifikation zu implementieren. Deshalb findet man SMIL an unerwarteten Stellen.
Es wird für MMS genutzt, um mehrere Medien zeitlich zu koordinieren. Bild, dann Ton, dann Text. Bei der inzwischen nicht mehr existierenden HD-DVD steuerte SMIL innerhalb der Interaktivitäts-Schicht HDi die zeitliche Synchronisation von Menüs und Zusatzinhalten mit dem Hauptfilm. Auch E-Books im EPUB-3-Format nutzen SMIL, um vorgelesenen Text mit Audio zu synchronisieren.
Leider wurde es für etwas bekannt, was nur ein Bruchteil des Standards ausmacht: SVG-Animation im Browser.
Was es tatsächlich kann, ist allerdings deutlich mehr als eine Slideshow. Es ist eine deklarative Sprache, in der man beschreibt, was wann passieren soll, statt es zu programmieren.
Zeitachsen
Elemente laufen sequenziell nacheinander oder parallel nebeneinander ab, je nachdem, welche Container direkte Eltern sind.
Trigger und Bedingungen
Inhalte lassen sich an eine Uhrzeit koppeln, an ein Datum, an das Ende eines anderen Elements oder an einen Klick respektive Touch auf ein Medium. Ohne eine Zeile Programmcode zu schreiben.
Regionen / Zonen
Das sind überlappbare Flächen auf dem Bildschirm, denen man Inhalte zuweist. Ein Layout lässt sich aus mehreren Bereichen bauen: ein Videofeld in der Mitte, ein Textticker unten, ein transparentes Sendelogo darüber und ein Touchfeld rechts, über das sich die Inhalte ändern lassen.
Und wozu das Ganze?
Wenn der Player den Standard spricht, ist die Quelle austauschbar, egal ob Digital-Signage-CMS, Authoring-Tool, WordPress-Plugin oder eine handgeschriebene Datei im Texteditor. So einige HTML-Seiten entstehen noch heute im Texteditor.
Das Markup
Kommen wir zu ein paar kleinen Praxisbeispielen, damit wir nicht nur bedeutungsschwanger theoretisieren.
Der Header und das Layout
Die SMIL-Struktur ähnelt auf den ersten Blick HTML. Es existiert ein <head>-Bereich für Meta-Tags sowie Instruktionen und ein <body>-Bereich für Inhalte. Die wichtigste Sektion im Header ist das <layout>-Tag. Hier definiert <root-layout>in Pixeln den absoluten Bereich der Präsentation.
Wir gehen im folgenden Beispiel von einem HD-fähigen Bildschirm mit einer Auflösung von 1920 × 1080 Pixeln aus. Als Nächstes definieren wir die Regionen (Zonen) mittels <region>. Dort lassen sich sowohl Pixel- als auch Prozentangaben nutzen. Im Beispiel sehen wir eine Region, die links oben bei der Koordinate 0 anfängt und sowohl 100 % Breite als auch 100 % Höhe des zugewiesenen Layouts einnimmt.
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<smil xmlns="http://www.w3.org/ns/SMIL" version="3.0" baseProfile="Language">
<head>
<meta name="title" content="Einfaches SMIL" />
<layout>
<root-layout width="1920" height="1080" />
<region regionName="Zone 1" top="0" left="0" width="100%" height="100%" z-index="0" backgroundColor="#CCCCCC" />
</layout>
</head>
<body>
<!-- Inhalte -->
</body>
</smil>Bei nur einer Zone kann man auf <region> verzichten. Hier bietet sie aber eine schöne Überleitung zum Multizonen-Layout, einer der großen Stärken von SMIL für Digital Signage.
Wir fügen nun eine weitere Region hinzu und legen diese mit dem Attribut z-index="1" über Zone 1. In Zone 2 ließe sich beispielsweise ein Sendelogo platzieren.
<layout>
<root-layout width="1920" height="1080" />
<region regionName="Zone 1" top="0" left="0" width="100%" height="100%" z-index="0" backgroundColor="yellow" />
<region regionName="Zone 2" top="3%" left="4%" width="10%" height="12%" z-index="1" backgroundColor="transparent" />
</layout>Aussehen würde das auf dem Bildschirm in etwa so:
Inhalte im Body
Ohne Inhalte ergibt eine Präsentation wenig Sinn. Bei SMIL unterscheiden wir zwischen Containern und Medienobjekten. Container bestimmen, wann und in welcher Reihenfolge etwas abgespielt wird, Medienobjekte sind die eigentlichen Inhalte.
Es existieren drei Container:
- <seq> Inhalte dieses Containers werden sequenziell abgespielt.
- <par> Hier werden die Inhalte parallel abgespielt.
- <excl> Dieser Container spielt nur jeweils einen Inhalt ab. Er eignet sich für Priorisierungen und triggergesteuertes Abspielen.
Die wichtigsten Medienobjekte sind:
- <img> Zeigt ein über das src-Attribut verlinktes Bild an und benötigt ein
dur-Attribut, um die explizite Anzeigedauer festzulegen. - <video> Videos benötigen keine explizite Anzeigedauer, weil sie eine intrinsische (eigene) Dauer haben.
- <audio> Für Tondateien wie mp3, wav usw.
- <ref> Ein allgemeines Tag, das über das
type-Attribut jedes andere Medienobjekt abbilden kann. Es nimmt eine wichtige Sonderstellung ein, weil sich darüber Webseiten und sogenannte Digital-Signage-Widgets anzeigen lassen. Widgets sind HTML5-Apps, die direkt auf dem Player laufen.
Es gibt noch weitere Medienobjekte wie <brush>, <text> und das mit SMIL 3.0 hinzugekommene <smilText>. In Digital-Signage-Lösungen spielen sie aber in der Regel keine Rolle. Wie eingangs erwähnt: Bei SMIL nimmt sich jeder, was er braucht.
Hier ein paar konkrete Beispiele für den <body>-Bereich:
Der Loop
<seq repeatCount="indefinite">
<img src="angebot-1.jpg" dur="10s" />
<video src="lustiges-video-1.mkv" soundLevel="0%"/>
<img src="angebot-2.jpg" dur="10s" />
<ref src="https://server/webseite.wgt" type="application/widget" dur="15s"/>
<video src="lustiges-video-2.mkv" soundLevel="0%"/>
</seq>Das ist die wohl typischste aller Playlisten und deckt den Löwenanteil der einfachen Digital-Signage-Anwendungsfälle ab.
Fünf Medienobjekte stecken in einem seq-Container und laufen brav nacheinander ab. Stellen wir uns vor, wir stehen an der Supermarktkasse in einer kleinen Schlange (gefühlt immer die langsamste) und warten, bis wir dran sind. Zuerst sehen wir 10 Sekunden lang ein Angebot, dann ein unterhaltsames Video ohne Ton, danach wieder 10 Sekunden Werbung, die neue animierte Webseite des Supermarkts und zum Schluss noch ein Video.
Dank repeatCount="indefinite" läuft die Playliste in einer Schleife bis ans Ende aller Tage.
Ich höre gerade: „Moment mal, bis auf die Webseite kriegt das auch der VLC-Player mit einer Playlist hin.“ Stimmt. Für eine Diashow mit ein paar Videos braucht niemand einen W3C-Standard. Also legen wir eine Schippe drauf und bringen Verschachtelung und paralleles Abspielen ins Spiel. Ab hier wird es für einen klassischen Mediaplayer nämlich eng.
Paralleles Abspielen
<par>
<seq begin="5s" repeatCount="indefinite">
<img region="Zone 1" src="angebot-1.jpg" dur="10s" />
<video region="Zone 1" src="lustiges-video-1.mkv" soundLevel="0%" />
<img region="Zone 1" src="angebot-2.jpg" dur="10s" />
<ref region="Zone 1" src="https://server/webseite.wgt" type="application/widget" dur="15s" />
<video region="Zone 1" src="lustiges-video-2.mkv" soundLevel="0%" />
</seq>
<img begin="0" region="Zone 2" src="sendelogo.png" dur="indefinite" />
<seq begin="0" repeatCount="indefinite">
<audio src="audio/ambient-1.ogg" soundLevel="100%" />
<audio src="audio/ambient-2.ogg" soundLevel="100%" />
</seq>
</par>Das <par>-Tag sorgt dafür, dass alle Inhalte gleichzeitig abgespielt werden. Der Container hat drei Kindelemente: die Playliste aus Beispiel 1, das Sendelogo und eine Hintergrundmusik. Alle drei laufen endlos. Die beiden seq-Container drehen sich in einer Schleife, und das Sendelogo bleibt dank dur="indefinite" einfach stehen.
Standardmäßig starten in einem <par> alle Elemente gleichzeitig. Das Attribut begin="0" beim Sendelogo und beim Ambient-Container ist also eigentlich überflüssig. Mit begin legt man fest, wann ein Element startet, hier einfach abhängig von der Zeitleiste. Um das zu verdeutlichen, habe ich den Start der Playliste auf 5s gesetzt. Musik und Sendelogo laufen also sofort los, die visuelle Präsentation folgt fünf Sekunden später.
Statt einer festen Zeit kann begin aber auch einen Trigger aufnehmen: eine Uhrzeit, einen Touch oder das Ende eines anderen Elements.
Trigger
Machen wir es noch einen Tick komplexer und setzen Prioritäten.
<par>
<img region="Zone 2" src="sendelogo.png" dur="indefinite" />
<excl>
<priorityClass peers="stop">
<video region="Zone 1" src="happy-hour.mp4" begin="wallclock(R7/2026-10-02T17:00:00/P1D)" />
</priorityClass>
<priorityClass higher="pause">
<seq begin="0" repeatCount="indefinite">
<img region="Zone 1" src="angebot-1.jpg" dur="10s" />
<video region="Zone 1" src="lustiges-video-1.mkv" soundLevel="0%" />
<img region="Zone 1" src="angebot-2.jpg" dur="10s" />
<ref region="Zone 1" src="https://server/webseite.wgt" type="application/widget" dur="15s" />
<video region="Zone 1" src="lustiges-video-2.mkv" soundLevel="0%" />
</seq>
</priorityClass>
</excl>
</par>Was passiert hier?
Unsere bekannte Playliste läuft ganz normal in Zone 1 parallel zum Senderlogo. Ab dem 2. Oktober 2026 wird sie sieben Tage unterbrochen und ein Happy Hour an der Frischetheke angekündigt. Dank higher="pau wird die Playliste nur angehalten und läuft nach dem Video genau an der Stelle weiter, an der sie unterbrochen wurde.
Wichtig: Kinder eines <excl> starten standardmäßig nicht von selbst. Der Defaultwert hierbei ist begin="indefinite". Deshalb braucht die Playliste ein explizites begin="0". Über <priorityClass> legt man fest, wer wem den Vortritt lässt. Die erste Klasse, also von oben nach unten, besitzt die höchste Priorität, und higher="pause" sorgt dafür, dass die Playliste bei einer Unterbrechung nur angehalten wird.
Die Wiederholung mit R7/…/P1D stammt zwar aus ISO 8601, gehört aber nicht zum SMIL-Standard. SMIL übernimmt von ISO 8601 nur Datum und Uhrzeit. Die Signage-Player haben die Intervalle nachgerüstet.
Ich denke, die drei Beispiele reichen erst mal, um zu zeigen, wie mächtig SMIL sein kann. Vor allem, wenn man bedenkt, dass das erst der Anfang ist. Wer tiefer einsteigen will, dem empfehle ich die offizielle W3C Dokumentation. Etwas praxisnäher und mit Fokus auf Digital Signage habe ich außerdem ein SMIL-Tutorial auf meiner Webseite.
Womit Ausprobieren?
Einige Hardwareplayer, zum Beispiel von IAdea, sprechen SMIL nativ, jeweils mit eigenen Erweiterungen. Auf diesem Dialekt baut auch der quelloffene SMIL-PLayer von signageOS auf, der allerdings an deren Plattform gebunden ist. Transparenzhinweis: Ich entwickle selbst einen Open-Source-Player namens garlic-player.
Wo SMIL nichts taugt
Eine deklarative Sprache ist allerdings kein Allheilmittel. Es gibt Anwendungen, bei denen SMIL an seine Grenzen stößt. Dynamische Inhalte, die sich aufgrund von Ereignissen ständig ändern, lassen sich damit oft nur umständlich und wartungsintensiv umsetzen.
Nehmen wir den Klassiker: Fluginformationssysteme (FIDS). Mit Triggern, viel Skripting und noch mehr Kompromissen bekommt man das zwar in purem SMIL hin, aber für solche dynamischen Anwendungen gibt es deutlich bessere Werkzeuge. Moderne FIDS setzen auf HTML5, JavaScript und API-Anbindungen. Und genau so eine Anwendung lässt sich bequem in SMIL einbetten, statt sie mühsam damit nachzubauen.
Entweder als Webseite oder, noch eleganter wie oben erwähnt, als HTML5-Widget. Die Anwendung läuft dann lokal auf dem Player, holt sich ihre Daten aus dem Netzwerk und lässt sich unabhängig verwalten sowie aktualisieren. SMIL ist dann nur noch die Infrastruktur drumherum: Es platziert die Anwendung, steuert sie, sorgt für Updates oder blendet Notfallinformationen als Overlay ein.
Jetzt könnte man fragen: Dann kann ich doch gleich alles in JavaScript machen?
Ignorieren wir mal, dass ein Webbrowser kein Medienplayer ist und erst recht nicht für autonom ablaufende, remote verwaltbare Anwendungen konzipiert wurde.
Ja, das kann man. Man baut dem FIDS ein eigenes Scheduling, eine eigene Update-Logik und einen eigenen Player drumherum, der weiß, wann was auf dem Bildschirm läuft. Nur landet man damit genau dort, wovon der ganze Artikel handelt: bei einem Format, das nur der eigene Player versteht und sonst niemand.
Willkommen in der proprietären JSON-Variante dessen, was SMIL seit über 25 Jahren kann.
Fazit
Der Standard ist da. Er ist offen dokumentiert, seit Jahrzehnten stabil und deckt fast alles ab, was Digital Signage im Alltag braucht. Was fehlt, sind offen zugängliche Implementierungen. Nur eine Handvoll Player spricht offiziell SMIL, und die meisten davon sind an eine Hardware oder Plattform gebunden. Allein vier meiner Reseller haben sich in den letzten 13 Jahren eigene SMIL-Player geschrieben. Öffentlich ist davon keiner. Der Rest der Branche hat sich stattdessen für unzählige eigene Formate entschieden. Jedes davon bindet Kunden an genau einen Anbieter.
Dabei wäre der Weg raus gar nicht kompliziert. Wenn CMS SMIL ausliefern und Player SMIL verstehen, lassen sich beide Seiten unabhängig voneinander austauschen. Dann entscheidet wieder der Kunde, womit er arbeitet, und nicht der Vertrag.
Dass das bisher nicht passiert ist, liegt nicht am Standard, sondern an fehlenden Anreizen. Offene Software braucht diese Anreize nicht. Sie muss nur da sein und funktionieren. Vielleicht ist das die Chance, die SMIL in über 25 Jahren noch nicht hatte.
Das Titelbild wurde mit KI erstellt.
