docs: Document simulcast middle layer and H.264 codec switch for calls

feat: Try H.264 codec for calls instead of VP8
H.264 uses classic simulcast (like VP8), not SVC, so it's compatible with the fork's simulcast-shaped publish options without needing a code fix - unlike VP9/AV1 (see the 2026-07-28 incident notes). Also tends to be hardware-accelerated on more devices, notably iOS/Safari. Server-side: LiveKit has no codec restriction configured, supports H.264 by default.
2026-07-28 12:00:00 +00:00 · 2026-07-28 12:00:00 +00:00 · 2026-07-28 12:00:00 +00:00
3 changed files with 15 additions and 6 deletions
@@ -74,7 +74,7 @@ spec:
      image:
        registry: rohana.axion1337.de
        repository: sorb/threadnet-web
-        tag: v0.2.1-elementcall-noquotavp9
+        tag: v0.2.3-elementcall-h264
      ingress:
        host: axion1337.chat

@@ -55,8 +55,10 @@ verankert. Was in dieser Session erledigt wurde:
   und danach committed. Nebenbei: `matrixRTC`-Authorisation-Service OOM-Fix (20Mi→128Mi).

 ### Offene Punkte
- **VP9-Retry**: Root Cause des Call-Ausfalls isolieren (Browser-Konsolen-Repro nötig), bevor
-  wieder versucht wird — siehe Backlog "Element Call Enhancement".
+- **VP9-Retry**: vermutete Ursache jetzt bekannt (LiveKit nutzt SVC für vp9/av1, Fork-Code
+  setzt aber immer Simulcast-Layer) — braucht einen Code-Fix in `buildPublishOptions()`
+  (`src/livekit/options.ts`) bevor erneut versucht wird. Stattdessen H.264 probiert (siehe
+  unten) — läuft gut, kein SVC-Risiko, hardwarebeschleunigt auf mehr Geräten.
 - **`ThreadNet-Web` Build-Bug**: `scripts/docker-link-repos.sh`/`docker-package.sh` nicht
  ausführbar committet + veralteter `matrix-js-sdk#develop`-Pin im Lockfile blockiert
  vollständigen Neu-Build des Web-Forks. Noch nicht gefixt, User hat noch nicht final
@@ -57,9 +57,16 @@
  LiveKits eigener Empfehlung für Mensch-zu-Mensch-Calls. Bewusst **kein** server-seitiges
  ML-Noise-Cancellation (siehe `docs/TASKS.md` Backlog).
 - **Incident (2026-07-28)**: Erster Versuch mit erzwungenem `video_codec: vp9` hat Calls
-  komplett kaputt gemacht (kein Bild/Ton). Sofort zurückgerollt, dann ohne erzwungenen Codec
-  (Standard VP8) mit denselben Auflösungswerten neu deployed — funktioniert, live bestätigt.
-  VP9 vorerst zurückgestellt (Backlog).
+  komplett kaputt gemacht (kein Bild/Ton). Sofort zurückgerollt. Vermutete Ursache: LiveKit
+  nutzt für vp9/av1 SVC statt klassischem Simulcast, `buildPublishOptions()` im Fork setzt
+  aber immer Simulcast-Layer — Code-Fix nötig, bevor vp9 erneut versucht wird (Backlog).
+- **720p-Zwischen-Layer ergänzt** (`simulcast_layers`) — ohne eigene Definition fiel die
+  Übertragung bei kleinsten Netzwerkschwankungen direkt von 1440p auf blockiges 360p, jetzt
+  sanftere Abstufung über 720p.
+- **H.264 statt VP8** (2026-07-28) — nutzt wie VP8 klassisches Simulcast (kein SVC-Risiko wie
+  bei VP9), zusätzlich auf vielen Geräten (v.a. iOS/Safari) hardwarebeschleunigt. Live
+  verifiziert: 7 von 8 Video-Tracks liefen über H.264, 1 fiel sauber auf den VP8-Backup-Codec
+  zurück (kein Ausfall). Deployed als `v0.2.3-elementcall-h264`.
 - Deployt als `rohana.axion1337.de/sorb/threadnet-web:v0.2.1-elementcall-noquotavp9` — nur
  der `/app/widgets/element-call/`-Ordner im bestehenden `v0.1.0`-Image ausgetauscht, da
  `ThreadNet-Web` einen vorbestehenden Build-Bug hat (siehe unten).