Stream: Rechenlast des Proxys senken

Ein Zuschauer erzeugt rund zwanzig Anfragen je Sekunde. Bisher baute der
Proxy dafür jedes Mal eine neue Verbindung auf, holte die Antwort komplett
in den Speicher und schickte sie durch gzip — obwohl Videosegmente bereits
komprimiert sind. Gemessen: 47-67 % CPU für einen einzigen Zuschauer.

Jetzt ein gemeinsamer Client mit offenen Verbindungen, die Daten fließen
stückweise durch, und /stream bleibt von der Kompression verschont. Dazu
protokolliert die App die Stream-Anfragen nicht mehr einzeln; das waren
410 Zeilen je Minute bei einem Zuschauer.

Ergebnis: 11,5 % statt 47-67 %. Mit fünfzehn Zuschauern liegt die Last bei
150 % von 400 % verfügbarer Rechenzeit.

Dazu am Rand:
- hlsAlwaysRemux hält den Muxer durchgehend offen. Vorher riss er 60 s nach
  dem letzten Zuschauer ab und setzte beim Neuaufbau die Zeitbasis zurück.
- hlsAllowOrigin ist veraltet und heißt jetzt hlsAllowOrigins.
- Der Player holt höchstens mit 1,1-fachem Tempo auf statt mit 1,5. Das
  reicht für normale Schwankungen und bleibt unhörbar.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013XVnRop5c3or3B8xE2hpgZ

mediamtx/mediamtx.yml

@@ -9,7 +9,13 @@ hlsSegmentCount: 7
 hlsSegmentDuration: 1s
 hlsPartDuration: 200ms
 # Die Seite reicht den Stream unter eigenem Ursprung durch
-hlsAllowOrigin: '*'
+hlsAllowOrigins: ['*']
+
+# Ohne das baut MediaMTX den Muxer erst auf, wenn der erste Zuschauer
+# fragt — und reißt ihn 60s nach dem letzten wieder ab. Jeder Neuaufbau
+# setzt die Zeitbasis zurück; wer dazukommt, während gerade keiner schaut,
+# wartet auf den Aufbau. Durchlaufend sehen alle dieselbe Stelle.
+hlsAlwaysRemux: yes
 
 rtmp: yes
 rtmpAddress: :1935