ohne ScreenShot stabil

doc/04_Delay_roadmap.md

@@ -464,11 +464,17 @@ neu) + `docker restart AppRobotWebcam` (lädt zurückgesetzten Code).
 | 3 | Externer FFmpeg parallel zu go2rtc auf demselben Gerät | „device busy" → `exit 1`: Live-Viewer reconnectet, go2rtc greift das Gerät zurück, bevor der externe FFmpeg es öffnen kann | **Eine USB-Kamera = ein Öffner.** Zwei Prozesse können sie nicht teilen. |
 | 4 | **PATCH zum Umschalten der Live-Quelle** (auf laufendem cam0) | go2rtc's PATCH **ersetzt nicht — es hängt an** → cam0 lief 640 **und** 1280 gleichzeitig → **CPU 107%, Live-Stream beschädigt** | **NIE den Live-Producer im Betrieb mutieren, ohne das Verhalten vorher auf einem Wegwerf-Stream getestet zu haben.** |
 | 5 | „Verifiziert" behauptet, obwohl nur Syntax + JPEG-Parser geprüft | Die **tragende** Annahme (PATCH-Verhalten) war ungeprüft — und wurde trotzdem auf cam0 ausgeliefert | „Peripherie geprüft" ≠ „die sicherheitskritische Annahme geprüft". |
+| 6 | `#video=copy` (Passthrough) auf cam0 getestet, Vorhersage „senkt CPU" | **Gegenteil: 50% → 107%** (Grund ungeklärt). cam0 zeigte Bild, kein „mjpeg eof" → Producer lief, nur teurer | Vorhersagen sind keine Daten. `#video=copy` ist auf dieser Kamera empirisch tot. |
+| 7 | Diese 107% vorschnell als „WebRTC-Transcode" gedeutet | Falsch — Viewer stand auf „MJPEG live". Wieder geraten statt den Fakt zu holen | Bei unerwartetem Ergebnis erst messen *was wirklich läuft*, keine Story erfinden. |
 
 ### Eiserne Regeln (daraus)
 
 1. **Der Snapshot-Pfad ist READ-ONLY gegenüber go2rtc.** Nur `GET /api/frame.jpeg`. Niemals `PUT`/`PATCH`/`DELETE` auf cam0/cam1 im laufenden Betrieb.
-2. **go2rtc-API-Verhalten wird auf einem Wegwerf-Stream verifiziert**, bevor es eine echte Kamera berührt — nie angenommen.
+2. **Laufzeit-API-Mutationen (`PATCH`/`PUT`/`DELETE`) auf cam0/cam1 sind verboten.**
+   go2rtc-API-Verhalten zuerst auf einem Wegwerf-Stream verifizieren. Eine reine
+   **Config-Änderung + Redeploy** an einer echten Kamera ist dagegen ok, wenn (a) eine
+   Rollback-Zeile in der Datei steht und (b) die andere Kamera auf dem bekannten guten
+   Stand bleibt — so wurde der Copy-Test gefahrlos und reversibel gemacht.
 3. **„Verifiziert" = die sicherheitskritische Annahme wurde getestet** — nicht nur die Syntax drumherum.
 4. **Der Live-Stream hat absolute Priorität.** Im Zweifel lieber kein Feature als ein wackliger Live-Stream.
 
@@ -488,32 +494,32 @@ einem one-shot FFmpeg ab. Da es ein **anderes Gerät** ist, kann das den Live-St
 am besten an eigenem USB-Controller, damit der kurze Grab die Live-Kameras nicht drosselt).
 → **Die einzige Lösung, die ich zu 100 % garantieren kann.**
 
