Open TV Studio

Lokales, kanalneutrales Broadcast-Control-Center für einen individuellen YouTube-, Twitch-, TikTok-LIVE-, X-, Rumble-, Kick-, Facebook-Live-, LinkedIn-Live- oder eigenen RTMP-Kanal. Das Monorepo verbindet Quellenabruf, vertrauensbasierte Redaktionsregeln, thematische Video- und Grafikrecherche, deutsche TTS-Ausgabe, persistente Sendelisten, OBS-WebSocket-Steuerung, veröffentlichte Browser-Overlays und ein frei konfigurierbares Haupt- und Multistream-Ausgabemodell.

Lokale Installation

Unter Ubuntu oder Debian mit Node.js 22:

./install.sh

Das Installationsskript richtet PostgreSQL, FFmpeg, FFprobe, eSpeak NG, OBS Studio, das OBS-Plugin Multiple RTMP Outputs, Datenbankmigrationen, offizielle Primärquellen, OBS-Szenen, die systemd --user-Dienste sowie einen täglichen Backup- und einen wöchentlichen Wiederherstellungsproben-Timer ein. Die JavaScript-Abhängigkeiten werden reproduzierbar über npm ci aus der eingecheckten Sperrdatei installiert. Vor dem Build wird die README-Vertragsprüfung und vor dem Aktivieren der Dienste die vollständige Studio-Vorabprüfung ausgeführt. Danach ist das Control-Center unter http://127.0.0.1:12001/ erreichbar. Die bei der Erstinstallation erzeugten lokalen Admin-Zugangsdaten stehen mit Dateimodus 0600 in var/admin-credentials.json.

Eine neue Installation ist bewusst keinem fremden Kanal zugeordnet. STUDIO_NAME, CHANNEL_NAME, CHANNEL_URL, STREAM_PLATFORM, STREAM_SERVER und STREAM_KEY werden ausschließlich lokal in .env gesetzt.

Laufzeit

systemctl --user status obs-live-studio.target
systemctl --user restart obs-live-studio.target
systemctl --user list-timers 'obs-live-studio-backup*'
npm run studio:channel:status
npm run studio:preflight
npm run studio:verify
npm run studio:audit

Der Desktop-Agent startet OBS in der grafischen Sitzung. Vor einem Start erkennt er bereits außerhalb des Agents laufende OBS-Prozesse und verhindert dadurch einen zweiten konkurrierenden OBS-Prozess. Crash-Sentinels und Chromium-Singleton-Dateien werden nur entfernt, wenn kein OBS-Prozess läuft und die Dateien mindestens OBS_STALE_ARTIFACT_MIN_AGE_MS alt sind; der Standardwert beträgt 1000 Millisekunden. Die lokale OBS-PID-Datei und ihr Verzeichnis werden mit 0600 beziehungsweise 0700 geschützt. API, Web-UI, Worker, Broadcast-Runner und Overlay-Renderer laufen als neu startende Benutzerdienste. Die Dienste funktionieren sowohl mit systemweit installiertem Node.js als auch mit NVM; NVM wird nur geladen, wenn es vorhanden ist.

Globale Studiosuche

Ctrl+K öffnet die globale Suche. Neben Navigationstiteln durchsucht sie den gesamten relevanten Repository-Quelltext aus WebUI, Backend, Paketen, Dokumentation, Tests und Betriebsskripten und ordnet Treffer dem Arbeitsbereich zu, in dem die Funktion bedient wird. Dadurch führen auch technische Funktionsnamen oder exakte Buttontexte zur passenden Seite. Geheimdateien, Abhängigkeiten und Build-Ausgaben werden nicht indexiert; Rohquelltext wird niemals an den Browser übertragen.

SENDEGOTT und Publikumsrat

Unter KI Studio → SENDEGOTT steuert der Senderinhaber die autonome Strategie, das fünf Rollen umfassende KI-Sendergremium, zwei unabhängige Schlussprüfungen und die KI-Budgets. Vorschläge und Einwände aus YouTube- und Twitch-Chats werden von Sam erfasst, aber niemals direkt ausgeführt. Erst nach Gremiumsquorum und zwei verschiedenen Modellfreigaben darf der Worker eine Entscheidung anwenden; AVA erklärt Beteiligung und Ergebnis im Live-Overlay und im Sprechertext. Architektur, Chatbefehle, Schutzregeln und Diagnose stehen in docs/AUDIENCE_COUNCIL.md.

