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"