Stream-Werkzeuge zentral

Das Ziel

Jede laufende AVI-Mover-Instanz lässt sich vom Browser aus beobachten und ändern, ohne dass jemand an den Rechner geht. Der Anlass ist bekannt: Am Austrian Cup stand in allen acht Paketen derselbe Replay-Ordner, und die Korrektur kostete einen Gang zu jeder Matte — mitten im Betrieb.

Beobachten heißt: aktueller Zustand, laufende Datei, Zähler für verschoben / misslungen / leer, und das Log mitlesen — nicht nur die letzte Zeile, sondern der Verlauf, so wie er im Fenster steht.

Ändern heißt: Quellordner, Serverziel, Kanal, Statusordner und Turniername setzen; starten, stoppen, neu starten, pausieren; Liegengebliebenes nachholen.

An zwei Orten bedienbar: lokal in der Halle auf dem Capt-Server, ohne Internet — und vom Hetzner aus, wenn jemand von außen schauen soll. Beide zeigen dasselbe.

Nicht Teil des Ziels: den Mover selbst ablösen. Er bleibt das PowerShell-Programm auf jedem Laptop, weil er dort überwachen und verschieben muss. Was verschwindet, ist der Gang an den Rechner.

Befehlsdatei statt WebSocket

Der Rückkanal steht schon: Jeder Mover schreibt seine status.json in einen Statusordner (\\capt-server-1\www-root\avi-mover\matteN). Denselben Ordner kann er lesen. Die Zentrale legt dort befehl.json ab, der Mover holt sie in seinem bestehenden 250-ms-Takt ab, führt aus und quittiert.

Ein echter WebSocket in PowerShell-WinForms bräuchte Reconnect-Logik und Nebenläufigkeit und brächte nur Latenz unter einer Sekunde. Für „Pfad ändern, neu starten, Turnier umbenennen" ist das ohne Wert. Bei OBS ist das anders — dort ist WebSocket die eingebaute Schnittstelle, siehe Punkt 4.

Eigene Konfigdatei, nicht die INI

Die Zeilen der AVI-Mover.ini sind positionsgebunden (0-basig: 2 Quelle, 4 Serverziel, 5 Kanal, 6 Statusordner, 7 Turnier). Eine zusätzliche Zeile verschiebt alles — genau diese Falle hat am 03.10. Zeit gekostet. Die Adressen der Zentralen kommen deshalb in eine eigene avimover_config.json daneben.

Der Name ist mit Absicht so gewählt: Er trifft das Schutzmuster *_config.json in Get-SchutzDateien des Stream-Tools-Updaters. Damit überschreibt kein Update die örtliche Einrichtung, die neue Fassung landet als .neu daneben.

{ "zentralen": ["\\\\capt-server-1\\www-root\\avi-mover",
                "\\\\rtmp-server-1\\www-root\\avi-mover"],
  "kanal": "matte1", "takt_ms": 1000 }

Log in Scheiben zum Server

Das Fenster-Log soll auch auf dem Server lesbar sein. Nicht die ganze Datei bei jedem Takt — der Mover schreibt fortlaufend an log.txt im Statusordner, die Zentrale holt nur den Zuwachs ab der letzten Position.

Dazu in status.json zwei Felder: Länge der Logdatei und Zeitstempel. So sieht die Zentrale ohne Dateizugriff, ob es etwas Neues gibt.

Pfadwechsel absichern

Der nützlichste Befehl ist zugleich der, der eine laufende Matte lahmlegen kann. Deshalb: Der Mover lehnt ab, solange er gerade kopiert, prüft das neue Ziel mit Test-Path bevor er es übernimmt, und schreibt den Grund in die Quittung. In der Oberfläche sitzt der Knopf hinter einer Rückfrage.

Dazu gehört, was AVI-Mover nicht tut: Zielordner anlegen (AVI-Mover.ps1:1058 prüft nur). Die Zentrale muss das vorher können oder deutlich sagen, dass der Ordner fehlt.

Steuerzentrale: eine Zeile je Matte

Eine Seite, vier Zeilen. Je Zeile: Zustand, letzte Datei, Zähler, Quell- und Zielordner, und die Knöpfe. Darunter aufklappbar das Log.

Der eigentliche Gewinn ist das Nebeneinander: Die Fehler vom Austrian Cup saßen alle an den Nahtstellen — Replay-Ordner zeigte auf Matte 1, Serverziel ins Nirgendwo, Cams leer. Jedes Werkzeug für sich sah in Ordnung aus. Vier Zeilen untereinander hätten es sofort gezeigt.

Dazu ein Knopf „an alle" für das, was sich mit der Mattenzahl multipliziert: Turniername, Tageswechsel, Zielordner mit eingesetzter Mattennummer.

Was wir heute haben — und warum es weg kann

Bisher lief der Hallenton über ein eigenes Windows-Programm (Microphon-Broadcaster, PowerShell mit mitgeliefertem ffmpeg): Geräteliste, ein oder zwei Mikrofone, dazu ein schwarzes Videobild — weil RTMP ohne Videospur nicht auskommt — und per RTMP an einen Restreamer (192.168.1.210 / .212).

Das wird nicht abgelöst, sondern abgeschafft. Gernot, 04.10.2026: „Den brauchen wir nicht mehr." Es taugt deshalb auch nicht als Messlatte — wir bauen den Weg neu, nicht nach.

Was aus dem alten Aufbau bleibt, ist eine einzige Erkenntnis: Der Umweg über RTMP zwingt zu einer Videospur für einen reinen Tonkanal. Genau die fällt mit WebRTC weg.

Das Ziel

Der Hallenton kommt ohne eigenes Programm auf einem Rechner in alle OBS-Instanzen. Quelle auswählen, starten, stoppen — vom Browser aus, mit derselben Oberfläche wie die übrigen Werkzeuge.

Anforderungen: Auswahl der Tonquelle, wenn mehrere am Rechner hängen; ein klarer Zustand — läuft / läuft nicht — mit Pegelanzeige; und selbsttätiges Wiederverbinden nach einem Abriss.

Wie groß der Gewinn bei der Verzögerung ausfällt, messen wir in der Testphase. Vorher lege ich dazu keine Zahl fest.

MediaMTX als Drehscheibe statt MonaServer

Mein Vorschlag: MediaMTX auf dem Capt-Server. Er nimmt WebRTC per WHIP entgegen und gibt denselben Strom wahlweise als SRT, RTSP oder RTMP wieder aus. Damit ersetzt ein Dienst den MonaServer und kann beides: modern rein, vertraut raus.

Der Vorteil liegt in der OBS-Seite: Die bleibt eine Medienquelle wie bisher, nur mit anderer Adresse. Kein Plugin, kein Umbau der Szenen, kein neues Verfahren, das am Turniertag zum ersten Mal auf die Probe gestellt wird.

MediaMTX ist ein einzelnes Programm ohne Installation, läuft als Dienst und wird über eine einzige mediamtx.yml eingerichtet.

Der Sender wird eine Webseite

Statt PowerShell und mitgeliefertem ffmpeg: eine kleine Seite auf dem Capt-Server. Sie fragt den Browser nach den Tonquellen (enumerateDevices), zeigt sie in einer Liste, dazu ein Pegel und zwei Knöpfe. Gesendet wird per WHIP an MediaMTX.

Damit fällt der Broadcaster als eigenes Programm weg. Jedes Gerät mit Browser kann Sender sein — der Regie-Laptop, ein zweiter Rechner, notfalls ein Handy. Nichts zu installieren, nichts zu aktualisieren.

HTTPS — die CA steht schon

Weitgehend erledigt. Die eigene Stamm-CA läuft seit 17.08.2026:

Judo Fanpage Stream-CA        10 Jahre, kein Intermediate
  └── CAPT-Server-1           gültig bis 18.09.2027

Verwaltet im Stream-Tools-Updater, Reiter Zertifikate (ZERT-V1). Abyss steht auf HTTP & HTTPS, Zertifikat und Schlüssel sind als Inhalt eingetragen. Die Sender-Seite kann dort also sofort gesichert laufen.

Was offen bleibt:

• Nur über den Hostnamen aufrufen. Das Zertifikat enthält bewusst keine IP — nur CAPT-Server-1 und CAPT-Server-1.JUDO-FANPAGE. Über https://192.168.1.10/… schlägt es fehl, und der Browser rückt dann kein Mikrofon heraus.
• MediaMTX ist ein eigener Dienst, nicht Abyss. Für WHIP braucht er dasselbe Zertifikat noch einmal, in seiner Konfiguration als Dateipfad.
• Auf jedem sendenden Gerät muss Stream-CA.crt im Stammspeicher liegen (Updater-Knopf Auf DIESEM PC vertrauen). Für Rechner längst erledigt; ein Handy als Sender wäre eine eigene Baustelle, dort ist das deutlich mühsamer.