Das integrierte Autonome Master Control überwacht zusätzlich OBS, Stream, Playout-Runner, Quellenzustand, Programmdeckung, Wiederholungen und Formatbestand im laufenden Betrieb. Es führt bekannte reversible Reparaturen ohne Rückfrage aus, hält ein wiederkehrendes 24-Stunden-Programmraster vor und stößt fehlende Formate sowie reale Eigenproduktionen selbst an. Kreative Änderungen werden weiterhin erst nach Gremiumsquorum und zwei unabhängigen Modellprüfungen automatisch materialisiert. Technische Beratungsabbrüche werden begrenzt wiederaufgenommen; OpenRouter-Strukturfehler besitzen einen lokalen Planungsfallback, ohne die Freigabekette zu umgehen.

Die sichere Agenten-Orchestrierung ergänzt SENDEGOTT um Nora (Self-Improvement), Leo (Growth & Analytics) und Kian (Content/Clips). Sie startet bewusst im Modus stopped, arbeitet mit einmaligen Capability-Grants, einem append-only Audit und lokalem PostgreSQL-RAG und kann den Broadcast weder stoppen noch direkt verändern. Betrieb, API und Grenzen beschreibt docs/AGENT_ORCHESTRATOR.md; die schrittweise Ausbauplanung steht in docs/AUTONOMOUS_GREMIUM_ROADMAP.md.

Lokales YouTube Video Studio

Unter Shorts & Clips → YouTube Video lädt das Studio freigegebene YouTube-Quellen mit yt-dlp lokal, kombiniert Video und Audio per FFmpeg und stellt eine mehrspurige Timeline für Trim, Schnitt, Text, Bilder, Audio, Effekte und Übergänge bereit. Fortschritt, Fehler, Neustartwiederaufnahme und lokale MP4-Exporte sind serverseitig abgesichert. Details stehen in docs/YOUTUBE_VIDEO_EDITOR.md.

Studio-Vorabprüfung

Die Vorabprüfung erkennt unvollständige oder unsichere Installationen, bevor ein Dienst oder eine Sendungsabnahme startet. Sie kontrolliert unter anderem:

• Node.js-Version und benötigte Programme,
• restriktive Rechte für .env, OBS-Profile und Streamkonfigurationen,
• globale OBS-Konfiguration, Benutzerkonfiguration, WebSocket-Konfiguration und Szenensammlung,
• Mindestlängen der lokalen Geheimnisse,
• Loopback-Bindung von API und Desktop-Agent,
• Erreichbarkeit von PostgreSQL,
• OBS-Profil, gewähltes Hauptziel und TTS,
• Installation und Konfiguration von obs-multi-rtmp,
• sämtliche zusätzlichen Ziele, synchronen Start/Stopp, Schlüsselabgleich und Encoder-Sharing.
• Agenten-Orchestrator-Schema, unveränderliches Audit, Broadcast-Isolation, Rollen, Tagesbudget und veraltete Claims.

npm run studio:preflight
npm run studio:preflight -- --scope=configuration
npm run studio:preflight -- --scope=api --json
npm run studio:preflight -- --scope=obs --json

Die API- und Desktop-Agent-Dienste verwenden die passende Prüfung als ExecStartPre. Bei einem Fehler bleibt der betreffende Dienst gestoppt, statt in einem scheinbar betriebsbereiten Zustand zu laufen. Die Diagnose ist anschließend über systemctl --user status oder journalctl --user-unit sichtbar. Geheimnisse werden nicht in den Prüfbericht aufgenommen.

README-Vertragsprüfung

npm run studio:audit gleicht die in dieser README zugesagten Kernfunktionen mit den zugehörigen Skripten, Diensten, Timern, Redaktionsregeln und Oberflächen ab. Die Prüfung läuft während der Installation und zu Beginn der CI-Kette. Der aktuelle Audit kontrolliert 41 Verträge. Fehlt beispielsweise ein beworbener Dienst, ein Betriebsbefehl, die aktive Quellenprüfung des Autopiloten, die Warnhinweis-Anzeige, die verbindliche Video- und Medienrecherche, eine sichere OBS-Konfigurationstransaktion, die veraltete-Artefakte-Regel, das Betriebsstörungszentrum, der Quellenmonitor, die GitHub-Actions-Prüfkette oder die generische Multistream-Synchronisierung, bricht die Prüfung mit einem konkreten Vertragsnamen ab.

npm run studio:audit
npm run studio:audit -- --json

Die Vertragsprüfung ergänzt Funktions- und Integrationstests; sie ersetzt keine Laufzeitprüfung gegen PostgreSQL, OBS oder die Streamingplattformen. Die GitHub-Actions-Datei .github/workflows/ci.yml führt bei Pull Requests und Änderungen an main die vollständige npm run ci-Kette in einer reproduzierbaren Playwright-Umgebung aus. Dazu gehören README-Audit, Formatierung, Lint, TypeScript, Build, PostgreSQL-Migration, Unit- und Integrationstests, OBS-Mock, API, Web-UI, Broadcast-Runner und End-to-End-Tests. Bei Fehlern werden Logs, Broadcast-Tabellen und Playwright-Diagnosen als zeitlich begrenztes Artefakt gesichert.

