From 1252a5dc10b965593e1075472519e66986825f56 Mon Sep 17 00:00:00 2001 From: chk <79915315+ChKendel@users.noreply.github.com> Date: Thu, 4 Jun 2026 16:52:59 +0200 Subject: [PATCH] Claude: ScreenShot v3 --- docker-compose.yaml | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git a/docker-compose.yaml b/docker-compose.yaml index b2d3ab0..52517d9 100644 --- a/docker-compose.yaml +++ b/docker-compose.yaml @@ -25,9 +25,20 @@ configs: go2rtc_yaml: content: | streams: - # 640x480 @ 30fps – stabiler Live-Stream, <5% CPU, ~200ms Latenz. - # Hi-Res-Snapshots über /api/snapshot/cam{n}/hires (Node.js Blackout-Methode). - cam0: "ffmpeg:device?video=/dev/video0&input_format=mjpeg&video_size=640x480&framerate=30#video=mjpeg" + # ── COPY-TEST (2026-06-04) · nur cam0 ──────────────────────────────── + # Frage: Kann go2rtc die Kamera-MJPEG DURCHREICHEN (#video=copy) statt sie + # zu re-encodieren (#video=mjpeg, aktuell ~50% CPU für 2 Kameras)? + # Geht es → cam0 zeigt Bild UND go2rtc-Gesamt-CPU fällt deutlich + # (cam0 encodiert nicht mehr): grob ~50% → ~25-30%. + # Geht es NICHT → cam0 bleibt schwarz / Log "mjpeg eof" (bekanntes go2rtc- + # Problem #747 bei USB-MJPEG). Dann cam0-Zeile zurücktauschen. + # WICHTIG: Das ist eine Config-Änderung + Redeploy (sauberer Neustart, EIN + # Producer) — KEINE Laufzeit-API-Mutation. Der 107%-Vorfall kann so nicht passieren. + # + # ROLLBACK cam0 (bekannt gut, ~50% aber stabil) — diese Zeile wieder aktiv setzen: + # cam0: "ffmpeg:device?video=/dev/video0&input_format=mjpeg&video_size=640x480&framerate=30#video=mjpeg" + cam0: "ffmpeg:device?video=/dev/video0&input_format=mjpeg&video_size=640x480&framerate=30#video=copy" + # cam1 bleibt Re-Encode = bekannter guter Stand (Kontrolle + Sicherheitsnetz): cam1: "ffmpeg:device?video=/dev/video2&input_format=mjpeg&video_size=640x480&framerate=30#video=mjpeg" webrtc: listen: ":8555"