Wiedervorlage: Server-Zertifikate laufen nach 397 Tagen ab. Nach dem Erneuern müssen sie erneut in Abyss eingetragen werden — und künftig auch bei MediaMTX.

Rückweg für den Turniertag

Bis WebRTC einen kompletten Turniertag ohne Zwischenfall gelaufen ist, bleibt der bisherige RTMP-Weg als Rückfall erreichbar — die OBS-Quelle lässt sich in Sekunden zurückstellen.

Ein Tonausfall in der Halle ist nicht reparabel, während er passiert.

Das Ziel

Alle Hallenkameras müssen in jede OBS-Instanz. Die vier Matten laufen auf vier Laptops — eine Kamera, die am Capt-Server hängt, sieht dort niemand. Jede Kamera wird also verteilt, unabhängig davon, ob sie am Kabel hängt oder nicht.

Zuständig ist der Capt-Server. Er nimmt alle Kameras entgegen und gibt sie an die Matten weiter. Je nach Last und Aufgabe kann ein RTMP-Server das übernehmen — das wird beim Event entschieden und bleibt flexibel.

Nicht Teil des Ziels: die Mattenkameras. Die hängen direkt am jeweiligen OBS und bleiben, wo sie sind.

Alle müssen verteilt werden — der Weg dahin unterscheidet sich

Alle fünf Kameras gehen über die Drehscheibe. Der Unterschied liegt nur darin, wie sie dorthin kommen — und das entscheidet die Verkabelung:

Die verkabelten holt sich der Capt-Server selbst. MediaMTX kann ein angeschlossenes Gerät beim Start einlesen und als Pfad bereitstellen — kein zusätzliches Programm, kein Fenster, das jemand offen halten muss. Fällt die Kamera aus und kommt wieder, holt MediaMTX sie von selbst zurück.

Die kabellosen senden selbst — Handy mit Larix auf denselben Dienst. Für sie gilt alles, was in Punkt 2 zum Mikrofon steht.

In OBS sieht am Ende alles gleich aus: fünf Medienquellen, fünf Adressen, gleiche Bauart. Ob dahinter ein Kabel oder ein Handy steckt, merkt die Matte nicht — und genau so soll es sein.

Overlays: in OBS, nicht in der Kamera

Gernots offene Frage: Overlays in der Kamera-Kette oder in OBS?

Meine Empfehlung: OBS machen lassen. Ein Overlay, das schon im Kamerabild steckt, ist eingebrannt — es lässt sich nicht mehr ausschalten, nicht verschieben, nicht gegen ein anderes tauschen, und wenn der Name falsch geschrieben ist, muss jemand zur Kamera laufen. In OBS bleibt es eine Ebene über dem Bild: ein Klick aus, ein Klick an.

Dazu kommt, dass die Overlay-Infrastruktur bereits steht — Studio, Szenen, Docks, alles zentral änderbar. Eine zweite Overlay-Kette in der Kamera wäre ein Werkzeug mehr, das gepflegt werden will.

Der Preis: Jede OBS-Instanz, die eine Hallenkamera zeigt, braucht die passende Szene. Das ist Arbeit beim Einrichten — aber Arbeit, die der Lotse mitliefern kann, und sie fällt einmal an statt bei jedem Umschalten.

Ausnahme, falls doch nötig: eine feste Einblendung, die immer gleich bleibt und nie weg soll (etwa ein kleines Logo in der Ecke). So etwas darf in die Kamera-Kette, weil niemand es je abschalten will.

Der Lotse entscheidet, welche Kamera dabei ist

Gernots Festlegung (04.10.2026): Ob eine Hallenkamera überhaupt dabei ist, wird im Lotsen entschieden — beim Zusammenstellen des OBS-Pakets, nicht am Turniertag an vier Laptops.

Zwei Wege, wenn eine Kamera nicht gebraucht wird: die Quelle deaktivieren oder sie gar nicht erst ins Paket packen.