Sprachausgabe

TTS erzeugen bereitet bei Bedarf zuerst automatisch den Sprechertext des Artikels vor und erzeugt anschließend die Audiodatei. Pocket TTS mit german_24l und natürlicher deutscher Frauenstimme ist der lokale Standard; Piper bleibt der automatische Broadcast-Fallback. ./update.sh migriert ältere Standardeinstellungen, installiert oder repariert die konfigurierte Laufzeit und prüft Pocket TTS, Piper und FFprobe vor dem Neustart. Einzelprüfung und Reparatur:

npm run studio:tts:install
npm run studio:tts:status
npm run studio:tts:check

Störungen, Hinweise und manuelle Quellenabrufe

Das Control-Center besitzt unter Störungen ein persistentes Betriebszentrum. Quellenfehler, Medienrecherchefehler und Fehler des Broadcast-Runners werden nicht nur protokolliert, sondern als deduplizierte Meldungen in PostgreSQL gespeichert. Wiederholte identische Störungen erhöhen den Ereigniszähler und aktualisieren den letzten Zeitpunkt, statt die Oberfläche mit Einzelmeldungen zu überfluten. Quellenfehler werden nach mehreren aufeinanderfolgenden Fehlversuchen von einer Warnung zu einem Fehler hochgestuft. Nach einem erfolgreichen Quellenabruf, einer erfolgreichen Videoauswahl beziehungsweise einem wieder stabilen Runner wird die zugehörige Meldung automatisch als behoben markiert.

Der Lesestatus wird je Benutzer geführt. Das Dashboard und die Seitenleiste zeigen die Anzahl der noch nicht quittierten offenen Meldungen. Im Betriebszentrum können einzelne oder alle offenen Meldungen quittiert und auf Wunsch auch bereits behobene Ereignisse angezeigt werden. Meldungen enthalten nur betriebliche Details wie Komponente, Fehlertext, Fehlversuche und nächsten Wiederholungszeitpunkt; Streamschlüssel und andere Geheimnisse werden nicht aufgenommen.

In der Quellenverwaltung kann jede Quelle unmittelbar über Jetzt abrufen in die persistente Worker-Warteschlange gestellt werden. Der vorhandene Eindeutigkeitsschutz verhindert parallele doppelte Abrufe derselben Quelle. Quellen können außerdem direkt pausiert und erneut aktiviert werden. Manuelle Abrufe und Quittierungen werden im Audit-Protokoll erfasst.

Quellenmonitor und Abrufdiagnose

Unter Quellenmonitor wertet das Control-Center die bereits persistent gespeicherten source_checks aus. Für frei wählbare Zeiträume von sechs Stunden bis 30 Tagen zeigt es pro Quelle Verfügbarkeit, durchschnittliche und maximale Abrufdauer, erfolgreiche und fehlgeschlagene Prüfungen, aktuelle Fehlerfolgen, den letzten Prüfzeitpunkt und einen überfälligen nächsten Abruf. Der Gesamtüberblick fasst stabile, beeinträchtigte, ausgefallene, pausierte und noch nicht gemessene Quellen zusammen.

Eine Quelle gilt als ausgefallen, wenn mindestens drei aktuelle Abrufe in Folge scheitern. Sie gilt als beeinträchtigt, wenn ein aktueller Fehler vorliegt, die Verfügbarkeit im gewählten Zeitraum unter 95 Prozent fällt oder ein erwarteter Abruf einschließlich einer Toleranz von mindestens fünf Minuten ausbleibt. Historische Einzelfehler halten eine inzwischen wieder stabile Quelle nicht dauerhaft im Warnzustand. Bereits vorhandene Prüfungen ohne Laufzeitmessung bleiben sichtbar; neue Abrufe speichern zusätzlich ihre Gesamtdauer. Auch HTTP-Antworten mit unverändertem Inhalt werden als erfolgreiche Prüfung erfasst.

Der detaillierte Prüfverlauf zeigt HTTP-Status, Dauer, erkannte und neu gespeicherte Beiträge, unveränderte Antworten und bereinigte Fehlertexte. Berechtigte Benutzer können direkt aus dem Monitor einen erneuten Abruf in die vorhandene deduplizierte Worker-Warteschlange stellen. Ein zusätzlicher Datenbankindex beschleunigt die zeitbasierte Auswertung großer Prüfverläufe.

Verifizierte Backups

Ein Studio-Backup wird atomar in einem eigenen Verzeichnis angelegt. Es enthält ein komprimiertes Projektarchiv, optional einen PostgreSQL-Dump sowie ein Manifest mit Größe und SHA-256-Prüfsumme aller Artefakte. Unvollständige Sicherungen werden nicht veröffentlicht. Backup-Verzeichnis und Dateien erhalten ausschließlich Eigentümerrechte (0700 beziehungsweise 0600). Die .env wird nicht als Shell-Code ausgeführt, und das Backup-Verzeichnis selbst wird aus dem Archiv ausgeschlossen.

