Roadmap & CSS
This commit is contained in:
chk
@@ -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
|
## Problem
|
||||||
|
|
||||||
Der aktuelle Video-Stream (insbesondere 1080p MJPEG) erzeugt **sehr hohe Datenraten (~30 MBit/s)**.
|
MJPEG überträgt jedes Frame als vollständiges JPEG → die Bandbreite skaliert
|
||||||
Das führt zu Problemen bei:
|
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)
|
⚠️ **Wichtig – aktuelle Realität prüfen, nicht annehmen:**
|
||||||
- mehreren gleichzeitigen Clients
|
Die Live-Streams laufen derzeit auf **320×240** (`liveSize` pro Kamera in
|
||||||
- schwachen Netzwerken
|
[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
|
## 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)
|
Zielbitrate (Hypothese): ~2–5 MBit/s bei vergleichbarer wahrgenommener Qualität.
|
||||||
- Zielformat: H.264 (deutlich effizienter)
|
|
||||||
|
|
||||||
👉 Zielbitrate: ~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)
|
Der aktuelle Viewer rendert den Stream in einem **`<img>`**
|
||||||
- MJPEG bleibt unverändert
|
([public/viewer.js](../public/viewer.js)), gespeist aus
|
||||||
- minimale Latenz
|
`multipart/x-mixed-replace` ([src/snapshotService.js](../src/snapshotService.js)).
|
||||||
- keine GPU-Abhängigkeit
|
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
|
- ideal im LAN / bei wenigen Clients
|
||||||
|
|
||||||
### 2. 🔵 Komprimierter Modus (optional)
|
### 2. 🔵 H.264 (optional, GPU)
|
||||||
- MJPEG → H.264 via GPU-Encoding
|
- MJPEG → H.264 (VAAPI/QSV) → fMP4 → MSE-`<video>`
|
||||||
- drastisch reduzierte Bandbreite
|
- drastisch reduzierte Bandbreite, für mobil / WAN / viele Clients
|
||||||
- geeignet für:
|
- höhere Komplexität + GPU-Abhängigkeit + (zu messende) Zusatzlatenz
|
||||||
- mobile Clients
|
|
||||||
- WAN-Zugriff
|
|
||||||
- mehrere parallele Streams
|
|
||||||
|
|
||||||
👉 **Wichtig:** Kompression muss pro Kamera konfigurierbar sein.
|
Der Browser wählt **pro Kamera** anhand der Server-Metadaten den richtigen Player
|
||||||
|
(`<img>` oder `<video>`).
|
||||||
---
|
|
||||||
|
|
||||||
## 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
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## Architektur-Entscheidung
|
## Architektur-Entscheidung
|
||||||
|
|
||||||
- Encoding erfolgt **im Server (FFmpeg + GPU)**
|
- Encoding erfolgt **direkt in Node via FFmpeg + GPU** (kein go2rtc mehr).
|
||||||
- Kamera liefert weiterhin MJPEG
|
- Kamera liefert weiterhin MJPEG; der `CameraSwitch` bleibt einziger Geräte-Öffner.
|
||||||
- Pipeline entscheidet dynamisch:
|
- Der Modus hängt am **vorhandenen `encode`-Feld** (siehe Konfigurationsmodell).
|
||||||
|
|
||||||
```
|
```
|
||||||
Camera (MJPEG)
|
Kamera (MJPEG, v4l2)
|
||||||
↓
|
│
|
||||||
FFmpeg
|
┌─┴─────────────────────────── encode = 'copybsf' | 'mjpeg'
|
||||||
↓
|
│ ffmpeg -c:v copy -bsf mjpeg2jpeg -f mpjpeg
|
||||||
[ optional ]
|
│ → multipart/x-mixed-replace → <img> (heutiger Pfad, unverändert)
|
||||||
H.264 Encoding (GPU)
|
│
|
||||||
↓
|
└───────────────────────────── encode = 'h264'
|
||||||
Client
|
ffmpeg -c:v h264_vaapi -f mp4 (fragmentiert)
|
||||||
|
→ Byte-Stream (+ gecachtes Init-Segment) → MSE → <video> (neu)
|
||||||
```
|
```
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## Konfigurationsmodell
|
## 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
|
| `encode` | Bedeutung |
|
||||||
- ✅ `compress`: an/aus (neu)
|
|----------|-----------|
|
||||||
|
| `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
|
```json
|
||||||
{
|
{
|
||||||
"camera": "cam1",
|
"id": "cam2",
|
||||||
|
"device": "/dev/video4",
|
||||||
"stream": true,
|
"stream": true,
|
||||||
"compress": true
|
"encode": "h264",
|
||||||
|
"liveSize": "640x480"
|
||||||
}
|
}
|
||||||
```
|
```
|
||||||
|
|
||||||
---
|
`hiresEncode` bleibt davon unberührt (HD-Snapshot bleibt JPEG — sinnvoll, da ein
|
||||||
|
Einzelbild bandbreiten-unkritisch ist).
|
||||||
## Technische Integration
|
|
||||||
|
|
||||||
### 1. GPU in Docker verfügbar machen
|
|
||||||
|
|
||||||
- Unterstützung für:
|
|
||||||
- Intel (VAAPI: `/dev/dri`)
|
|
||||||
- AMD (ebenfalls VAAPI)
|
|
||||||
- dynamische Erkennung statt Hardcoding
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
### 2. FFmpeg-Pipeline erweitern
|
## Technische Integration (was wirklich zu tun ist)
|
||||||
|
|
||||||
Aktuell:
|
### 1. GPU in den Container durchreichen
|
||||||
- MJPEG → MJPEG (copy oder re-encode)
|
- `/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.
|
||||||
Neu:
|
|
||||||
- optionaler Pfad:
|
|
||||||
|
|
||||||
|
### 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
|
```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
|
### 🖥️ Intel UHD 630 (Coffee Lake) — die heutige Box
|
||||||
- Erweiterung:
|
- VAAPI / Quick Sync (H.264/H.265), `/dev/dri/renderD128` bestätigt.
|
||||||
- Encoding-Mode abhängig von `compress`
|
- Erwartung: 1–2 H.264-Streams stabil, niedrige CPU bei GPU-Encode.
|
||||||
- neue FFmpeg-Args
|
|
||||||
|
|
||||||
---
|
### 🖥️ AMD Radeon 680M (Rembrandt) — falls Zielhardware
|
||||||
|
- VAAPI / VCN 3.x; erwartet deutlich mehr Encode-Reserve.
|
||||||
### 4. UI erweitern
|
- ⚠️ **Erst prüfen, ob diese Box überhaupt Ziel ist** und ob `/dev/dri` + VAAPI dort
|
||||||
|
laufen — die bisherige Doku basiert auf der Intel-Box.
|
||||||
In `config.html`:
|
|
||||||
|
|
||||||
- Checkbox:
|
|
||||||
```
|
|
||||||
[ ] Compress Stream (H.264)
|
|
||||||
```
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## Design-Prinzipien
|
## Design-Prinzipien
|
||||||
|
|
||||||
- ✅ **Backward-compatible** (Default: kein Encoding)
|
- ✅ **Backward-compatible** — Default bleibt MJPEG, nichts ändert sich für LAN.
|
||||||
- ✅ **Low latency bleibt möglich**
|
- ✅ **Pro Kamera schaltbar** über das vorhandene `encode`-Feld.
|
||||||
- ✅ **Hardware optional**
|
- ✅ **Node behält die Kameras** — kein go2rtc/WebRTC-Rückbau.
|
||||||
- ✅ **Pro Kamera steuerbar**
|
- ⚠️ **Low latency** nur, wenn die Messung es bestätigt (MSE puffert).
|
||||||
- ✅ **Minimal CPU overhead**
|
- ⚠️ **GPU optional** — H.264-Kameras hängen an funktionierendem VAAPI/QSV.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## Offene Punkte
|
## Offene Entscheidungen
|
||||||
|
|
||||||
- H.264 → Rückgabeformat:
|
1. **Lohnt es sich überhaupt?** → Phase 0 (Bandbreite der realen Live-Streams messen).
|
||||||
- weiterhin MJPEG für Browser?
|
2. **Transport: MSE-fMP4 (empfohlen) oder WebRTC?** → entscheidet Latenz + Aufwand,
|
||||||
- oder direkt Stream (z.B. mpegts / WebRTC)?
|
abhängig von Phase-0-Messung.
|
||||||
|
3. **Decode auf CPU oder GPU?** → messen, ob USB-MJPEG-VAAPI-Decode stabil ist.
|
||||||
>> 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.
|
4. **Zielhardware Intel-Box oder AMD 680M?**
|
||||||
|
|
||||||
- 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.
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## nächste Schritte (ToDo)
|
## Nächste Schritte (ToDo — ehrlicher Stand: nichts erledigt)
|
||||||
|
|
||||||
1. ✅ GPU-Passthrough in Docker implementieren
|
**Phase 0 — Messen (Vorbedingung, blockiert alles andere)**
|
||||||
2. ✅ FFmpeg-Encoding-Profil definieren (VAAPI / QSV)
|
1. 🔲 Bandbreite der heutigen Live-Streams (320×240 bzw. konfigurierte `liveSize`) auf dem Host messen, bei 1 und bei n Clients.
|
||||||
3. ✅ `CameraSwitch` um Encoding-Modus erweitern
|
2. 🔲 Hypothese 1080p-Stream gegen die echte Zielauflösung abgleichen — lohnt der Umbau?
|
||||||
4. ✅ Config um `compress` erweitern
|
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).
|
||||||
5. ✅ UI-Checkbox hinzufügen
|
|
||||||
6. 🔄 Tests mit:
|
**Phase 1 — Encode-Pfad (nur wenn Phase 0 positiv)**
|
||||||
- Intel UHD 630
|
4. 🔲 `/dev/dri`-Passthrough + VAAPI/QSV-Auto-Erkennung.
|
||||||
- AMD 680M
|
5. 🔲 FFmpeg-H.264-fMP4-Profil definieren; CPU/GPU/Latenz auf dem Host messen.
|
||||||
7. 🔄 Bandbreite & CPU vergleichen
|
|
||||||
|
**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).
|
||||||
|
|||||||
@@ -1,7 +1,7 @@
|
|||||||
/* ════════════════════════════════════════════════════════════════════════════
|
/* ════════════════════════════════════════════════════════════════════════════
|
||||||
AppRobotWebcam – gemeinsames Theme für Viewer (index.html) und Konfiguration
|
AppRobotWebcam – gemeinsames Theme für Viewer (index.html) und Konfiguration
|
||||||
(config.html). Haus-Stil: helle Fläche, system-ui, weiche Karten mit Schatten,
|
(config.html). Haus-Stil: dunkler Verlauf-Hintergrund, navyblaue Karten,
|
||||||
dunkler Blur-Header. Video-/Bildflächen bleiben bewusst dunkel (Kontrast).
|
hellblauer Akzent – passend zum AppRobot-Control-Panel-Design.
|
||||||
════════════════════════════════════════════════════════════════════════════ */
|
════════════════════════════════════════════════════════════════════════════ */
|
||||||
|
|
||||||
* { box-sizing: border-box; }
|
* { box-sizing: border-box; }
|
||||||
@@ -9,8 +9,9 @@
|
|||||||
body {
|
body {
|
||||||
margin: 0;
|
margin: 0;
|
||||||
font-family: system-ui, sans-serif;
|
font-family: system-ui, sans-serif;
|
||||||
background: #f5f6f8;
|
background: linear-gradient(135deg, #5e7080 0%, #8fa2b2 45%, #5e7080 100%);
|
||||||
color: #1c1e21;
|
min-height: 100vh;
|
||||||
|
color: #c8d8e8;
|
||||||
}
|
}
|
||||||
|
|
||||||
/* ── Header ──────────────────────────────────────────────────────────────── */
|
/* ── Header ──────────────────────────────────────────────────────────────── */
|
||||||
@@ -21,27 +22,25 @@ header {
|
|||||||
gap: 16px;
|
gap: 16px;
|
||||||
padding: 0 20px;
|
padding: 0 20px;
|
||||||
position: sticky; top: 0; z-index: 10;
|
position: sticky; top: 0; z-index: 10;
|
||||||
color: #fff;
|
background: #0c1824;
|
||||||
background: rgba(20, 22, 26, 0.85);
|
box-shadow: 0 2px 10px rgba(0, 0, 0, 0.6);
|
||||||
backdrop-filter: blur(6px);
|
|
||||||
box-shadow: 0 4px 12px rgba(0, 0, 0, 0.35);
|
|
||||||
}
|
}
|
||||||
header .logo { font-weight: bold; letter-spacing: 0.03em; }
|
header .logo { font-weight: bold; letter-spacing: 0.03em; color: #7ec8e3; }
|
||||||
header .status { font-size: 0.85rem; color: rgba(255, 255, 255, 0.6); margin-right: auto; }
|
header .status { font-size: 0.85rem; color: rgba(180, 210, 235, 0.55); margin-right: auto; }
|
||||||
|
|
||||||
.ml-auto { margin-left: auto; }
|
.ml-auto { margin-left: auto; }
|
||||||
|
|
||||||
/* Buttons / Links im Header */
|
/* Buttons / Links im Header */
|
||||||
.hbtn {
|
.hbtn {
|
||||||
display: inline-flex; align-items: center; gap: 6px; white-space: nowrap;
|
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;
|
padding: 8px 12px; border-radius: 6px;
|
||||||
font: inherit; font-size: 0.9rem; cursor: pointer; text-decoration: none;
|
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:disabled { opacity: 0.4; cursor: default; }
|
||||||
.hbtn.primary { background: rgba(80, 180, 120, 0.30); }
|
.hbtn.primary { background: rgba(60, 160, 100, 0.30); color: #a8e8c0; }
|
||||||
.hbtn.primary:hover:not(:disabled) { background: rgba(80, 180, 120, 0.48); }
|
.hbtn.primary:hover:not(:disabled) { background: rgba(60, 160, 100, 0.48); }
|
||||||
|
|
||||||
main { padding: 20px; }
|
main { padding: 20px; }
|
||||||
|
|
||||||
@@ -54,29 +53,30 @@ main { padding: 20px; }
|
|||||||
|
|
||||||
.cam-box {
|
.cam-box {
|
||||||
position: relative;
|
position: relative;
|
||||||
background: #11131a; /* dunkle Karte für das Bild */
|
background: #0d1b2e;
|
||||||
border-radius: 10px;
|
border-radius: 10px;
|
||||||
overflow: hidden;
|
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 {
|
.cam-img {
|
||||||
display: block; width: 100%; aspect-ratio: 4 / 3;
|
display: block; width: 100%; aspect-ratio: 4 / 3;
|
||||||
background: #11131a; object-fit: contain;
|
background: #07101a; object-fit: contain;
|
||||||
}
|
}
|
||||||
|
|
||||||
.cam-label {
|
.cam-label {
|
||||||
position: absolute; top: 8px; left: 10px; z-index: 2;
|
position: absolute; top: 8px; left: 10px; z-index: 2;
|
||||||
background: rgba(0, 0, 0, 0.55); padding: 3px 9px; border-radius: 6px;
|
background: rgba(0, 0, 0, 0.65); padding: 3px 9px; border-radius: 6px;
|
||||||
font-size: 0.75rem; color: #fff;
|
font-size: 0.75rem; color: #9abcd6;
|
||||||
}
|
}
|
||||||
|
|
||||||
/* Health-Anzeige unten links */
|
/* Health-Anzeige unten links */
|
||||||
.cam-info {
|
.cam-info {
|
||||||
position: absolute; bottom: 8px; left: 10px; z-index: 2;
|
position: absolute; bottom: 8px; left: 10px; z-index: 2;
|
||||||
background: rgba(0, 0, 0, 0.6); padding: 3px 9px; border-radius: 6px;
|
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.ok { color: #7ee29a; }
|
||||||
.cam-info.warn { color: #ffc861; }
|
.cam-info.warn { color: #ffc861; }
|
||||||
@@ -85,14 +85,14 @@ main { padding: 20px; }
|
|||||||
/* Ein/Aus-Schalter + HD-Button (über dem Bild) */
|
/* Ein/Aus-Schalter + HD-Button (über dem Bild) */
|
||||||
.cam-toggle, .cam-hdtest {
|
.cam-toggle, .cam-hdtest {
|
||||||
position: absolute; top: 8px; z-index: 2;
|
position: absolute; top: 8px; z-index: 2;
|
||||||
background: rgba(0, 0, 0, 0.55); color: #fff;
|
background: rgba(0, 0, 0, 0.55); color: #c8d8e8;
|
||||||
border: 1px solid rgba(255, 255, 255, 0.18); border-radius: 6px;
|
border: 1px solid rgba(80, 140, 200, 0.3); border-radius: 6px;
|
||||||
font: inherit; cursor: pointer; backdrop-filter: blur(2px);
|
font: inherit; cursor: pointer; backdrop-filter: blur(2px);
|
||||||
}
|
}
|
||||||
.cam-toggle { right: 10px; width: 30px; height: 26px; font-size: 0.72rem; }
|
.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-hdtest { right: 48px; height: 26px; padding: 0 9px; font-size: 0.72rem; color: #7ec8e3; }
|
||||||
.cam-toggle:hover { background: rgba(60, 60, 60, 0.85); }
|
.cam-toggle:hover { background: rgba(30, 60, 100, 0.85); }
|
||||||
.cam-hdtest:hover:not(:disabled) { background: rgba(40, 60, 90, 0.85); }
|
.cam-hdtest:hover:not(:disabled) { background: rgba(20, 50, 90, 0.85); }
|
||||||
.cam-hdtest:disabled { opacity: 0.4; cursor: default; }
|
.cam-hdtest:disabled { opacity: 0.4; cursor: default; }
|
||||||
|
|
||||||
/* Snapshot-Modus: gross + fett über dem Einzelbild */
|
/* 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;
|
position: absolute; top: 0; left: 0; right: 0; z-index: 3;
|
||||||
text-align: center; padding: 8px 4px;
|
text-align: center; padding: 8px 4px;
|
||||||
font-size: 1.1rem; font-weight: bold; letter-spacing: 0.06em; text-transform: uppercase;
|
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) ───────────────────────────────────────── */
|
/* ── Karte / Tabelle (config.html) ───────────────────────────────────────── */
|
||||||
.card {
|
.card {
|
||||||
background: #fff; border-radius: 10px; padding: 20px;
|
background: #0d1b2e;
|
||||||
box-shadow: 0 4px 10px rgba(0, 0, 0, 0.08); max-width: 760px;
|
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; }
|
table { width: 100%; border-collapse: collapse; font-size: 0.9rem; }
|
||||||
th, td { text-align: left; padding: 10px 12px; border-bottom: 1px solid #eceef1; }
|
th, td { text-align: left; padding: 10px 12px; border-bottom: 1px solid rgba(80, 140, 200, 0.12); }
|
||||||
th { color: #65676b; font-weight: 600; }
|
th { color: #7ec8e3; font-weight: 600; }
|
||||||
|
td { color: #c8d8e8; }
|
||||||
tr:last-child td { border-bottom: none; }
|
tr:last-child td { border-bottom: none; }
|
||||||
|
|
||||||
select {
|
select {
|
||||||
font: inherit; padding: 6px 10px;
|
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; }
|
.warn-badge { color: #ffc861; cursor: help; }
|
||||||
.cur { color: #8a8d91; }
|
.cur { color: #5a7a9a; }
|
||||||
|
|
||||||
.actions { margin-top: 18px; display: flex; align-items: center; gap: 14px; }
|
.actions { margin-top: 18px; display: flex; align-items: center; gap: 14px; }
|
||||||
.btn-primary {
|
.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;
|
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; }
|
.btn-primary:disabled { opacity: 0.5; cursor: default; }
|
||||||
|
|
||||||
#status { font-size: 0.85rem; color: #65676b; }
|
#status { font-size: 0.85rem; color: #7a9ab8; }
|
||||||
#status.ok { color: #2e7d46; }
|
#status.ok { color: #7ee29a; }
|
||||||
#status.err { color: #c0392b; }
|
#status.err { color: #ff8080; }
|
||||||
|
|
||||||
.hint {
|
.hint {
|
||||||
margin-top: 18px; max-width: 760px;
|
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;
|
||||||
}
|
}
|
||||||
|
|||||||
Reference in New Issue
Block a user