Meine Empfehlung: drin lassen, deaktiviert. Eine fehlende Quelle muss jemand am Turniertag von Hand anlegen — Name, Adresse, Transformation, Einpassung. Das ist genau die Handarbeit, die wir loswerden wollen. Eine deaktivierte Quelle dagegen ist ein Klick auf das Auge.

Damit das sauber bleibt, muss bei jeder Kameraquelle „Wiedergabe beenden, wenn Quelle nicht sichtbar" gesetzt sein. Sonst hängt eine unsichtbare Quelle weiter an der Drehscheibe, verbraucht Bandbreite und meldet Verbindungsfehler für etwas, das niemand sieht.

Rausziehen lohnt nur, wenn eine Kamera auf Dauer wegfällt — dann gehört sie auch nicht mehr in die Vorlage, aus der der Lotse baut.

Was der Lotse dafür braucht: eine Angabe je Paket, welche Kameras aktiv sind. Das passt zu der Vorbelegung, die laut Punkt „Vorbelegung im JEM" mitfahren könnte — aber auch ohne sie: Beim Paketbau wird es ohnehin entschieden, es muss nur festgehalten werden.

Welcher Weg für die kabellosen

Für die beiden kabellosen Kameras — Siegerehrung und die bewegliche — kommen drei Wege in Frage. Sie unterscheiden sich vor allem darin, was passiert, wenn das WLAN kurz wegbricht.

Larix Broadcaster sendet vom Handy direkt per RTMP oder SRT, ohne Rechner dazwischen. Bei uns bereits im Einsatz, die Grenzen sind bekannt. Mein Vorschlag für beide.

DroidCam macht das Handy zur Webcam über USB oder WLAN. Braucht einen Rechner in der Nähe — bei der Siegerehrung also einen zusätzlichen Aufbau, den wir gerade loswerden wollen.

Der Browser mit derselben Sender-Seite wie beim Mikrofon, nur mit Video. Spart eine App — aber Handybrowser schlafen ein, sobald der Bildschirm dunkel wird, und dann ist das Bild weg. Für Dauerbetrieb nicht geeignet, für eine kurze Interviewstrecke schon.

Entschieden wird nach dem ersten Test, nicht vorher.

Capt-Server oder RTMP-Server — je Event

Wer nimmt die kabellosen Kameras entgegen — Capt-Server oder RTMP-Server?

Das wird beim Event entschieden, nicht vorab festgelegt. Gernot, 04.10.2026: „Das soll flexibel bleiben." Eine Halle mit vier Matten und Replay-Betrieb verteilt anders als ein Ligakampftag mit einer Matte.

Voreinstellung ist der Capt-Server — dort liegen ohnehin Regie-Dashboard, AVI-Mover-Statusordner und künftig das Mikrofon. Ein Rechner weniger im Spiel.

Umziehen lohnt, wenn der Capt-Server gleichzeitig Replays ausspielt und mehrere Kameras weiterverteilt. Dann bekommt der RTMP-Server die Kameras, der Capt-Server behält Replay und Steuerung.

Der Umzug ist eine Zeile: In der Sender-App ein anderer Rechnername, in OBS ebenso. Pfadnamen und Aufbau bleiben gleich — genau deshalb muss man es nicht vorher wissen. Was im Aufbau gleich bleibt, darf im Betrieb wandern.

Vorbelegung im JEM, Anpassung vor Ort

Flexibel heißt nicht, dass man am Turniertag bei null anfängt. Im Event-Manager könnte je Event stehen, was vorgesehen ist — welche Kameras mitkommen und wer sie entgegennimmt. Nicht als Festlegung, sondern als Vorschlag, den man vor Ort umwirft, wenn es anders kommt.

Wo es hingehört: Die Bridge überträgt bereits device_counts aus dem Event-Manager zum Capt-Server — Hallenkameras, Mikrofone, Zusatzkameras. Das ist die Stelle, an der so eine Vorbelegung mitfahren könnte, ohne einen neuen Weg zu bauen.

Was dafür spricht: Beim Aufbau steht dann auf dem Schirm, was geplant war — statt dass jemand im Kopf hat, dass diesmal die Bewegt-Hallenkamera dabei ist. Die Fehler am Austrian Cup kamen nicht daher, dass etwas unmöglich war, sondern dass niemand sah, wie es gemeint war.