Vor jeder Archiverstellung werden verwaiste .studio-backup-*-Verzeichnisse beseitigt und ausschließlich bereits verifizierte, abgelaufene oder überzählige Sicherungen bereinigt. Das neueste gültige Backup bleibt immer erhalten. Anschließend ermittelt das Studio die Größe der tatsächlich einzuschließenden Quelldaten ohne Schreibprobe. Das Backup startet nur, wenn diese konservative Schätzung mit 20 Prozent Aufschlag, Archiv-Overhead, gegebenenfalls geschätztem Datenbank-Dump und der konfigurierten freien Sicherheitsreserve auf das Backup-Dateisystem passt.

npm run studio:backup
npm run studio:backup -- --json
npm run studio:backup:verify -- ./var/backups/studio-20260714T120000Z
npm run studio:backup:rehearse
npm run studio:backup:rehearse -- ./var/backups/studio-20260714T120000Z

BACKUP_RETENTION_DAYS, BACKUP_MAX_COUNT und optional BACKUP_MAX_TOTAL_BYTES begrenzen Alter, Anzahl und Gesamtvolumen. Standardmäßig werden höchstens zwei vollständige Sicherungen gehalten. BACKUP_MIN_FREE_GB beziehungsweise BACKUP_MIN_FREE_BYTES reserviert nach der geschätzten Erstellung freien Plattenplatz; fehlen Platz oder ein freier Backup-Slot, bricht der Lauf vor tar mit freien, geschätzten, reservierten und benötigten Bytes ab. Nach erfolgreicher Erstellung wird erneut bereinigt.

