ChK/appRobotWebcam
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Claude: ScreenShot v3

Browse Source
This commit is contained in:
chk
2026-06-04 16:52:59 +02:00
parent 1af16267f4
commit 1252a5dc10
1 changed files with 14 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

17
docker-compose.yaml
View File

@@ -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"