Was dagegen spricht: Ein Vorschlag, den niemand pflegt, ist schlimmer als keiner — er behauptet etwas. Das lohnt sich also nur, wenn die Angabe beim Anlegen des Events ohnehin anfällt.

Und vor Ort anpassbar. Der Vorschlag aus dem Event-Manager ist der Stand beim Planen; was gilt, entscheidet sich beim Aufbau. Die Zuordnung muss sich deshalb in der Stream-Regie ändern lassen (Punkt 4) — nicht im JEM, nicht in einer Datei auf einem Rechner.

Daraus folgt eine Anforderung an Punkt 4: Die Regie zeigt je Kamera, was vorgesehen war und was tatsächlich läuft, und erlaubt das Umhängen auf den anderen Server mit einem Griff. Weicht beides voneinander ab, ist das kein Fehler — nur eine Auskunft.

Entscheidung vertagt, bis Punkt 3 einmal gelaufen ist. Vorher wissen wir nicht, welche Angaben sich überhaupt lohnen.

Das Ziel

Eine Adresse für den Turniertag. Statt sieben Lesezeichen und vier Fenstern eine Oberfläche, die zeigt, wie es um alles steht, und von der aus sich alles bedienen lässt.

Es gibt bereits einen Vorläufer: die Einstiegsseite des Capt-Servers (capt-start/index.php, CAPTSTART-V1) mit drei Kacheln — Stream Dashboard, Verbindungsmanager, Regie-Dashboard. Sie prüft sogar, ob die verlinkten Seiten existieren. Die Stream-Regie ist der Ausbau dieser Seite, kein Neuanfang daneben.

Was hineingehört — alles davon existiert bereits oder entsteht in den Punkten 1 bis 3 und 6:

• Regie-Dashboard (Replays sichten und ausspielen)
• Master-Monitor / Dashboard (Kanäle, Klickzahlen, Kurzlinks)
• Verbindungsmanager (netz/index.php) — welches Gerät antwortet und wie man draufkommt. Am Turniertag das Werkzeug, mit dem man herausfindet, warum eine Matte schweigt.
• AVI-Mover-Steuerzentrale (Punkt 1)
• Hallenmikrofon (Punkt 2)
• Hallenkameras (Punkt 3)
• OBS-Fernsteuerung mit Setup (Punkt 6)
• Overlay-Docks je Matte
• Matten-Status-Board

Der eigentliche Zweck ist nicht die Sammlung, sondern die Kopfzeile: eine Zeile je Matte, die zeigt, ob Kamera, Ton, Replay, Mover und Stream zusammenpassen. Die Fehler am Austrian Cup saßen alle an den Nahtstellen — jedes Werkzeug für sich meldete „in Ordnung".

Der Verbindungsmanager ist dabei die Ebene darunter: Wenn die Kopfzeile sagt „Matte 3 antwortet nicht", beantwortet er die nächste Frage — liegt es am Rechner, am Netz oder am Programm.

Bauart: Rahmen statt Neubau

Kein Neubau. Ein Rahmen um das, was schon läuft. Die Werkzeuge bleiben eigenständige Seiten; die Regie bettet sie ein und legt eine gemeinsame Kopfzeile darüber. So bleibt jedes Werkzeug auch einzeln aufrufbar — wichtig, wenn mal etwas klemmt.

Die Falle beim Einbetten, und zwar eine, die uns schon zweimal getroffen hat: Ein eingebettetes Fenster zeigt „Verbindung abgelehnt", wenn die eingebettete Seite es nicht erlaubt. Das ist kein Netzproblem, sondern X-Frame-Options beziehungsweise frame-ancestors. Jede Seite, die in die Regie soll, muss das Einbetten durch die Regie ausdrücklich zulassen.

Zwei Welten, ein Rahmen: Die Regie läuft lokal auf dem Capt-Server. Werkzeuge, die auf dem Hetzner liegen (Overlay-Docks, JEM-Seiten), werden von dort geholt — fällt das Internet in der Halle aus, müssen die örtlichen Werkzeuge weiterlaufen. Die Kopfzeile muss deshalb sagen, welcher Teil gerade nicht erreichbar ist, statt leer zu bleiben.

Das Ziel

Das Dashboard auf dem Capt-Server zeigt heute, was über RTMP läuft. Mit Punkt 2 und 3 wechselt die Technik unter Ton und Hallenkameras — MediaMTX statt MonaServer, WebRTC statt RTMP. Das Dashboard muss das mitbekommen, sonst zeigt es grün, wo nichts mehr fließt.

Was sich ändert:

• Die Zustandsabfrage. Bisher über den RTMP-Server, künftig über die MediaMTX-API — sie sagt je Pfad, ob jemand sendet und wie viele zuhören.
• Die Quellenarten. Ein Kanal kann nun RTMP, SRT oder WebRTC sein; das Dashboard sollte sagen, welche.
• Die Gerätezählung aus dem Event-Manager (device_counts in der Bridge: hall_mic, hall_cam …) bleibt, aber was dahintersteht, ist nicht mehr dasselbe.

Wichtig für die Übergangszeit: Solange MonaServer als Rückfall steht (Punkt 2), muss das Dashboard beide Wege anzeigen können — und auseinanderhalten, welcher gerade trägt.

Die MediaMTX-API als neue Quelle

MediaMTX bringt eine Abfrageschnittstelle mit. Sie ist der Ersatz für das Mitlesen am RTMP-Server:

http://capt-server-1:9997/v3/paths/list

Die Antwort nennt je Pfad, ob eine Quelle sendet (ready), seit wann, und wie viele Empfänger daranhängen. Genau die drei Angaben, die das Dashboard je Kachel braucht.

Daraus lässt sich etwas bauen, was es bisher nicht gab: die Unterscheidung zwischen „niemand sendet" und „es sendet jemand, aber niemand hört zu". Heute sieht beides gleich aus — und das zweite ist der Fall, bei dem in OBS die Quelle fehlt.

Das Ziel

Jede laufende OBS-Instanz muss sich von außen anpassen lassen — Quellen, deren Einstellungen und deren Lage im Bild, einzeln oder an allen vier Matten gleichzeitig.

Der Anlass steht im Protokoll des Austrian Cup: In allen acht Paketen stand derselbe Replay-Ordner. Die Korrektur kostete einen Gang zu jeder Matte, mitten im Betrieb. Dasselbe bei den Fenstermaßen im Replay, bei der leeren Szene Cams, bei der Pause-Szene mit Begrenzung 0×0. Jedes Mal vier Mal dasselbe von Hand.

WebSocket ist hier der richtige Weg, anders als beim AVI-Mover: OBS bringt obs-websocket ab Werk mit, Port 4455. Das ist die eingebaute Schnittstelle, kein Nachbau — und sie kann mehr als nur Szenen umschalten.

Kein Server-Prozess nötig. Eine HTML-Seite auf dem Capt-Server hält vier Verbindungen gleichzeitig und spricht jede Instanz direkt an.

Was sich ändern lässt

Was sich damit ändern lässt — geordnet danach, was uns tatsächlich gekostet hat:

Das Bildschirmfoto ist vermutlich das Wertvollste — vier Kacheln nebeneinander zeigen auf einen Blick, wo eine Matte schwarz läuft. Heute erfährt man das vom Zuschauer.

Global, Gruppe, einzeln — mit Rücksicht auf die Matte

Drei Reichweiten, immer sichtbar vor dem Senden:

• Einzeln — eine Instanz, etwa wenn an Matte 3 etwas verstellt ist.
• Gruppe — freie Auswahl per Haken. Etwa „alle Matten von Tag 2" oder „Matte 1 und 2", wenn nur die beiden eine Hallenkamera zeigen.
• Global — alle verbundenen Instanzen.

Und hier liegt die eigentliche Schwierigkeit: Ein Befehl an alle darf nicht überall denselben Wert setzen. Genau das war der Fehler am Austrian Cup — in allen acht Paketen stand Judo Matte 1, und Matte 2 bis 4 schrieben ihre Replays in den Ordner von Matte 1.

Also: Platzhalter statt fester Werte. Der Befehl trägt {matte}, jede Instanz setzt ihre eigene Nummer ein:

An alle:   D:\Replay Aufnahmen\Judo Matte {matte}
Matte 1 →  D:\Replay Aufnahmen\Judo Matte 1
Matte 2 →  D:\Replay Aufnahmen\Judo Matte 2

