From f989e4f873cc0200aa7bef98070cb5e537a8b0c8 Mon Sep 17 00:00:00 2001
From: chk <79915315+ChKendel@users.noreply.github.com>
Date: Thu, 4 Jun 2026 06:13:20 +0200
Subject: [PATCH] Claude: Latenz

---
 docker-compose.yaml | 29 +++++++++++++++++------------
 1 file changed, 17 insertions(+), 12 deletions(-)

diff --git a/docker-compose.yaml b/docker-compose.yaml
index 32a7130..3c01440 100644
--- a/docker-compose.yaml
+++ b/docker-compose.yaml
@@ -25,19 +25,20 @@ configs:
     # Komplette go2rtc-Config eingebettet – keine separate Datei nötig.
     content: |
       streams:
-        # NUR #video=h264 (kein #video=mjpeg) → halbiert CPU-Last pro Kamera.
-        # go2rtc erzeugt intern: -preset superfast -tune zerolatency (gut).
-        # Standard-GOP: -g 50 = 1.67s @30fps. Für kürzeres GOP → exec: Source nötig (TODO).
+        # Option C — ffmpeg: mit expliziten Input-Flags, OHNE -re und OHNE -readrate_initial_burst.
+        # go2rtc ist on-demand: startet FFmpeg erst wenn ein Client verbindet (bestätigt: 0% CPU ohne Client).
+        #   -input_format mjpeg   → Kamera-natives MJPEG, kein Pixel-Decode nötig
+        #   -fflags nobuffer      → kein Input-Puffer
+        #   -flags low_delay      → minimaler Decoder-Delay
+        #   -probesize 32         → keine lange Format-Analyse beim Start
+        #   -analyzeduration 0    → sofortiger Start
+        # go2rtc übernimmt H.264-Encoding (-g 50 bleibt, aber ohne -re-Stau).
+        cam0: "ffmpeg:-f v4l2 -input_format mjpeg -video_size 640x480 -framerate 30 -fflags nobuffer -flags low_delay -probesize 32 -analyzeduration 0 -i /dev/video0#video=h264"
+        cam1: "ffmpeg:-f v4l2 -input_format mjpeg -video_size 640x480 -framerate 30 -fflags nobuffer -flags low_delay -probesize 32 -analyzeduration 0 -i /dev/video2#video=h264"
         #
-        # Variante A – Software-Encoding (immer kompatibel):
-        cam0: "ffmpeg:/dev/video0#video=h264"
-        cam1: "ffmpeg:/dev/video2#video=h264"
-        #
-        # Variante B – Hardware-Encoding (Intel QuickSync / VAAPI, falls vorhanden):
-        # Drastisch weniger CPU-Last. Aktivieren wenn "Variante A" CPU-Bottleneck zeigt.
-        # Braucht: /dev/dri/renderD128 im Container (devices: unten ergänzen)
-        # cam0: "ffmpeg:/dev/video0#video=h264#hardware"
-        # cam1: "ffmpeg:/dev/video2#video=h264#hardware"
+        # Option B – Hardware-Encoding (nächster Schritt falls CPU noch zu hoch):
+        # cam0: "ffmpeg:-f v4l2 -input_format mjpeg -video_size 640x480 -framerate 30 -fflags nobuffer -flags low_delay -i /dev/video0#video=h264#hardware"
+        # cam1: "ffmpeg:-f v4l2 -input_format mjpeg -video_size 640x480 -framerate 30 -fflags nobuffer -flags low_delay -i /dev/video2#video=h264#hardware"
       webrtc:
         listen: ":8555"
         candidates:
@@ -53,6 +54,10 @@ configs:
         origin: "*"
       log:
         level: info
+      # TODO (on-demand Encoding): go2rtc hält den Encoder auch ohne Clients am Laufen.
+      # Das verbraucht unnötig ~35% CPU wenn niemand zuschaut.
+      # Lösung: v4l2:/dev/video0 ohne #video=h264 → go2rtc öffnet Kamera nur bei Bedarf?
+      # Oder: mediamtx als Zwischenstufe (hat explizites on-demand). Prüfen.
 
 services: