From 39fa6d07f5c7cb6cf92a6a5decaf05307b299699 Mon Sep 17 00:00:00 2001
From: chk <79915315+ChKendel@users.noreply.github.com>
Date: Sun, 7 Jun 2026 12:01:39 +0200
Subject: [PATCH] Roadmap & CSS

---
 doc/14_ReRender_roadmap.md | 320 ++++++++++++++++++++-----------------
 public/app.css             |  84 +++++-----
 2 files changed, 221 insertions(+), 183 deletions(-)

diff --git a/doc/14_ReRender_roadmap.md b/doc/14_ReRender_roadmap.md
index 349baa9..93e1c77 100644
--- a/doc/14_ReRender_roadmap.md
+++ b/doc/14_ReRender_roadmap.md
@@ -1,206 +1,240 @@
-# 📦 Re-Render & Compress
+# 📦 Re-Render & Compress (H.264)
+
+> Status: **Entwurf / noch nichts implementiert.** Alle Zahlen unten sind
+> Hypothesen, bis sie auf dem Host gemessen sind (siehe Phase 0).
 
 ## Problem
 
-Der aktuelle Video-Stream (insbesondere 1080p MJPEG) erzeugt **sehr hohe Datenraten (~30 MBit/s)**.  
-Das führt zu Problemen bei:
+MJPEG überträgt jedes Frame als vollständiges JPEG → die Bandbreite skaliert
+linear mit Auflösung × Framerate × Clients. Bei höheren Auflösungen oder mehreren
+gleichzeitigen Clients kann das im WAN / mobil teuer werden.
 
-- mobiler Nutzung (Bandbreite / Datenvolumen)
-- mehreren gleichzeitigen Clients
-- schwachen Netzwerken
+⚠️ **Wichtig – aktuelle Realität prüfen, nicht annehmen:**
+Die Live-Streams laufen derzeit auf **320×240** (`liveSize` pro Kamera in
+[cameras.json](../cameras.json)), **nicht** 1080p. Das `1920x1080` dort ist die
+**`hiresSize`** — also das *Einzelbild* beim HD-Knopf bzw. im Snapshot-Modus, kein
+Dauerstream. Die oft zitierten „~30 MBit/s" gelten also bestenfalls für einen
+hypothetischen 1080p-Dauerstream, nicht für den heutigen Betrieb.
+
+👉 Bevor hier irgendwas gebaut wird, gilt **Phase 0: messen**. Ohne belastbare
+Bandbreiten-Zahl ist unklar, ob sich der ganze Umbau überhaupt lohnt.
 
 ## Ziel
 
-Reduktion der Bandbreite durch **optionale Hardware-basierte Neukodierung**:
+Reduktion der Bandbreite durch **optionale, pro Kamera schaltbare** Neukodierung
+MJPEG → H.264 (GPU), **ohne** die schlanke Default-Architektur (Node besitzt die
+Kameras, MJPEG-Passthrough, `<img>`-Viewer) für den LAN-Fall aufzugeben.
 
-- Eingangsformat: MJPEG (von der Webcam)
-- Zielformat: H.264 (deutlich effizienter)
-
-👉 Zielbitrate: ~2–5 MBit/s bei vergleichbarer wahrgenommener Qualität
+Zielbitrate (Hypothese): ~2–5 MBit/s bei vergleichbarer wahrgenommener Qualität.
 
 ---
 
-## Lösungsansatz
+## ⚠️ Der eigentliche Knackpunkt zuerst: Wiedergabe im Browser
 
-Zwei Betriebsmodi sollen flexibel unterstützt werden:
+Das ist der Teil, der den Umbau groß macht — und der im ersten Entwurf als
+„UI-Checkbox" verharmlost war.
 