Gebraucht werden mindestens {matte}, {tag} und {event}. Woher die Instanz ihre Nummer kennt, muss festgelegt werden — aus dem Namen der Szenensammlung, aus dem Rechnernamen oder aus einer Angabe in der Verbindung.

Zwei Arten von Werten, die man nicht verwechseln darf:

Der Stream-Key ist der gefährlichste Fall. Vier Instanzen mit demselben Key senden alle auf denselben YouTube-Stream — drei Matten sind dann weg, und zwar sofort. Felder dieser Art gehören gesperrt für Global-Befehle, außer sie enthalten einen Platzhalter. Nicht als Warnung, sondern als Sperre.

Vorschau vor dem Senden. Die Oberfläche zeigt je ausgewählter Instanz, welcher Wert dort ankommt — ausgeschrieben, mit eingesetzten Platzhaltern. Wer das sieht, erkennt den Austrian-Cup-Fehler in einer Sekunde.

Setup: Matten, Rechner, Geräte

Wie im Dashboard: ein Setup, das der JEM vorgeben kann — und das sich von Hand anpassen oder ganz neu anlegen lässt.

Darin steht je Matte, welcher Rechner sie fährt und welche Geräte daran hängen. Daraus ergibt sich alles Weitere: die Zuordnung Instanz ↔ Matte, die Einsetzung von {matte}, und welche Quellen es auf dieser Matte überhaupt gibt.

Keine feste Mattenzahl. Vier war der Austrian Cup; ein Ligakampftag hat eine, das JTFO-Herbstfinale hatte neun. Die Zahl kommt aus dem Setup oder aus der Bridge — nirgends im Programm.

Damit ist auch geklärt, woher die Mattennummer kommt: aus dem Setup, nicht aus der Instanz. Die Instanz muss nichts über sich wissen; die Zentrale weiß, mit wem sie spricht.

Vorgabe aus dem JEM — Bridge oder JSON

Derselbe Weg wie beim Dashboard — nicht ein zweiter danebengebaut:

1. Bridge-Pull. Der Capt-Server holt die Konfiguration aus dem Event-Manager (capt_export.php, Schema judo-capt-config). Dort stehen bereits mats (Mattenzahl), channels[] (je Matte Kanal und Video-Kennung) und device_counts (Hallenkameras, Mikrofone, Zusatzkameras). Seit 04.10. zusätzlich shlink mit den Kurzlinks.
2. JSON-Import. Dieselbe Antwort als Datei einspielen — für den Fall, dass in der Halle kein Internet ist. Läuft durch dieselbe Verarbeitung.
3. Von Hand. Setup anlegen oder ändern, ohne JEM. Muss vollständig möglich sein, nicht als Notbehelf.

Was in der Bridge noch fehlt: der Rechnername je Matte. Den kennt der JEM nicht — er kommt aus dem Setup vor Ort und bleibt dort. Beim nächsten Pull darf er nicht überschrieben werden.

Daraus folgt eine Regel für den Pull: Was der JEM weiß (Mattenzahl, Keys, Geräte), kommt von dort. Was nur vor Ort bekannt ist (Rechnernamen, Ports, Passwörter), bleibt stehen. Ein Pull, der die örtliche Einrichtung mitlöscht, wird nach einmal Ärger nie wieder benutzt.

Was vorher zu klären ist

Was vor dem Bauen geklärt sein muss:

Anmeldung. obs-websocket v5 verlangt ein Passwort und rechnet eine Prüfsumme über eine Zufallszahl. In allen Paketen steht dasselbe Passwort — bequem, aber jeder im Hallennetz kann damit auf jede Instanz. Für ein geschlossenes Netz vertretbar; es gehört trotzdem entschieden, nicht nebenbei festgelegt.

Erreichbarkeit. Die Instanzen heißen LAPTOP-STREAM-1 bis -4. Namensauflösung im Hallennetz oder feste Adressen? Wenn der Name mal nicht geht, muss die Oberfläche das sagen und nicht endlos warten.

Teiltreffer. Was ist, wenn ein Befehl an drei Matten ankommt und an der vierten nicht? Das darf nicht aussehen wie Erfolg. Je Matte eine Rückmeldung, und wer nicht geantwortet hat, steht rot da.

