Roadmap ReRender

This commit is contained in:
chk
2026-06-07 11:40:37 +02:00
parent 8d56a8fe35
commit 0a36b21996

206
doc/14_ReRender_roadmap.md Normal file
View File

@@ -0,0 +1,206 @@
# 📦 Re-Render & Compress
## Problem
Der aktuelle Video-Stream (insbesondere 1080p MJPEG) erzeugt **sehr hohe Datenraten (~30 MBit/s)**.
Das führt zu Problemen bei:
- mobiler Nutzung (Bandbreite / Datenvolumen)
- mehreren gleichzeitigen Clients
- schwachen Netzwerken
## Ziel
Reduktion der Bandbreite durch **optionale Hardware-basierte Neukodierung**:
- Eingangsformat: MJPEG (von der Webcam)
- Zielformat: H.264 (deutlich effizienter)
👉 Zielbitrate: ~25 MBit/s bei vergleichbarer wahrgenommener Qualität
---
## Lösungsansatz
Zwei Betriebsmodi sollen flexibel unterstützt werden:
### 1. 🟢 Unkomprimierter Modus (Default)
- MJPEG bleibt unverändert
- minimale Latenz
- keine GPU-Abhängigkeit
- 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
👉 **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:**
- 12 Streams stabil
- niedrige CPU-Auslastung bei aktivem VAAPI
**Einschränkungen:**
- ältere Hardware
- limitiert bei:
- hoher Bitrate
- vielen Clients
**Praxis:**
- 30 MBit MJPEG → stabil auf ~35 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
- Encoding erfolgt **im Server (FFmpeg + GPU)**
- Kamera liefert weiterhin MJPEG
- Pipeline entscheidet dynamisch:
```
Camera (MJPEG)
FFmpeg
[ optional ]
H.264 Encoding (GPU)
Client
```
---
## Konfigurationsmodell
Pro Kamera:
-`stream`: an/aus
-`compress`: an/aus (neu)
Beispiel:
```json
{
"camera": "cam1",
"stream": true,
"compress": true
}
```
---
## 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
Aktuell:
- MJPEG → MJPEG (copy oder re-encode)
Neu:
- optionaler Pfad:
```bash
MJPEG → H.264 (h264_vaapi / h264_qsv)
```
---
### 3. Stream-Handling erweitern
- bestehende Logik (`camera_switch.js`) bleibt intakt
- Erweiterung:
- Encoding-Mode abhängig von `compress`
- neue FFmpeg-Args
---
### 4. UI erweitern
In `config.html`:
- Checkbox:
```
[ ] Compress Stream (H.264)
```
---
## Design-Prinzipien
- ✅ **Backward-compatible** (Default: kein Encoding)
- ✅ **Low latency bleibt möglich**
- ✅ **Hardware optional**
- ✅ **Pro Kamera steuerbar**
- ✅ **Minimal CPU overhead**
---
## Offene Punkte
- 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.
---
## nächste Schritte (ToDo)
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