Claude: Button

doc/01_WebcamRoadmap.md

@@ -65,11 +65,11 @@ Encoding, ICE-Negotiation, robuster Client mit Auto-Fallback (WebRTC→MSE→MJP
 - [x] Stabile Snapshot-API `/api/snapshot/cam{n}`
 - [x] Auflösung fest 640×480 → Latenz „akzeptabel" (war vorher das Hauptproblem)
 
-### Phase 3 – Latenz final tunen (offen)
-- [ ] Messvergleich WebRTC ⟷ MJPEG durchführen → siehe `03_Protocoll_roadmap.md`
-- [ ] Falls nötig: Auflösung 320×240 testen (kleiner = weniger Browser-Last)
-- [ ] Falls nötig: Keyframe-Intervall senken (`-g 15`), zerolatency-Tuning
-- [ ] Prüfen ob Kamera natives H.264 liefert (`v4l2-ctl --list-formats`) → kein Re-Encode
+### Phase 3 – Latenz final tunen ✅
+- [x] Messvergleich WebRTC ⟷ MJPEG: **WebRTC ~130 ms, MJPEG ~200 ms** → WebRTC gewinnt
+- [x] Entscheid: bei WebRTC bleiben (niedrigere Latenz + besser für Internet)
+- [ ] Optional: Prüfen ob Kamera natives H.264 liefert (`v4l2-ctl --list-formats`) → kein Re-Encode
+- [ ] Optional: Keyframe-Intervall / Encoder-Preset tunen wenn <100 ms gefordert
 
 ### Phase 4 – Internet-Härtung (offen, vor Produktiv-Schaltung)
 - [ ] **TLS via Caddy** – empfohlen, weil Caddy WebSocket-Proxy nativ und zuverlässig kann.

doc/03_Protocoll_roadmap.md

@@ -56,12 +56,15 @@ direkt im Browser öffnen (für cam1: `cam0` → `cam1` ersetzen):
    gleichzeitig zeigt (Handy + Monitor zusammen abfotografieren ist am einfachsten).
 4. Differenz „echte Zeit ↔ Bild im Stream" ablesen = Gesamt-Latenz pro Protokoll.
 
-### Ergebnis-Tabelle (später ausfüllen)
+### Ergebnis-Tabelle ✅ gemessen 2026-06-03
 
-| Kamera | MJPEG roh | WebRTC | MSE | Sieger |
-|--------|-----------|--------|-----|--------|
-| cam0   |    ?  ms  |  ? ms  | ? ms |   ?   |
-| cam1   |    ?  ms  |  ? ms  | ? ms |   ?   |
+Methode: Handy-Stoppuhr (ms) vor Kamera, Foto von Monitor + Stoppuhr.
+
+| Kamera | MJPEG | WebRTC | MSE | Sieger |
+|--------|-------|--------|-----|--------|
+| cam0+1 | ~200 ms | ~130 ms | — | **WebRTC** |
+
+MSE nicht gemessen (erwartet schlechter als beide, für Live nicht relevant).
 
 ---