-**Weg C — Live dauerhaft in 1280×960, Browser skaliert per CSS auf 640, Snapshot = der
-bestehende read-only `frame.jpeg`-Grab (dann schon 1280).**
-Der Snapshot-Mechanismus ist hier **garantiert sicher** (read-only, keine Mutation des
-Streams — kann den CPU-Vorfall nicht auslösen). Offen ist **nicht die Korrektheit,
-sondern der Preis**: Dauerbetrieb 1280 kostet CPU + Bandbreite. Hängt am ungeklärten
-Hebel **„kann go2rtc echtes `-c:v copy`?"**:
-- Wenn ja → 1280 ist CPU-billig (nur mehr Bytes), Snapshot „gratis", elegant.
-- Wenn nein → 1280-Re-Encode ist teuer (vgl. gemessene 53 % / 127 %).
-- **Dieser Hebel ist UNVERIFIZIERT → zwingend zuerst auf einem Wegwerf-Stream prüfen, nie auf cam0.**
+**Weg C — Live dauerhaft 1280×960, Browser skaliert auf 640, Snapshot = read-only
+`frame.jpeg` (dann schon 1280). → ❌ VERWORFEN (getestet).**
+Der Snapshot-Mechanismus wäre sicher (read-only). Der Preis hing daran, ob go2rtc echtes
+Passthrough kann. **Getestet 2026-06-04** (config-basiert auf cam0, reversibel, cam1 als
+Sicherheitsnetz): `#video=copy` machte die CPU **schlechter (50% → 107%)**, nicht besser —
+Grund ungeklärt (cam0 zeigte Bild, kein „mjpeg eof", Producer lief, nur teurer). Damit ist
+die billige Variante tot; bliebe nur 1280-Re-Encode (53 % / 127 % — für Dauerbetrieb zu
+teuer). **Weg C ist kein gangbarer Weg.**
 
-**Wovon ich NICHT sicher bin:** dass sich die *eine* Live-Kamera on-demand sicher
-zwischen 640 und 1280 umschalten lässt. Das ginge allenfalls über ein **vollständiges
-Replace (DELETE + PUT, nicht PATCH)** mit Grab über go2rtcs `frame.jpeg` — aber nur nach
-Verifikation auf einem Test-Stream. Ohne diese Verifikation: **kein Versprechen.**
+**Ebenfalls ausgeschlossen:** On-Demand-Umschalten der *einen* Live-Kamera zwischen 640
+und 1280. Über `PATCH` hat es den Live-Stream zerstört (107%); ein „sauberes" Replace
+(DELETE+PUT) bliebe riskant. **Kein Versprechen, wird nicht weiterverfolgt.**
 
-### Nächster gefahrloser Schritt (wenn Hi-Res wieder dran ist)
+### Fazit & Empfehlung (2026-06-04, Stand nach allen Tests)
 
-Auf einem **Wegwerf-Stream** `test` (separate Kamera oder Test-Datei, **nicht** cam0)
-verifizieren — der Live-Stream wird dabei nicht berührt:
-1. Kann go2rtc `-c:v copy` (echtes Passthrough, ~0 % CPU bei beliebiger Auflösung)? → entscheidet Weg C.
-2. Wie verhalten sich `PATCH` und `DELETE`+`PUT` wirklich (ersetzen vs. anhängen, Geräte-Freigabe)?
+- **Live-Stream: fertig und stabil.** 640×480 MJPEG, ~50 % CPU, keine Freezes, ~200 ms.
+  Dabei bleiben — nicht ohne konkreten Grund anfassen.
+- **Hi-Res billig & ohne Hardware: ausgeschlossen.** Copy-Passthrough getestet → schlechter
+  (Weg C tot). Umschalten der einen Kamera → gefährlich (107%-Vorfall). 1280-Dauerbetrieb → zu teuer.
+- **Verlässliches Hi-Res ⇒ Weg A (separate Kamera).** Einzige Lösung, die den Live-Stream
+  physisch nicht berühren kann.
+- **Kein Hardware-Budget ⇒ vorerst kein Hi-Res.** Beim stabilen 640er-Snapshot
+  (`/api/snapshot/cam{n}`) bleiben.
 
-Erst wenn das **belegt** ist, cam0 anfassen. Bis dahin ist der read-only 640er-Snapshot
-(`/api/snapshot/cam{n}`) der stabile Stand.
-
-### Empfehlung
-
-- **Budget für Hardware vorhanden → Weg A.** Sauberste, garantierte Lösung, kein Risiko für den Live-Stream.
-- **Kein Hardware-Budget → erst den `-c:v copy`-Hebel auf einem Test-Stream verifizieren.** Geht er → Weg C. Geht er nicht → mit dem 1280-Preis leben oder doch Weg A.
+**Weg A konkret, wenn es so weit ist:** separate USB-Kamera, möglichst an eigenem
+USB-Controller; in go2rtc **nicht** als Stream einbinden; Node greift sie on-demand per
+one-shot FFmpeg ab, z. B.:
+`ffmpeg -f v4l2 -input_format mjpeg -video_size 1280x960 -i /dev/videoN -frames:v 1 -q:v 2 out.jpg`.
+Getrenntes Gerät + read-only gegenüber go2rtc → kann mit dem Live-Stream nicht kollidieren.