-### 1. 🟢 Unkomprimierter Modus (Default)
-- MJPEG bleibt unverändert
-- minimale Latenz
-- keine GPU-Abhängigkeit
+Der aktuelle Viewer rendert den Stream in einem **`<img>`**
+([public/viewer.js](../public/viewer.js)), gespeist aus
+`multipart/x-mixed-replace` ([src/snapshotService.js](../src/snapshotService.js)).
+Ein `<img>` kann **ausschließlich MJPEG** darstellen.
+
+> **H.264 läuft niemals in einem `<img>`.** „Der Browser soll mit beidem umgehen"
+> ist daher kein Schalter, sondern ein **zweiter, vollständiger Wiedergabe-Pfad.**
+
+H.264 + MJPEG schließen sich auch im Transport gegenseitig aus — H.264 lässt sich
+nicht in MJPEG-multipart verpacken. Es braucht einen eigenen Container und einen
+eigenen Player. Optionen:
+
+| Transport | Client | Aufwand | Latenz (Erwartung, zu messen) |
+|-----------|--------|---------|-------------------------------|
+| **MSE (fMP4)** | `<video>` + `MediaSource` + JS-Feeder | mittel | gut, mit Low-Latency-Tuning; sonst 200 ms–1 s Puffer |
+| **WebRTC** | `RTCPeerConnection` + Signaling | hoch | am niedrigsten |
+| HLS/DASH | `<video>` / hls.js | gering | Sekunden — für Live untauglich |
+
+**Achtung – Déjà-vu:** WebRTC + H.264 ist genau das, was go2rtc gemacht hat und
+was bewusst entfernt wurde (siehe Architektur-Doku). WebRTC würde Signaling-
+Infrastruktur wieder einführen. **Empfehlung: MSE-fMP4**, weil es die „Node besitzt
+die Kameras"-Architektur erhält (Node → ffmpeg → Byte-Stream → Browser) und keine
+ICE/STUN/TURN-Maschinerie braucht. Endgültige Wahl erst nach der Latenz-Messung
+(Phase 0).
+
+### MSE-Besonderheit: Init-Segment für späte Clients
+
+Anders als bei MJPEG (jedes Frame eigenständig) muss bei fragmentiertem MP4 ein
+Client, der **mitten im Stream** dazukommt, zuerst das **Init-Segment**
+(`ftyp`+`moov`) bekommen, dann die Media-Fragmente. Der Server muss das
+Init-Segment also **zwischenspeichern** und jedem neuen Client zuerst schicken,
+bevor er ihn in den Fan-out hängt. Das ist neue Logik gegenüber dem heutigen
+„jedes Frame an jeden"-Modell.
+
+---
+
+## Lösungsansatz: zwei Modi pro Kamera
+
+### 1. 🟢 MJPEG-Passthrough (Default, unverändert)
+- bestehender Pfad: `copybsf` → `mpjpeg` → `multipart` → `<img>`
+- minimale Latenz, keine GPU-Abhängigkeit, ~5 % idle-CPU
 - ideal im LAN / bei wenigen Clients
 
-### 2. 🔵 Komprimierter Modus (optional)
-- MJPEG → H.264 via GPU-Encoding
-- drastisch reduzierte Bandbreite
-- geeignet für:
-  - mobile Clients
-  - WAN-Zugriff
-  - mehrere parallele Streams
+### 2. 🔵 H.264 (optional, GPU)
+- MJPEG → H.264 (VAAPI/QSV) → fMP4 → MSE-`<video>`
+- drastisch reduzierte Bandbreite, für mobil / WAN / viele Clients
+- höhere Komplexität + GPU-Abhängigkeit + (zu messende) Zusatzlatenz
 
-👉 **Wichtig:** Kompression muss pro Kamera konfigurierbar sein.
-
----
-
-## Hardware-Bewertung
-
-### 🖥️ Intel UHD 630 (Coffee Lake)
-
-**Unterstützung:**
-- VAAPI
-- Quick Sync Video (H.264/H.265)
-
-**Leistung:**
-- 1–2 Streams stabil
-- niedrige CPU-Auslastung bei aktivem VAAPI
-
-**Einschränkungen:**
-- ältere Hardware
-- limitiert bei:
-  - hoher Bitrate
-  - vielen Clients
-
-**Praxis:**
-- 30 MBit MJPEG → stabil auf ~3–5 MBit H.264 reduzierbar
-
----
-
-### 🖥️ AMD Radeon 680M (Rembrandt)
-
-**Unterstützung:**
-- VAAPI
-- VCN 3.x Hardware Encoder
-
-**Vorteile:**
-- deutlich bessere Encoding-Performance
-- höhere Effizienz
-- gut geeignet für mehrere Streams
-
-**Praxis:**
-- mehrere parallele Re-Encodes in Echtzeit möglich
+Der Browser wählt **pro Kamera** anhand der Server-Metadaten den richtigen Player
+(`<img>` oder `<video>`).
 
 ---
 
 ## Architektur-Entscheidung
 
-- Encoding erfolgt **im Server (FFmpeg + GPU)**
-- Kamera liefert weiterhin MJPEG
-- Pipeline entscheidet dynamisch:
+- Encoding erfolgt **direkt in Node via FFmpeg + GPU** (kein go2rtc mehr).
+- Kamera liefert weiterhin MJPEG; der `CameraSwitch` bleibt einziger Geräte-Öffner.
+- Der Modus hängt am **vorhandenen `encode`-Feld** (siehe Konfigurationsmodell).
 
 ```
-Camera (MJPEG)
-    ↓
-FFmpeg
-    ↓
-[ optional ]
-H.264 Encoding (GPU)
-    ↓
-Client
+Kamera (MJPEG, v4l2)
+    │
+  ┌─┴─────────────────────────── encode = 'copybsf' | 'mjpeg'
+  │  ffmpeg -c:v copy -bsf mjpeg2jpeg -f mpjpeg
+  │  → multipart/x-mixed-replace → <img>           (heutiger Pfad, unverändert)
+  │
+  └─────────────────────────────  encode = 'h264'
+     ffmpeg -c:v h264_vaapi -f mp4 (fragmentiert)
+     → Byte-Stream (+ gecachtes Init-Segment) → MSE → <video>   (neu)
 ```
 
 ---
 
 ## Konfigurationsmodell
 
-Pro Kamera:
+**Kein neues `compress`-Flag** — das würde sich mit dem bestehenden Encode-Schalter
+überschneiden. Stattdessen das vorhandene `encode`-Feld erweitern, das in
+[server.js](../server.js) und [src/cameraSwitch.js](../src/cameraSwitch.js) bereits
+pro Kamera verdrahtet ist:
 
-- ✅ `stream`: an/aus
-- ✅ `compress`: an/aus (neu)
+| `encode` | Bedeutung |
+|----------|-----------|
+| `copybsf` | Default, Bitstream-Copy, niedrigste CPU (heute) |
+| `mjpeg` | Re-Encode MJPEG→MJPEG, Fallback (heute) |
+| `h264` | **neu:** GPU-H.264 → fMP4 (VAAPI/QSV, Auto-Erkennung) |
 
-Beispiel:
+Beispiel `cameras.json`:
 
 ```json
 {
-  "camera": "cam1",
+  "id": "cam2",
+  "device": "/dev/video4",
   "stream": true,
-  "compress": true
+  "encode": "h264",
+  "liveSize": "640x480"
 }
 ```
 
----
-
-## Technische Integration
-
-### 1. GPU in Docker verfügbar machen
-
-- Unterstützung für:
-  - Intel (VAAPI: `/dev/dri`)
-  - AMD (ebenfalls VAAPI)
-- dynamische Erkennung statt Hardcoding
+`hiresEncode` bleibt davon unberührt (HD-Snapshot bleibt JPEG — sinnvoll, da ein
+Einzelbild bandbreiten-unkritisch ist).
 
 ---
 
-### 2. FFmpeg-Pipeline erweitern
+## Technische Integration (was wirklich zu tun ist)
 
-Aktuell:
-- MJPEG → MJPEG (copy oder re-encode)
-
-Neu:
-- optionaler Pfad:
+### 1. GPU in den Container durchreichen
+- `/dev/dri` ins Docker-`devices` (wie in [doc/02_HardwareEncoding.md](02_HardwareEncoding.md) für die Intel-Box bestätigt: `/dev/dri/renderD128` vorhanden).
+- Encoder dynamisch wählen (`h264_vaapi` vs. `h264_qsv`) statt Hardcoding.
 
+### 2. FFmpeg-H.264-Profil (Node spawnt direkt — `#hardware` von go2rtc gibt es nicht mehr)
+Skizze (VAAPI, Werte in Phase 1 zu tunen/messen):
 ```bash
-MJPEG → H.264 (h264_vaapi / h264_qsv)
+ffmpeg -fflags nobuffer \
+  -f v4l2 -input_format mjpeg -video_size 640x480 -framerate 30 -i /dev/video4 \
+  -vaapi_device /dev/dri/renderD128 -vf 'format=nv12,hwupload' \
+  -c:v h264_vaapi -b:v 3M -g 60 \
+  -f mp4 -movflags +frag_keyframe+empty_moov+default_base_moof -frag_duration 100000 \
+  pipe:1
 ```
+- MJPEG-**Decode** bleibt vorerst CPU (USB-MJPEG via VAAPI dekodieren ist wackelig)
+  → die „nur GPU"-Erwartung in Phase 0/1 **messen**, nicht annehmen.
+- Kurze GOP (`-g`) + `frag_duration` klein = niedrige Latenz, mehr Overhead → Trade-off messen.
+
+### 3. `CameraSwitch` erweitern ([src/cameraSwitch.js](../src/cameraSwitch.js))
+Nicht „nur neue Args" — betroffen sind mehrere Stellen:
+- `videoOutArgs()` um den `h264`-Zweig erweitern (anderer Muxer als `-f mpjpeg`).
+- Der `MpjpegParser` ist MJPEG-spezifisch und greift hier **nicht**; für fMP4 wird
+  der Byte-Stream durchgereicht (Init-Segment cachen, Media-Fragmente fan-out).
+- On-Demand / idle-Stop / Auto-Restart gelten weiter — die Pipeline startet wie
+  heute erst bei Verbrauchern.
+
+### 4. Neue Stream-Route ([src/snapshotService.js](../src/snapshotService.js))
+- `createStreamRouter` sendet heute `multipart/x-mixed-replace`. Für H.264 braucht
+  es eine Variante (oder zweite Route), die `video/mp4` als fortlaufenden
+  Byte-Stream liefert und neuen Clients zuerst das Init-Segment schickt.
+- `/api/cameras` muss den Modus (`mjpeg`|`h264`) mitliefern, damit der Viewer den
+  Player wählen kann.
+
+### 5. Viewer erweitern ([public/viewer.js](../public/viewer.js))
+- Bei `encode==='h264'`: `<video>` + `MediaSource` + SourceBuffer-Feeder statt `<img>`.
+- **Auto-Fallback statt schwarzem Bild:** client-seitig
+  `MediaSource.isTypeSupported('video/mp4; codecs="avc1.42E01E"')` prüfen; bei
+  fehlender Unterstützung sichtbare Meldung + automatischer Rückfall auf MJPEG,
+  nicht stilles Schwarz.
+
+### 6. UI ([public/config.html](../public/config.html))
+- Statt Checkbox „Compress": Dropdown/Select für `encode` (copybsf / mjpeg / h264).
 
 ---
 
-### 3. Stream-Handling erweitern
+## Hardware-Bewertung (Erwartung — in Phase 0/1 zu bestätigen)
 
-- bestehende Logik (`camera_switch.js`) bleibt intakt
-- Erweiterung:
-  - Encoding-Mode abhängig von `compress`
-  - neue FFmpeg-Args
+### 🖥️ Intel UHD 630 (Coffee Lake) — die heutige Box
+- VAAPI / Quick Sync (H.264/H.265), `/dev/dri/renderD128` bestätigt.
+- Erwartung: 1–2 H.264-Streams stabil, niedrige CPU bei GPU-Encode.
 
----
-
-### 4. UI erweitern
-
-In `config.html`:
-
-- Checkbox:
-  ```
-  [ ] Compress Stream (H.264)
-  ```
+### 🖥️ AMD Radeon 680M (Rembrandt) — falls Zielhardware
+- VAAPI / VCN 3.x; erwartet deutlich mehr Encode-Reserve.
+- ⚠️ **Erst prüfen, ob diese Box überhaupt Ziel ist** und ob `/dev/dri` + VAAPI dort
+  laufen — die bisherige Doku basiert auf der Intel-Box.
 
 ---
 
 ## Design-Prinzipien
 
-- ✅ **Backward-compatible** (Default: kein Encoding)
-- ✅ **Low latency bleibt möglich**
-- ✅ **Hardware optional**
-- ✅ **Pro Kamera steuerbar**
-- ✅ **Minimal CPU overhead**
+- ✅ **Backward-compatible** — Default bleibt MJPEG, nichts ändert sich für LAN.
+- ✅ **Pro Kamera schaltbar** über das vorhandene `encode`-Feld.
+- ✅ **Node behält die Kameras** — kein go2rtc/WebRTC-Rückbau.
+- ⚠️ **Low latency** nur, wenn die Messung es bestätigt (MSE puffert).
+- ⚠️ **GPU optional** — H.264-Kameras hängen an funktionierendem VAAPI/QSV.
 
 ---
 
-## Offene Punkte
+## Offene Entscheidungen
 
