miese Auflösung, läuft

doc/04_Delay_roadmap.md

@@ -169,13 +169,44 @@ Aufwand: ~2h (zusätzlicher Container, RTSP-Verkabelung). Lohnt sich erst wenn
 
 ---
 
-## Hi-Res-Snapshots
+## Hi-Res-Snapshots — offenes Problem
 
-Snapshot-Auflösung = Stream-Auflösung (USB-Kamera kann nur in einer Auflösung
-gleichzeitig geöffnet sein).
+### Warum es nicht trivial ist
 
-Bei **Lösung 1** (Hardware H.264): Stream hochauflösend konfigurieren, Browser
-skaliert herunter. `/api/frame.jpeg` liefert H.264-Frame (leicht verlustbehaftet).
-Beste Qualität: zusätzlich `#video=mjpeg` für Snapshot-Track (wenn GPU übrig hat).
+Eine USB-Kamera kann gleichzeitig nur **eine** Auflösung liefern.
+go2rtc hält die Kamera offen — Snapshot-Auflösung = Stream-Auflösung.
 
-Bei **Lösung 2** (MJPEG): `/api/frame.jpeg` = natives Kamera-JPEG, volle Qualität, gratis.
+Versuch: `video_size=1280x960` im laufenden Stream → CPU sprang auf 112%.
+Ursache unklar (vermutlich MJPEG-Frames 4× grösser → mehr I/O-Last in go2rtc).
+**Zurückgesetzt auf stabilen Zustand: 640x480 @ 30fps, ~20% CPU.**
+
+### Drei Optionen (noch nicht umgesetzt)
+
+**Option 1 — Hi-Res-Stream + CSS-Skalierung im Browser**
+- Stream auf 1280x720 oder 1280x960 setzen
+- Browser zeigt 640x480 (CSS), Snapshot = volle Auflösung
+- Problem: CPU-Last beim Hochskalieren steigt (s.o.)
+- Lösung: erst `v4l2-ctl --list-formats-ext -d /dev/video0` prüfen welche
+  MJPEG-Auflösungen die Kamera nativ unterstützt. Dann schrittweise testen:
+  640x480 → 1280x720 → 1280x960. CPU nach jedem Schritt messen.
+- Zeitaufwand: 30 min
+
+**Option 2 — Stream stoppen, Snapshot, Stream starten**
+- Node.js orchestriert: go2rtc-Stream stoppen → FFmpeg einmalig
+  `-frames:v 1` bei maximaler Auflösung → Bild speichern → Stream neu starten
+- Video-Blackout: ~1–2 Sekunden
+- CPU-Peak: kurz, dann zurück auf normal
+- Aufwand: ~2h (Node.js Orchestrierungslogik + go2rtc Stream-API)
+- Geeignet wenn Snapshots nur alle 10–30s gebraucht werden
+
+**Option 3 — Separate Kameras für Homing**
+- Zwei zusätzliche USB-Kameras, nur für Homing (kein Live-Stream)
+- go2rtc öffnet sie nicht → kein Konflikt, volle Auflösung on-demand
+- Aufwand: Hardware-Kosten + Montage + FFmpeg one-shot in Node.js
+- Sauberste Lösung langfristig
+
+### Empfehlung
+
+Option 1 zuerst, aber schrittweise mit CPU-Messung pro Auflösungsstufe.
+Option 2 wenn Blackout akzeptabel und Option 1 zu viel CPU braucht.
+Option 3 wenn Homing-Qualität kritisch und Budget vorhanden.