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

ohne ScreenShot stabil

Browse Source
This commit is contained in:
chk
2026-06-04 17:16:06 +02:00
parent 1252a5dc10
commit 0bcd583b6d
2 changed files with 37 additions and 40 deletions
Download Patch File Download Diff File Expand all files Collapse all files

19
docker-compose.yaml
View File

@@ -25,20 +25,11 @@ configs:
go2rtc_yaml:
content: |
streams:
# ── 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):
# Stabiler Stand: beide Kameras 640x480 MJPEG, Re-Encode in go2rtc
# (~50% CPU gesamt für 2 Kameras), keine Freezes, ~200ms. Viewer: MODE='mjpeg'.
# NICHT #video=copy verwenden: am 2026-06-04 getestet → CPU 50% → 107%
# (schlechter, Grund ungeklärt). Verworfen.
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"