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

frontend/src/components/StreamTab.vue

@@ -36,8 +36,10 @@ function verbinden() {
     // führt laut Doku zu Stockern.
     liveMaxLatencyDuration: ZIEL_LATENZ + 3,
     // Über 1 erlaubt hls.js, die Geschwindigkeit anzuheben, um die
-    // Ziel-Latenz zu halten. Standard ist 1, also aus.
-    maxLiveSyncPlaybackRate: 1.5,
+    // Ziel-Latenz zu halten. 1,5 wäre deutlich hörbar, wenn der Player sie
+    // ausreizt; 1,1 reicht für normale Schwankungen und fällt nicht auf.
+    // Bleibt der Rückstand größer, springt liveMaxLatencyDuration ohnehin.
+    maxLiveSyncPlaybackRate: 1.1,
     backBufferLength: 30,
   })