Rekonstruierbare Laufzeitdaten wie var/*-venv, var/models, var/tts, lokale yt-dlp-Komponenten, Caches, Logs, Render- und temporäre Verzeichnisse werden standardmäßig nicht archiviert. var/tts enthält in dieser Installation erzeugte WAV-Ausgaben und Testausgaben; Sprechertexte, Einstellungen und Asset-Metadaten bleiben in PostgreSQL erhalten und die Audios können nach einem Restore erneut erzeugt werden. Mit BACKUP_INCLUDE_MEDIA=false kann auch var/media ausgeschlossen werden. Zusätzliche relative Pfade lassen sich mit BACKUP_EXTRA_INCLUDE_PATHS ausdrücklich wieder einschließen oder mit BACKUP_EXTRA_EXCLUDE_PATHS ausschließen. Die vollständige Datenmatrix, Wiederherstellung und eine empfohlene 100-GB-Konfiguration stehen in docs/BACKUP.md.

Da die Sicherung .env, Streamkonfigurationen und gegebenenfalls Mediendaten enthalten kann, darf das Backup-Verzeichnis nicht veröffentlicht oder mit anderen Benutzern geteilt werden.

Die Wiederherstellungsprobe prüft zuerst Manifest, Größe, Dateirechte und SHA-256-Prüfsummen. Anschließend entpackt sie das Anwendungsarchiv in einen isolierten temporären Arbeitsbereich, lehnt aus dem Zielbaum herausführende Symlinks und besondere Gerätedateien ab, liest die wiederhergestellte package.json und zählt Dateien sowie Datenvolumen. Ein vorhandener PostgreSQL-Custom-Dump wird mit pg_restore --list auf eine lesbare Wiederherstellungsstruktur geprüft. Die Live-Installation und die produktive Datenbank werden dabei nicht verändert. Ergebnisse liegen mit Modus 0600 unter var/backups/rehearsals/; latest.json enthält die zuletzt ausgeführte Probe.

Der OBS-Betriebsstatus überwacht zusätzlich Alter, Lesbarkeit und Dateirechte der Sicherungen. Standardmäßig gilt ein Backup nach 36 Stunden und eine Wiederherstellungsprobe nach 216 Stunden als veraltet. Die Schwellen lassen sich mit BACKUP_MAX_AGE_HOURS und BACKUP_REHEARSAL_MAX_AGE_HOURS anpassen. Fehlende, veraltete, fehlgeschlagene oder unsicher gespeicherte Sicherungen erscheinen im Control-Center unter OBS und Livestream, ohne den Livestream selbst zu blockieren.

Bei der Installation werden zwei Timer aktiviert. obs-live-studio-backup.timer startet täglich gegen 03:30 Uhr Ortszeit mit bis zu 30 Minuten zufälliger Verzögerung ein verifiziertes Backup. obs-live-studio-backup-rehearsal.timer prüft sonntags gegen 05:30 Uhr mit bis zu einer Stunde zufälliger Verzögerung die Wiederherstellbarkeit des neuesten Backups. Durch Persistent=true werden während einer ausgeschalteten Maschine verpasste Läufe nachgeholt. Beide Dienste laufen mit niedriger CPU- und IO-Priorität, restriktiver UMask und zusätzlichen systemd-Schutzoptionen.

systemctl --user status obs-live-studio-backup.timer
systemctl --user status obs-live-studio-backup-rehearsal.timer
systemctl --user list-timers 'obs-live-studio-backup*'
systemctl --user start obs-live-studio-backup.service
systemctl --user start obs-live-studio-backup-rehearsal.service
journalctl --user-unit obs-live-studio-backup.service --since today
journalctl --user-unit obs-live-studio-backup-rehearsal.service --since today

API-Zugriffsprotokolle

Fastifys doppelte Standardmeldungen incoming request und request completed sind deaktiviert. Normale fachliche Requests werden einmal protokolliert; erfolgreiche Status-, Overlay-, SSE- und Polling-Zugriffe nur als Stichprobe. Fehlerantworten, langsame Requests und explizite Zustandsänderungen bleiben vollständig sichtbar. API_REQUEST_LOGGING=all|sampled|errors, API_REQUEST_LOG_SAMPLE_RATE zwischen 0 und 1 und API_SLOW_REQUEST_MS steuern das Verhalten. Die produktionsfreundlichen Defaults sind sampled, 0.01 und 2000.

Redaktion und Autopilot

Codex CLI, OpenRouter und KI-Zauberstab

Mit AI_PROVIDER=codex verwendet das Studio Codex CLI als Primäranbieter. Jeder Aufruf läuft nicht-interaktiv in einem leeren temporären Verzeichnis, mit Read-only-Sandbox und einem aufgabenspezifischen JSON-Schema. OpenRouter wird zentral unter Einstellungen → KI Studio verwaltet und bleibt mit OPENROUTER_FALLBACK=false standardmäßig aus dem Codex-Laufweg entfernt. Wird OpenRouter bewusst als Primär- oder Fallback-Anbieter aktiviert, gelten weiterhin der dynamische Free-Router, atomare PostgreSQL-Budgets, Preisobergrenzen und Datenschutzfilter.

Bei aktivierter Eingangsbearbeitung schreibt der Worker neue Meldungen eigenständig um, ordnet sie einem Ressort zu, erzeugt Einordnung, Kernpunkte, Unsicherheiten, Bildschirmtext, Ticker und Sprechertext und bewahrt den Originalartikel unverändert auf. KI-Risikohinweise führen weiterhin in die manuelle redaktionelle Prüfung. Scheitert der konfigurierte KI-Anbieter, bleibt der Artikel erhalten; der Autopilot kann auf die bestehende regelbasierte Aufbereitung zurückfallen.

KI-Zauberstäbe stehen in der Beitragsansicht, der Quelleneinrichtung, der Sendelistenplanung und für ausgewählte Overlay-Texte bereit. Sendelisten werden nur aus bereits freigegebenen Beiträgen erzeugt. KI-Ausgaben sind Vorschläge und ersetzen weder Quellenprüfung noch Rechte-, Fakten- oder Freigabeentscheidungen.

Die vollständige Aufgaben- und Modellauswahl ist in docs/OPENROUTER_AI.md dokumentiert.

YouTube Shorts Creator

Unter Shorts & Clips → YouTube Shorts Creator werden qualifizierte Einordnungen aus dem Format „YouTube-Einordnung mit AVA“ als 1080 × 1920 Pixel große, exakt 90 Sekunden lange Shorts produziert. Ein echtes zeitcodiertes Transkript, eine fertige KI-Redaktionsanalyse und eine nicht als Fallback erzeugte AVA-Einordnung sind Pflicht. Tageslimit, PNG-Design, Quellpegel, Sichtbarkeit und Upload-Automatik werden in der WebUI verwaltet. AVA-Sprechertext, Hook, Titel, Beschreibung, Tags und Veröffentlichungsplanung entstehen verpflichtend mit einem budgetierten bezahlten OpenRouter-SOTA-Modell; Free-Modelle werden für diesen Produktionsschritt nicht verwendet. ElevenLabs liefert die gemeinsame hochwertige Stimme für YouTube und TikTok, mit lokalem TTS als protokolliertem Ausfall-Fallback. Automatische Uploads erfolgen ausschließlich nach ausdrücklicher Rechtebestätigung und über eine widerrufbare lokale YouTube-OAuth-Verbindung. Details stehen in docs/YOUTUBE_SHORTS.md.

Der Automatik-Tageswert begrenzt nur selbstständig angelegte Clips. „Aktuellen Moment erstellen“ bleibt eine bewusste manuelle Aktion: Sie kann einen geeigneten Live-Fallback als zeitlichen Anker verwenden, weil der verbindliche Paid-SOTA-Lauf Sprechertext und Veröffentlichungsdaten vor dem Rendern vollständig neu erzeugt.

Der benachbarte TikTok Shorts Creator verwendet dieselben qualifizierten AVA-Momente, rendert jedoch eine eigene TikTok-Fassung ohne Sender-PNG und besitzt einen vollständig getrennten Uploadstatus. Standard ist die Freigabewarteschlange ohne Developer-App: Ein Klick kopiert den Text, lädt die MP4 und öffnet den offiziellen TikTok-Web-Uploader. Die dort aus Sicherheitsgründen notwendige Dateiauswahl und Post-Bestätigung bleiben beim Benutzer. Direct Post mit OAuth ist optional; nicht geprüfte TikTok-Apps bleiben technisch auf SELF_ONLY beschränkt. Details stehen in docs/TIKTOK_SHORTS.md.

AI_PROVIDER=codex
OPENROUTER_FALLBACK=false
OPENROUTER_API_KEY=<lokaler-api-key>
OPENROUTER_PAID_FALLBACK=true
OPENROUTER_PRESENTER_PAID_FALLBACK=true
OPENROUTER_DAILY_BUDGET_USD=1.00
OPENROUTER_MAX_REQUEST_USD=0.03
OPENROUTER_AUTO_PROCESS_INGEST=true
OPENROUTER_DATA_COLLECTION=deny

Der Autopilot verarbeitet ausschließlich Artikel, die:

• aus einer aktuell aktiven und nicht gelöschten Quelle stammen,
• die konfigurierte Vertrauensschwelle erreichen,
• keine kritischen Warnbegriffe enthalten,
• noch nicht ausgespielt oder eingeplant wurden,
• mindestens ein geprüftes lokales Video besitzen,
• bei aktivierter Sendesperre einen laufenden OBS-Livestream vorfinden.

Der Aktivstatus wird unmittelbar vor jeder Auswahl erneut aus PostgreSQL geladen. Das Deaktivieren einer Quelle verhindert daher auch bei bereits eingelesenen Artikeln eine spätere automatische Ausspielung. Eine optionale Quellen-Auswahlliste schränkt die aktiven Quellen zusätzlich ein.

Autopilot, Mindestvertrauen und Livestream-Sperre lassen sich im Dashboard persistent steuern. Offizielle Feeds von Bundesregierung und Deutschem Bundestag werden mit Quellenattribution eingerichtet. Inhalte mit Warnhinweisen bleiben zur manuellen Prüfung im Control-Center: Sie sind in der Nachrichtenliste gekennzeichnet und filterbar; die Detailansicht zeigt die Warnhinweise, den Namen der Quelle, den Originallink, Autor, Veröffentlichungszeit und Vertrauensbewertung. Vor einer manuellen Freigabe eines gewarnten Beitrags verlangt die Oberfläche eine ausdrückliche Bestätigung.

Videos, Grafiken und Statistiken pro Beitrag

Ein Beitrag aus Text, Standbild und Sprecher-Audio gilt nicht als sendefähig. Nach jedem neuen Artikel wird transaktionssicher ein deduplizierter Medienjob angelegt. Der Worker sucht thematisch passende Videos und Bilder, speichert Herkunft, Urheber, Lizenz, Lizenzlink und Attribution und erzeugt aus geeigneten Zahlen im Artikel automatisch eine 16:9-Statistikkarte.

Unterstützt werden Wikimedia Commons ohne Schlüssel sowie Pexels, Pixabay und die YouTube Data API mit lokal konfigurierten API-Schlüsseln. YouTube-Ergebnisse dienen ausschließlich als redaktionelle Referenz und werden nicht heruntergeladen. Automatische Downloads sind auf bekannte Provider-CDNs, HTTPS, Redirect-Neuprüfung, Größenlimits und einen Gesamttimeout begrenzt. FFprobe prüft Videostream, Dauer und mindestens 640 × 360 Pixel; FFmpeg erzeugt Vorschaubilder.

Die Beitragsansicht bietet Suche, Vorschau, Quellen- und Lizenzlinks, Rechtebestätigung, Import, Ablehnung, Statistik-Erzeugung und einen Eigenvideo-Upload. Ein Eigenvideo wird erst akzeptiert, wenn Urheber, Quelle, Lizenz beziehungsweise Rechtsgrundlage und eine ausdrückliche Rechtebestätigung angegeben wurden.

Die Pflicht wird an vier Stellen durchgesetzt: redaktionelle Freigabe, PostgreSQL-Sendeliste, Autopilot und OBS-Ausspielung. OBS zeigt ANS_ARTICLE_VIDEO stumm und wiederholt im Hintergrund, führt ANS_SPRECHER_AUDIO als Ton- und Zeitquelle und kann ANS_ARTICLE_GRAPHIC als Bild-in-Bild einblenden. Das Hauptoverlay bleibt darüber teiltransparent sichtbar.

Ausführliche Anbieter-, Rechte- und Betriebsinformationen stehen in docs/MEDIA_RESEARCH.md.

MEDIA_COMMONS_ENABLED=true
PEXELS_API_KEY=
PIXABAY_API_KEY=
YOUTUBE_DATA_API_KEY=
MEDIA_AUTO_IMPORT_VIDEO=true
MEDIA_AUTO_IMPORT_GRAPHIC=true
MEDIA_DOWNLOAD_TIMEOUT_MS=120000
MEDIA_MAX_VIDEO_BYTES=262144000
MEDIA_MAX_VIDEO_DURATION_SECONDS=180

Kanal und Hauptplattform

Das Hauptziel und bis zu acht zusätzliche parallele Ziele werden im Browser unter Einstellungen → OBS und Streaming-Ziele beziehungsweise direkt unter http://localhost:12001/#/obs bearbeitet. Beim Speichern schreibt das Studio die private .env, aktualisiert das OBS-Profil und die Multi-RTMP-Konfiguration und startet einen zuvor laufenden OBS-Prozess neu. Während einer laufenden Sendung bleibt die Änderung gesperrt. Bereits gespeicherte Streamschlüssel werden nie an den Browser zurückgegeben; ein leeres Schlüsselfeld behält den vorhandenen Schlüssel bei.

Alternativ kann das Hauptziel weiterhin direkt über die lokale .env gewählt werden:

STUDIO_NAME=Mein TV Studio
CHANNEL_NAME=Mein Kanal
CHANNEL_URL=https://beispiel.invalid/mein-kanal
STREAM_PLATFORM=rumble
STREAM_TARGET_NAME=Rumble
STREAM_SERVER=<rtmps-server-aus-dem-creator-dashboard>
STREAM_KEY=<streamschluessel>

Unterstützte Plattformprofile sind youtube, twitch, tiktok, x, rumble, kick, facebook, linkedin und custom. Für YouTube und Twitch besitzt das Studio bekannte RTMPS-Standardserver. Für TikTok LIVE, X, Rumble, Kick, Facebook Live und LinkedIn Live werden Server und Schlüssel aus dem jeweiligen Creator-Dashboard eingetragen. TikTok stellt den LIVE-Zugang und Encoder-Schlüssel nur für dafür freigeschaltete Konten bereit; das Studio erfindet oder beschafft keinen Schlüssel über eine inoffizielle API. Der Streamschlüssel wird weder von der API noch vom Statusbefehl ausgegeben.

Bestehende Installationen mit YOUTUBE_CHANNEL_URL, TWITCH_ENABLED, TWITCH_STREAM_SERVER und TWITCH_STREAM_KEY bleiben abwärtskompatibel.

Zusätzliche Streaming-Ziele

Zusätzliche Ziele werden über das OBS-Plugin Multiple RTMP Outputs (sorayuki/obs-multi-rtmp) eingerichtet. Das Plugin verwendet den vorhandenen OBS-Hauptencoder und startet beziehungsweise stoppt alle Ziele synchron. Es wird kein zweiter OBS-Prozess gestartet.

Der Installer unterstützt sowohl die aktuellen, für OBS 32 angebotenen Ubuntu-.deb-Pakete als auch ältere .tar.xz-Releases. Er prüft Downloadquelle, Größe und SHA-256-Digest und installiert das Plugin ohne Root-Rechte atomar unter ~/.config/obs-studio/plugins/obs-multi-rtmp. Ein OBS-Neustart lädt das Plugin; die Vorabprüfung verhindert den Sendestart, falls Binärdatei, Zielkonfiguration, Schlüssel, Synchronisierung oder Encoder-Sharing nicht konsistent sind. Beim Speichern eines aktiven parallelen Ziels führt die WebUI diesen Installationsschritt automatisch vor der OBS-Konfiguration aus.

Die Browser-Oberfläche bietet für jedes zusätzliche Ziel Aktivierung, Plattform, RTMP-/RTMPS-Server, Streamschlüssel, Kanal-URL sowie synchronen Start und Stopp. Neben den bekannten Profilen nimmt „Benutzerdefiniertes RTMP-Ziel“ jeden weiteren Anbieter mit einer RTMP- oder RTMPS-Ingest-Adresse auf. Die folgende manuelle Konfiguration bleibt für automatisierte Installationen und Umgebungsreferenzen verfügbar:

RUMBLE_STREAM_SERVER=<rtmps-server>
RUMBLE_STREAM_KEY=<streamschluessel>
RUMBLE_CHANNEL_URL=https://rumble.com/c/mein-kanal
STREAM_TARGETS_JSON=[{"id":"rumble","platform":"rumble","name":"Rumble","serverEnv":"RUMBLE_STREAM_SERVER","keyEnv":"RUMBLE_STREAM_KEY","channelUrlEnv":"RUMBLE_CHANNEL_URL"}]

Mehrere Objekte können im JSON-Array stehen. Erlaubt sind direkte Werte oder Referenzen über serverEnv, keyEnv und channelUrlEnv. Die Verwendung von Umgebungsreferenzen verhindert, dass Schlüssel in gemeinsam genutzten Konfigurationsbeispielen auftauchen.

npm run studio:channel:status
npm run obs:install-multi-rtmp
systemctl --user stop obs-live-studio-desktop-agent.service || true
npm run obs:configure
npm run studio:preflight -- --scope=obs
systemctl --user restart obs-live-studio.target

npm run obs:configure pflegt ausschließlich Ziele mit dem Präfix studio-target- in obs-multi-rtmp.json und entfernt bei der Migration auch das frühere Ziel argumentationskette-twitch. Andere manuell angelegte Plugin-Ziele und Encoderprofile bleiben erhalten. Sämtliche vom Studio verwalteten OBS-Dateien werden über eine Transaktion aktualisiert: Vor jeder Inhalts- oder Rechteänderung werden vorhandene Originaldateien unter var/backups/obs-config-* gesichert. Das Backup enthält ein Manifest mit Pfad, Größe, ursprünglichem Modus und SHA-256-Prüfsumme. Erst nach erfolgreicher Sicherung werden geänderte Dateien atomar ersetzt. Symbolische Links werden abgewiesen. OBS-Profil, globale Konfiguration, Benutzerkonfiguration, WebSocket-Konfiguration, Szenensammlung, Streamkonfiguration, Plugin-Konfiguration und .env werden mit Dateimodus 0600 geschrieben.

Die Video-Encoding-Last wird durch Encoder-Sharing nicht für jedes Ziel erneut erzeugt. Die Internetleitung muss trotzdem die Summe aller parallelen Ausgaben zuzüglich Reserve tragen.

Clips und archivierte Streamsegmente

Der Stream-Supervisor beendet Langzeitstreams standardmäßig nach 11 Stunden 45 Minuten kontrolliert und startet sie nach fünf Sekunden neu. Vor dieser Zwangstrennung wird der aktive YouTube-Broadcast explizit abgeschlossen; damit wird das Segment mit seiner konfigurierten Sichtbarkeit als normales Kanalvideo archiviert. Weitere RTMP-Plattformen erhalten denselben synchronen Stopp und Start und veröffentlichen das Segment gemäß ihrer Creator-Dashboard-/VOD-Einstellung. Auf Twitch muss Vergangene Übertragungen speichern aktiviert sein.

Während Twitch live ist, erstellt das Studio zusätzlich standardmäßig alle 30 Minuten einen gehosteten Twitch-Clip. Dafür werden ein Twitch-User-Token mit clips:edit und die Helix-Anwendungsdaten benötigt:

STREAM_SEGMENT_MAXIMUM_MS=42300000
STREAM_SEGMENT_RESTART_DELAY_MS=5000
TWITCH_CLIPS_ENABLED=true
TWITCH_CLIP_INTERVAL_MS=1800000
TWITCH_CLIP_CONFIRM_ATTEMPTS=12
TWITCH_CLIP_CONFIRM_INTERVAL_MS=5000
TWITCH_CLIENT_ID=<twitch-client-id>
TWITCH_ACCESS_TOKEN=<user-token-mit-clips-edit>
TWITCH_BROADCASTER_ID=<numerische-sender-id>

Ohne Clip-OAuth läuft der Stream weiter; das Störungscenter meldet die fehlende Berechtigung. Die Segmentrotation bleibt aktiv, damit Plattform-VODs weiterhin begrenzt und archivierbar sind.

Struktur

• apps/api: Fastify-API, Authentifizierung, Redaktion, Overlays, OBS und Stream-Supervisor
• apps/web: produktives Live-Control-Center
• apps/worker: Quellenabruf, Medienrecherche und vertrauensbasierter Autopilot
• apps/broadcast-runner: persistente, geleaste OBS-Ausspielung
• apps/desktop-agent: OBS-Prozess und grafische Linux-Sitzung
• packages/streaming-platforms: zentrale Plattform-, Kanal- und Zielprofile
• packages/agent-orchestrator: typisierte Rollen, sichere Workflow-Vorlagen, Capability- und Memory-Verträge
• packages/*: Datenbank, Parser, TTS, Overlays, Medien, Security und Broadcast-Engine
• scripts/*: Installation, Bootstrap, Vorabprüfung, OBS-, Quellen-, Admin- und Abnahmeautomatisierung

OBS benötigt unter Linux eine echte grafische Sitzung. Paywalls, Captchas, Logins, DRM oder Zugriffsschutz werden nicht umgangen.