CoPilot Github: Stream fex 3

doc/05_screenShot_roadmap.md

@@ -66,11 +66,13 @@ Kamera  ──live 1920×1080──►  getFrame()  →  JPEG 1920×1080
 
 ```
 1. Live-FFmpeg SIGTERM → warte auf close (= FD frei)
-2. sleep(300ms)  ← v4l2-Buffer leeren, Kamera-Reset abwarten
-3. hires-FFmpeg bei hiresSize/hiresFps starten
-4. Frames warmlaufen lassen (settleFrames=6) + minWidth-Check (90 % der Soll-Breite)
-5. Ersten validen Frame nehmen → hires-FFmpeg SIGTERM
-6. finally: Live-FFmpeg neu starten (immer, auch bei Fehler)
+2. sleep(800ms)  ← Kamera-/Treiberreset, Puffer auslaufen lassen
+3. optional: 1280x720-Warmup-Format öffnen
+4. sleep(500ms)  ← Warmup/Formatwechsel stabilisieren
+5. hires-FFmpeg bei hiresSize/hiresFps starten
+6. Frames warmlaufen lassen (settleFrames=6) + minWidth-Check (90 % der Soll-Breite)
+7. Ersten validen Frame nehmen → hires-FFmpeg SIGTERM
+8. finally: Live-FFmpeg neu starten (immer, auch bei Fehler)
 ```
 
 **Blackout:** Der `<img>` friert ~2–3 s ein und läuft danach weiter. Kein Client-Handling nötig.
@@ -79,6 +81,45 @@ Kamera  ──live 1920×1080──►  getFrame()  →  JPEG 1920×1080
 Damit werden Frames abgelehnt, die noch auf der alten Live-Auflösung liegen
 (v4l2-Buffer-Reste vom vorherigen Format).
 
+**FFmpeg-Probe:** Für das finale hires-Open werden jetzt zusätzliche Probe-Parameter
+gesetzt (`-probesize 5000000`, `-analyzeduration 1000000`), um das MJPEG-Format
+und die Kameraparameter sicherer zu erkennen.
+
+---
+
+## Aktueller Ablauf des HD-Grabs
+
+Der aktuelle Ablauf ist bewusst defensiv:
+- Live-Stream beenden und auf FFmpeg-`close` warten.
+- 800 ms Pause zum Zurücksetzen des Kameratreibers.
+- Wenn liveSize deutlich kleiner als hiresSize ist, zunächst ein Zwischenformat
+  `1280x720` starten und kurz einlaufen lassen.
+- 500 ms warten, damit das Gerät in den neuen Auflösungsmodus umschaltet.
+- Hires-Stream starten, mehrere Frames puffern und den ersten validen Frame
+  mit genügend Bytes und Breite auswählen.
+- Hires-Stream beenden, Live-Stream neu starten.
+
+### Log- und Fehlerbild
+
+Aktuelle Log-Meldungen zeigen typische MJPEG/Treiber-Phänomene:
+- `unable to decode APP fields`: meist kosmetisch beim MJPEG-Parser, häufig bei
+  UVC-Webcams. Das bedeutet nicht zwingend einen fehlgeschlagenen Grab.
+- `input is truncated` / `Error applying bitstream filters`: kann auftreten, wenn
+  FFmpeg beim Beenden gerade ein MJPEG-Paket verarbeitet. Das ist ein Hinweis auf
+  einen abrupten Stream-Abbruch, nicht zwingend auf ein ungültiges Bild.
+- `Could not find codec parameters ... unspecified pixel format`: deutet darauf hin,
+  dass der neue HD-Stream noch nicht sauber genug erkannt wurde. Deshalb nutzen
+  wir jetzt größere Probe-Parameter.
+
+### Mögliche Ursachen
+
+- Treiberzustand der Kamera nach einem schnellen Formatwechsel: der C920 kann
+  noch Frames aus dem alten Modus liefern oder zwischen `640×480` und `1920×1080`
+  in einen inkonsistenten Zustand kommen.
+- MJPEG-Frames ohne vollständige JPEG-Header oder Huffman-Tabellen, die erst durch
+  `mjpeg2jpeg` ergänzt werden.
+- Abrupte Beendigung des `ffmpeg`-Prozesses während eines laufenden MJPEG-Pakets.
+
 ---
 
 ## Kamera-spezifische Konfiguration
@@ -140,6 +181,8 @@ v4l2-ctl --list-formats-ext -d /dev/videoN | grep -A 20 MJPG
 |---|---|---|
 | Stream friert selten dauerhaft ein | niedrig | Einzelfall; clientseitiger Watchdog (Frame-Timeout → `img.src` neu) noch nicht implementiert |
 | `unable to decode APP fields` im Log (C270) | kosmetisch | Einmalige Probe-Warnung von FFmpeg, kein Auswirkung |
+| `input is truncated` / `Error applying bitstream filters` beim HD-Grab | mittel | Hinweis auf abrupten Stream-Abbruch beim Formatwechsel; Bild kann dennoch gültig sein |
+| `Could not find codec parameters ... unspecified pixel format` | mittel | Zeichen für unvollständige FFmpeg-Probe nach Formatwechsel; größere probe-Parameter helfen |
 
 ---