Wie sich Live-Daten automatisch in teilbare Videos umwandeln lassen

• Es wurde ein webbasierter Workflow aufgebaut, um Live-Daten, die alle paar Tage aktualisiert werden, ohne manuelle Bearbeitung jedes Mal in Social-Videos umzuwandeln
• Die Quelle des Videos ist keine Schnittdatei, sondern eine versteckte Webseite; Playwright steuert den Browser Bild für Bild und ffmpeg setzt alles zu MP4 und GIF zusammen
• Ein kurzes storyboard.ts und ein einzelner Playhead formen aus den heutigen Zahlen, Fades, dem Startpunkt im Dezember 2024 und einem 18-monatigen Wachstumsabschnitt einen Clip von etwa 14 Sekunden
• Eine geplante GitHub Action erkennt Datenänderungen, baut und deployt die Seite neu und erzeugt 4 Fassungen für verschiedene Seitenverhältnisse und Sprachkombinationen, die auf einem CloudFront-CDN veröffentlicht werden
• YouTube erlaubt Uploads als nicht öffentliche Entwürfe, Instagram unterstützt dagegen nur sofortige öffentliche Veröffentlichungen, daher bleibt ein menschlicher Freigabeschritt für die Endkontrolle und das Bearbeiten der Captions bestehen

---

Eine Architektur, in der die Webseite als Videoquelle dient

• Das Video startet nicht aus einem separaten Schnittprojekt, sondern auf einer versteckten Spezialseite innerhalb der Website
• Diese Seite ist auf das vertikale 9:16-Format ausgelegt, das für Reels, Shorts und TikTok verwendet wird
• Auf dem Bildschirm werden vorhandene Elemente der Live-Website wiederverwendet
  • Überschrift
  • große Institutionszahl
  • animiertes Diagramm
  • landesweite Karte
  • kleine Credit-Zeile
• Verwendet werden Timeline-Animationen und Motion-Effekte des Webbrowsers, während ein Computer einen für Nutzer unsichtbaren Headless-Browser steuert
• Wie eine normale Webseite lässt sich die Seite direkt im Browser öffnen, vor- und zurückspulen sowie zur Vorschau und zum Debugging nutzen
• Sie übernimmt direkt das mehrsprachige Framework der Website, sodass Videos für jede unterstützte Sprache erfasst werden können
• Die Asset Bakery, die Datenpipeline und das Frontend dieses Projekts sind als Open Source veröffentlicht

storyboard.ts und der Playhead

• Eine einzige Datei, storyboard.ts, definiert Timing und Übergänge des Videos wie eine Shot-Liste der Regie
• Die Struktur besteht aus einigen benannten Beats und ihren Laufzeiten
  • den heutigen Gesamtwert 1,5 Sekunden halten
  • 0,7 Sekunden Fade
  • den Startpunkt der Daten im Dezember 2024 1,5 Sekunden halten
  • danach 18 Monate Wachstum vorwärts abspielen
  • wieder auf dem heutigen Bildschirm landen
• Das gesamte Ergebnis ist ein Clip von etwa 14 Sekunden
• Das Zeichnen des Diagramms, Punkte auf der Karte und das Hochzählen des Counters sind an einen einzigen Playhead gekoppelt
• Der Playhead sorgt dafür, dass bei einem bestimmten Timestamp alle Komponenten denselben Zustand rendern, damit die Bildelemente nicht auseinanderlaufen

Frame für Frame „backen“

• Die eigentliche Videodatei entsteht, indem die Webseite in einem Headless-Browser geöffnet und Chromium mit Playwright gesteuert wird
• Anfangs lag die Annahme nahe, man könne virtuell auf Play drücken und per Bildschirmaufnahme erfassen, doch Echtzeitaufnahmen konnten zu ausgelassenen Frames oder Rucklern führen
• Dasselbe Video konnte lokal flüssig laufen und sich auf Cloud-Hardware anders verhalten; in frühen Experimenten spielte es teils sogar unnatürlich schnell ab
• Für stabilere Ergebnisse werden statt Echtzeitaufnahmen die Frames einzeln wie in einem Daumenkino erzeugt
  • der Seite sagen: „Zeig mir den Zustand bei 0,04 Sekunden“
  • einen Screenshot machen
  • zu 0,08 Sekunden wechseln und erneut einen Screenshot machen
  • diesen Vorgang hunderte Male wiederholen
• Da der Ablauf wie beim manuellen Umblättern einer eingefrorenen Seite voranschreitet, wird jedes Bild vollständig gerendert erfasst
• Das Ergebnis ist deterministisch und testbar; bei zwei Durchläufen sollten überprüfbar identische Frames entstehen
• Verdoppelt man die Zahl der Frames, verdoppeln sich ungefähr auch Rechenzeit und Speicherbedarf für das Rendering

Details zur Stabilisierung des Server-Renderings

• Die landesweite Karte verwendet MapLibre GL JS und rendert normalerweise mit WebGL-Code, der eine GPU voraussetzt
• Auf dem Server gibt es keine GPU, daher wird Chromium so konfiguriert, dass es Software-Rendering nutzt
  • langsamer als echte Grafik-Hardware
  • läuft auf fast allen Plattformen mit derselben Qualität
• Jeder Frame wird nicht als PNG, sondern als JPEG gespeichert
  • bei Screenshots ist PNG-Encoding der langsame Teil
  • das fertige Video sieht gleich aus, wodurch sich über hunderte Frames ein Geschwindigkeitsvorteil ergibt
• Damit der Headless-Browser in einem Container auf einem Bare Server stabil läuft, sind einige Flags nötig; die vollständigen Details stehen im öffentlichen Repository
• Die erzeugten hunderten Bilder werden mit ffmpeg zu MP4 und einer wiederholbaren GIF-Datei zusammengesetzt

Automatisierung auf Basis von GitHub Actions

• Der gesamte Prozess ist an eine automatische Datenpipeline gekoppelt, die von einer geplanten GitHub Action ausgeführt wird
• Mehrmals täglich wird geprüft, ob sich die Daten verändert haben
• Wenn neue Daten vorliegen, führt der Job Folgendes aus
  • Website neu bauen
  • Website neu deployen
  • 4 Fassungen für quadratisches/vertikales Format und Englisch/Spanisch erzeugen
  • auf dem CloudFront-CDN veröffentlichen
• Eine öffentliche Download-Seite bietet die neuesten Fassungen für jede unterstützte Sprache an
• Zum letzten Schritt gehören das Hochladen von YouTube-Entwürfen und Benachrichtigungen für Instagram-Posts
  • Das Script für YouTube heißt publish-social-youtube.mjs
  • Die Benachrichtigung zur Vorbereitung eines Instagram-Posts heißt notify-social-ready.mjs
  • Eine TikTok-Integration ist ebenfalls geplant

Die Grenze zwischen Automatisierung und redaktioneller Kontrolle

• Das Projekt schließt vollständige Automatisierung nicht aus, behält aber vor der Veröffentlichung jedes Videos eine menschliche Prüfung bei
• Redaktionelle Kontrolle über Überschriften und Captions, die Endkontrolle und die Entscheidung über die Veröffentlichungsart bleiben bei Menschen
• Da Eingabedaten fehlerhaft sein können oder das System falsche Ergebnisse erzeugen kann, wird blindes automatisches Posten vermieden
• YouTube erstellt über die offizielle API nicht öffentliche Videoentwürfe
• Die Instagram-API unterstützt nur sofortige öffentliche Veröffentlichungen; deshalb wird bei neuen Daten jedes Mal ein YouTube-Entwurf erstellt und eine E-Mail versendet, dass der Instagram-Post manuell angelegt werden soll

Social-Video-Produktion, die bei Webdesign endet

• Der Vorteil dieses Ansatzes ist, dass das Videodesign direkt zum Webdesign wird
• Er hängt nicht von After Effects, manuellem Re-Export, veralteten Zahlen oder überlasteten Web-Producern ab
• Änderungen an Farben oder Labels sind mit einer einzelnen Zeile erledigt und werden im nächsten Rendering übernommen
• Das gesamte System besteht aus ein paar hundert Zeilen Glue Code rund um bestehende Werkzeuge
  • Datenpipeline
  • Headless-Browser
  • Karten und Diagramme, die auf der Website ohnehin schon genutzt werden
  • ffmpeg
• Die Betriebskosten liegen bei wenigen Dollar pro Monat
• Als Vergleich wird das Missouri Vehicle Stops MCP genannt, das derzeit offenbar etwa 50 Dollar pro Monat kostet
• Die Asset Bakery hat niedrigere Kosten pro Nutzer als MCP, während MCP eher ein Werkzeug für tiefergehende Dateninteraktion ist

Strategie und die Rolle der „Abkürzung“

• Die Strategie besteht darin, mit automatisch erzeugten, hochwertigen Assets für das Teilen auf Mainstream-Plattformen präsent zu sein und zugleich moderne Datentools wie MCP für stärker involvierte Nutzer zu unterstützen
• Das Ziel ist weder ein viraler Zirkus noch ein unklar definiertes Massenpublikum oder ein einzelnes Produkt für alle
• Eine Abkürzung ist kein Trick, sondern eine Methode, vorhandene Ressourcen zu nutzen, um weiter zu kommen und weniger auszubrennen
• Wenn eine GitHub Action bestehende Ressourcen zusammenbindet, muss man nur dann an Videos denken, wenn man Videos machen will oder die Situation es wirklich erfordert