Schutz im laufenden Betrieb. Eine Transformation an allen vier Matten gleichzeitig ist im Zweifel ein Fehler, der alle vier trifft. Für Eingriffe, die das Bild verändern, braucht es eine Rückfrage — und für die, die eine sendende Matte stören könnten, die Warnung, dass sie gerade sendet.

Rückweg. Vor jeder Änderung den alten Wert lesen und merken. Ein Knopf „zurück" ist am Turniertag mehr wert als jede Vorschau.

Was wir heute haben

Gelesen aus LeitungsTester.zip (Dropbox, 01 - Livestreams Aktuell). PowerShell mit Oberfläche, Fassung 22.2 „Event-Stable", 414 Zeilen, dazu speedtest.exe und ein eigenes ffmpeg.exe (83 MB).

Zwei Messungen, und die zweite ist die wertvolle:

1. Leitungstest — speedtest.exe, drei Läufe mit je 15 s Pause, daraus der Mittelwert für Ping, Download und Upload. Das sagt, was die Leitung grundsätzlich hergibt.
2. Pre-Flight — holt über die YouTube-API die echten Stream-Schlüssel des Kanals (liveStreams) und startet je Matte einen ffmpeg-Prozess, der wirklich sendet. Das ist kein Rechenexempel, sondern der Ernstfall ohne Publikum.

Event-Profile liegen als JSON daneben — ITG-2025.json etwa mit Mattenzahl, Infokanal und den geplanten Bitraten. Die Protokolle je Kanal (ffmpeg_logs/Matte_1_100818.log …) zeigen einen Lauf mit neun Matten plus Infokanal.

Warum das Werkzeug zählt: Es beantwortet vor dem Turnier die Frage, die sonst erst beim ersten Kampf auffällt — trägt diese Halle, was wir vorhaben? Und es beantwortet sie mit echten Streams auf dem echten Kanal.

Zugangsdaten im Klartext

In config.json stehen Zugangsdaten im Klartext: OAuth-Client-Kennung und -Geheimnis, ein OAuth-Refresh-Token, der YouTube-API-Schlüssel und der Shlink-API-Schlüssel.

Ein Refresh-Token ist kein Passwort auf Zeit — damit lässt sich dauerhaft ein neues Zugangsmerkmal holen. Wer die Datei hat, kann auf dem Kanal senden.

Das Paket liegt derzeit offen in der Dropbox. Das ist kein Weltuntergang und war im geschlossenen Kreis praktikabel — aber bevor das Werkzeug in die Werkzeugsammlung wandert und dabei kopiert wird, gehört geklärt: Wer bekommt die Datei, und reicht statt des Refresh-Tokens nicht ein Stream-Schlüssel aus dem JEM?

Mein Vorschlag: Die Schlüssel kommen aus dem Event-Manager, wo sie ohnehin gepflegt werden (yt_stream_keys, event_streams). Dann braucht der Leitungstester keinen eigenen Zugang zur YouTube-API — und die Datei verliert ihre Brisanz.

Wie es in die Werkzeuge kommt

Das Werkzeug bleibt lokal. Es misst die Leitung an dem Ort, an dem gestreamt wird, und sendet dafür echte Daten — vom Server aus ist beides sinnlos. Dieselbe Lage wie beim Verbindungsmanager.

Was dazukommen soll:

• Ausliefern über den Baukasten, wie beim Netz-Werkzeug: vorab einrichten, als Paket ziehen, am Zielrechner auspacken. Dann liegt nicht auf jedem Laptop eine andere Fassung.
• Ergebnisse auf den Server. Heute bleibt die Messung im Fenster und in lokalen Protokollen. Sie gehört zum Event — Datum, Halle, Mattenzahl, gemessener Upload, Ergebnis des Pre-Flight. Dann lässt sich beim nächsten Mal nachsehen, was diese Halle letztes Jahr hergab.
• Profil aus dem JEM. Mattenzahl, Infokanal und Bitraten stehen dort schon. Ein Event auswählen statt ein JSON von Hand anlegen.
• Später: Fernstart über denselben Befehlsweg wie der AVI-Mover (Punkt 1). Dann lässt sich die Messung aus der Stream-Regie anstoßen.

Was ausdrücklich nicht dazukommt: eine Bewertung der gemessenen Werte. Das Werkzeug misst und zeigt; ob eine Leitung für neun Matten reicht, entscheidet Gernot.