-- H.264 → Rückgabeformat:
-  - weiterhin MJPEG für Browser?
-  - oder direkt Stream (z.B. mpegts / WebRTC)?
-
-  >> das video soll entweder komprimiert oder unverändert zum browser kommen, je nachdem wie der Haken gesetzt ist. Der Browser soll mit beidem umgehen können.
-
-- Latenz vs. Kompression:
-  - Encoding erhöht minimal die Verzögerung. Das muss getestet werden, deshalb die Option es unverändert zu lassen.
-
-- Client-Kompatibilität:
-  - MJPEG: universell
-  - H.264: effizient, aber Wrapper nötig
-  Falls Browser das nicht unterstützt, wird die Darstellung schwarz. Dann kann die
-  Konfiguration "Kompression" abgeschaltet werden.
+1. **Lohnt es sich überhaupt?** → Phase 0 (Bandbreite der realen Live-Streams messen).
+2. **Transport: MSE-fMP4 (empfohlen) oder WebRTC?** → entscheidet Latenz + Aufwand,
+   abhängig von Phase-0-Messung.
+3. **Decode auf CPU oder GPU?** → messen, ob USB-MJPEG-VAAPI-Decode stabil ist.
+4. **Zielhardware Intel-Box oder AMD 680M?**
 
 ---
 
-## nächste Schritte (ToDo)
+## Nächste Schritte (ToDo — ehrlicher Stand: nichts erledigt)
 
-1. ✅ GPU-Passthrough in Docker implementieren  
-2. ✅ FFmpeg-Encoding-Profil definieren (VAAPI / QSV)  
-3. ✅ `CameraSwitch` um Encoding-Modus erweitern  
-4. ✅ Config um `compress` erweitern  
-5. ✅ UI-Checkbox hinzufügen  
-6. 🔄 Tests mit:
-   - Intel UHD 630
-   - AMD 680M  
-7. 🔄 Bandbreite & CPU vergleichen
+**Phase 0 — Messen (Vorbedingung, blockiert alles andere)**
+1. 🔲 Bandbreite der heutigen Live-Streams (320×240 bzw. konfigurierte `liveSize`) auf dem Host messen, bei 1 und bei n Clients.
+2. 🔲 Hypothese 1080p-Stream gegen die echte Zielauflösung abgleichen — lohnt der Umbau?
+3. 🔲 Transport-Latenz-Test: ein Test-fMP4-Stream (MSE) vs. heutiges MJPEG, Methode wie in [doc/03_Protocoll_roadmap.md](03_Protocoll_roadmap.md) (Stoppuhr-Foto).
+
+**Phase 1 — Encode-Pfad (nur wenn Phase 0 positiv)**
+4. 🔲 `/dev/dri`-Passthrough + VAAPI/QSV-Auto-Erkennung.
+5. 🔲 FFmpeg-H.264-fMP4-Profil definieren; CPU/GPU/Latenz auf dem Host messen.
+
+**Phase 2 — Server**
+6. 🔲 `encode='h264'` in `videoOutArgs` / `CameraSwitch` (inkl. Init-Segment-Cache + Byte-Stream-Fan-out).
+7. 🔲 H.264-Stream-Route + Modus in `/api/cameras`.
+
+**Phase 3 — Client**
+8. 🔲 MSE-`<video>`-Player + Feature-Detection + Auto-Fallback auf MJPEG.
+9. 🔲 `config.html`: `encode`-Auswahl.
+
+**Phase 4 — Verifikation**
+10. 🔲 Bandbreite & CPU/GPU vorher/nachher vergleichen (gemessen, auf dem Host).
diff --git a/public/app.css b/public/app.css
index d3c6f6b..06f5d8e 100644
--- a/public/app.css
+++ b/public/app.css
@@ -1,7 +1,7 @@
 /* ════════════════════════════════════════════════════════════════════════════
    AppRobotWebcam – gemeinsames Theme für Viewer (index.html) und Konfiguration
-   (config.html). Haus-Stil: helle Fläche, system-ui, weiche Karten mit Schatten,
-   dunkler Blur-Header. Video-/Bildflächen bleiben bewusst dunkel (Kontrast).
+   (config.html). Haus-Stil: dunkler Verlauf-Hintergrund, navyblaue Karten,
+   hellblauer Akzent – passend zum AppRobot-Control-Panel-Design.
    ════════════════════════════════════════════════════════════════════════════ */
 
 * { box-sizing: border-box; }
@@ -9,8 +9,9 @@
 body {
   margin: 0;
   font-family: system-ui, sans-serif;
-  background: #f5f6f8;
-  color: #1c1e21;
+  background: linear-gradient(135deg, #5e7080 0%, #8fa2b2 45%, #5e7080 100%);
+  min-height: 100vh;
+  color: #c8d8e8;
 }
 
 /* ── Header ──────────────────────────────────────────────────────────────── */
@@ -21,27 +22,25 @@ header {
   gap: 16px;
   padding: 0 20px;
   position: sticky; top: 0; z-index: 10;
-  color: #fff;
-  background: rgba(20, 22, 26, 0.85);
-  backdrop-filter: blur(6px);
-  box-shadow: 0 4px 12px rgba(0, 0, 0, 0.35);
+  background: #0c1824;
+  box-shadow: 0 2px 10px rgba(0, 0, 0, 0.6);
 }
-header .logo { font-weight: bold; letter-spacing: 0.03em; }
-header .status { font-size: 0.85rem; color: rgba(255, 255, 255, 0.6); margin-right: auto; }
+header .logo { font-weight: bold; letter-spacing: 0.03em; color: #7ec8e3; }
+header .status { font-size: 0.85rem; color: rgba(180, 210, 235, 0.55); margin-right: auto; }
 
 .ml-auto { margin-left: auto; }
 
 /* Buttons / Links im Header */
 .hbtn {
   display: inline-flex; align-items: center; gap: 6px; white-space: nowrap;
-  background: transparent; border: none; color: #fff;
+  background: transparent; border: none; color: #c8d8e8;
   padding: 8px 12px; border-radius: 6px;
   font: inherit; font-size: 0.9rem; cursor: pointer; text-decoration: none;
 }
-.hbtn:hover:not(:disabled) { background: rgba(255, 255, 255, 0.15); }
+.hbtn:hover:not(:disabled) { background: rgba(100, 160, 220, 0.18); }
 .hbtn:disabled { opacity: 0.4; cursor: default; }
-.hbtn.primary { background: rgba(80, 180, 120, 0.30); }
-.hbtn.primary:hover:not(:disabled) { background: rgba(80, 180, 120, 0.48); }
+.hbtn.primary { background: rgba(60, 160, 100, 0.30); color: #a8e8c0; }
+.hbtn.primary:hover:not(:disabled) { background: rgba(60, 160, 100, 0.48); }
 
 main { padding: 20px; }
 
@@ -54,29 +53,30 @@ main { padding: 20px; }
 
 .cam-box {
   position: relative;
-  background: #11131a;                 /* dunkle Karte für das Bild */
+  background: #0d1b2e;
   border-radius: 10px;
   overflow: hidden;
-  box-shadow: 0 4px 10px rgba(0, 0, 0, 0.12);
+  box-shadow: 0 4px 14px rgba(0, 0, 0, 0.5);
+  border: 1px solid rgba(80, 140, 200, 0.18);
 }
 
-/* Live-MJPEG bzw. Snapshot-Bild – responsiv, dunkler Hintergrund */
+/* Live-MJPEG bzw. Snapshot-Bild – responsiv */
 .cam-img {
   display: block; width: 100%; aspect-ratio: 4 / 3;
-  background: #11131a; object-fit: contain;
+  background: #07101a; object-fit: contain;
 }
 
 .cam-label {
   position: absolute; top: 8px; left: 10px; z-index: 2;
-  background: rgba(0, 0, 0, 0.55); padding: 3px 9px; border-radius: 6px;
-  font-size: 0.75rem; color: #fff;
+  background: rgba(0, 0, 0, 0.65); padding: 3px 9px; border-radius: 6px;
+  font-size: 0.75rem; color: #9abcd6;
 }
 
 /* Health-Anzeige unten links */
 .cam-info {
   position: absolute; bottom: 8px; left: 10px; z-index: 2;
   background: rgba(0, 0, 0, 0.6); padding: 3px 9px; border-radius: 6px;
-  font-size: 0.72rem; color: #d8d8d8;
+  font-size: 0.72rem; color: #7a9ab8;
 }
 .cam-info.ok   { color: #7ee29a; }
 .cam-info.warn { color: #ffc861; }
@@ -85,14 +85,14 @@ main { padding: 20px; }
 /* Ein/Aus-Schalter + HD-Button (über dem Bild) */
 .cam-toggle, .cam-hdtest {
   position: absolute; top: 8px; z-index: 2;
-  background: rgba(0, 0, 0, 0.55); color: #fff;
-  border: 1px solid rgba(255, 255, 255, 0.18); border-radius: 6px;
+  background: rgba(0, 0, 0, 0.55); color: #c8d8e8;
+  border: 1px solid rgba(80, 140, 200, 0.3); border-radius: 6px;
   font: inherit; cursor: pointer; backdrop-filter: blur(2px);
 }
 .cam-toggle { right: 10px; width: 30px; height: 26px; font-size: 0.72rem; }
-.cam-hdtest { right: 48px; height: 26px; padding: 0 9px; font-size: 0.72rem; color: #8cf; }
-.cam-toggle:hover { background: rgba(60, 60, 60, 0.85); }
-.cam-hdtest:hover:not(:disabled) { background: rgba(40, 60, 90, 0.85); }
+.cam-hdtest { right: 48px; height: 26px; padding: 0 9px; font-size: 0.72rem; color: #7ec8e3; }
+.cam-toggle:hover { background: rgba(30, 60, 100, 0.85); }
+.cam-hdtest:hover:not(:disabled) { background: rgba(20, 50, 90, 0.85); }
 .cam-hdtest:disabled { opacity: 0.4; cursor: default; }
 
 /* Snapshot-Modus: gross + fett über dem Einzelbild */
@@ -100,40 +100,44 @@ main { padding: 20px; }
   position: absolute; top: 0; left: 0; right: 0; z-index: 3;
   text-align: center; padding: 8px 4px;
   font-size: 1.1rem; font-weight: bold; letter-spacing: 0.06em; text-transform: uppercase;
-  color: #ffcf6b; background: rgba(0, 0, 0, 0.7);
+  color: #ffcf6b; background: rgba(0, 0, 0, 0.75);
 }
 
 /* ── Karte / Tabelle (config.html) ───────────────────────────────────────── */
 .card {
-  background: #fff; border-radius: 10px; padding: 20px;
-  box-shadow: 0 4px 10px rgba(0, 0, 0, 0.08); max-width: 760px;
+  background: #0d1b2e;
+  border: 1px solid rgba(80, 140, 200, 0.2);
+  border-radius: 10px; padding: 20px;
+  box-shadow: 0 4px 14px rgba(0, 0, 0, 0.5); max-width: 760px;
 }
 
 table { width: 100%; border-collapse: collapse; font-size: 0.9rem; }
-th, td { text-align: left; padding: 10px 12px; border-bottom: 1px solid #eceef1; }
-th { color: #65676b; font-weight: 600; }
+th, td { text-align: left; padding: 10px 12px; border-bottom: 1px solid rgba(80, 140, 200, 0.12); }
+th { color: #7ec8e3; font-weight: 600; }
+td { color: #c8d8e8; }
 tr:last-child td { border-bottom: none; }
 
 select {
   font: inherit; padding: 6px 10px;
-  border: 1px solid #ccd0d5; border-radius: 6px; background: #fff; cursor: pointer;
+  border: 1px solid rgba(80, 140, 200, 0.35); border-radius: 6px;
+  background: #152538; color: #c8d8e8; cursor: pointer;
 }
-.warn-badge { color: #e08500; cursor: help; }
-.cur { color: #8a8d91; }
+.warn-badge { color: #ffc861; cursor: help; }
+.cur { color: #5a7a9a; }
 
 .actions { margin-top: 18px; display: flex; align-items: center; gap: 14px; }
 .btn-primary {
-  background: #2e7d46; color: #fff; border: none; border-radius: 6px;
+  background: #1a5a8a; color: #e0f0ff; border: none; border-radius: 6px;
   padding: 9px 18px; font: inherit; cursor: pointer;
 }
-.btn-primary:hover:not(:disabled) { background: #256e3c; }
+.btn-primary:hover:not(:disabled) { background: #1e6aa0; }
 .btn-primary:disabled { opacity: 0.5; cursor: default; }
 
-#status { font-size: 0.85rem; color: #65676b; }
-#status.ok  { color: #2e7d46; }
-#status.err { color: #c0392b; }
+#status { font-size: 0.85rem; color: #7a9ab8; }
+#status.ok  { color: #7ee29a; }
+#status.err { color: #ff8080; }
 
 .hint {
   margin-top: 18px; max-width: 760px;
-  font-size: 0.8rem; color: #8a8d91; line-height: 1.6;
+  font-size: 0.8rem; color: #5a7a9a; line-height: 1.6;
 }