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.

docker-compose.yaml

@@ -25,15 +25,13 @@ configs:
     # Komplette go2rtc-Config eingebettet – keine separate Datei nötig.
     content: |
       streams:
-        # MJPEG-Passthrough: Kamera → go2rtc → Browser, kein Encoding.
-        # video_size = Aufnahme-Auflösung = Snapshot-Auflösung.
-        # Browser zeigt 640x480 (CSS), Snapshot liefert volle video_size.
-        # Kamera-Maximalauflösung prüfen: v4l2-ctl --list-formats-ext -d /dev/video0
-        # Gängige Werte: 640x480 / 1280x720 / 1280x960 / 1920x1080
-        cam0: "ffmpeg:device?video=/dev/video0&input_format=mjpeg&video_size=1280x960&framerate=15#video=mjpeg"
-        cam1: "ffmpeg:device?video=/dev/video2&input_format=mjpeg&video_size=1280x960&framerate=15#video=mjpeg"
-        # Falls 1280x960 nicht unterstützt → 1280x720 versuchen, dann 640x480.
-        # Framerate auf 15fps reduziert da hi-res MJPEG mehr USB-Bandbreite braucht.
+        # MJPEG-Passthrough: Kamera liefert MJPEG nativ → go2rtc reicht es 1:1 durch.
+        # Kein Encoding, kein libx264, kein VAAPI → CPU <5%, keine Freezes.
+        # Latenz ~200ms (vs. 130ms bei H.264) — für Roboter-Überwachung ausreichend.
+        # Hinweis: go2rtc's #hardware funktioniert NICHT mit MJPEG-Kamera-Input
+        # (hwupload benötigt VAAPI-Decoder auf Input-Seite, MJPEG läuft Software).
+        cam0: "ffmpeg:device?video=/dev/video0&input_format=mjpeg&video_size=640x480&framerate=30#video=mjpeg"
+        cam1: "ffmpeg:device?video=/dev/video2&input_format=mjpeg&video_size=640x480&framerate=30#video=mjpeg"
       webrtc:
         listen: ":8555"
         candidates: