Ich hatte zwei Maschinen. Ein ThinkPad — Baujahr 2015, zwei Kerne, acht Gigabyte — mit einer angeschlossenen Akaso-Kamera. Und ein MacBook, auf dem OBS lief. Beide im selben Tailscale-Netz.

Die Aufgabe war klar: das Kamerabild durchs Netz führen und in OBS einspeisen.

Fünf Hindernisse tauchten auf. Jedes in einer anderen Schicht.

Der erste Versuch war der direkteste: Kamera aufnehmen, komprimieren, per UDP hinüberwerfen.

Die Pakete gingen los. Es kam nichts an.

UDP ist der Verkehr, den Firewalls und virtuelle Netze am wenigsten mögen. Statt zu suchen, wo er verlorenging, wechselten wir die Straße: TCP. SSH lief bereits über TCP, dieser Weg war also offen.

Umstieg auf TCP, Port geöffnet, Firewall-Regel hinzugefügt. Verbindung abgelehnt.

Der Grund war subtil. Beim Verbinden über SSH hatte der Benutzer Administratorrechte — aber die Sitzung war nicht erhöht. Unter Windows ist das nicht dasselbe. Die Firewall-Regel war stillschweigend fehlgeschlagen.

Statt die Mauer zu durchbrechen, umgingen wir sie vollständig: ein SSH-Tunnel. Wir schoben das Video durch einen Kanal, der bereits funktionierte.

Der Tunnel stand, ffmpeg startete und starb nach vier Sekunden.

Der Fehler war eindeutig: Echtzeitpuffer zu voll, Bild verworfen.

Da niemand etwas anderes gesagt hatte, war die Kamera auf ihren Standardwert zurückgefallen: 3840×2160. 4K in Echtzeit zu komprimieren ist nicht die Sache eines Zweikernprozessors von 2015.

Die Lösung bestand aus zwei Teilen. Wir fixierten die Auflösung auf 1920×1080. Und wir verlagerten die Komprimierung vom Prozessor in Intel Quick Sync — den Hardware-Encoder im Grafikchip.

Die Kamera konnte H.264 selbst erzeugen. Also, dachten wir, reichen wir es unverändert durch. Prozessorlast: null.

Die Gegenstelle konnte es nicht dekodieren. Das Protokoll wiederholte eine Zeile: Verweis auf nicht existierendes PPS 0.

Die Kamera setzte die Kopfdaten, die das Bild beschreiben — SPS und PPS — nicht an den Anfang des Stroms. Ein Videostrom ohne Kopfdaten ist ein Text ohne Alphabet.

Wir nahmen ihn als MJPEG und kodierten über Quick Sync neu. Ein Schritt mehr, aber die Kopfdaten saßen, wo sie hingehören.

Alles funktionierte. Das Bild kam. Dann verschwand es.

Ich prüfte: Der gestartete Prozess war weg. Das Fehlerprotokoll leer. Das Programm war nicht abgestürzt — es war getötet worden.

Die Ursache war SSH selbst. Unter Windows bindet eine SSH-Sitzung die von ihr gestarteten Prozesse an ein Job-Objekt; schließt die Sitzung, gehen die Kinder mit. Indem ich die Verbindung trennte, trennte ich auch die Kamera.

Wir machten aus dem Stream eine geplante Aufgabe. Sie hängt nicht mehr an einer Sitzung, lebt für sich und startet sich nach jedem Abbruch neu.

Das Bild kam. An meinem Schreibtisch sitzend sah ich mich auf meinem eigenen Bildschirm — doch dieses Bild hatte den Laptop neben mir verlassen, war durch einen verschlüsselten Tunnel gereist und zurückgekehrt.

Und hier war der eigentliche Befund: Ein zehn Jahre altes Zweikern-Notebook komprimiert 1080p30-Video, während sein Prozessor nahezu untätig bleibt. Dank Quick Sync. Ich hielt diese Maschine für schwach. Schwach waren meine Einstellungen.

Keines der fünf Hindernisse war eine Hardwaregrenze. Alle fünf waren Konfiguration, Protokoll und Verhalten des Betriebssystems.

Hätte ich eine neue, starke Maschine gekauft, wären alle fünf genauso aufgetreten.

Ein System zu bauen heißt nicht, starke Teile zu kaufen. Es heißt, eines nach dem anderen herauszufinden, warum die Teile sich weigern, miteinander zu sprechen.