Roadmap ReRender
This commit is contained in:
206
doc/14_ReRender_roadmap.md
Normal file
206
doc/14_ReRender_roadmap.md
Normal 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: ~2–5 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:**
|
||||
- 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
|
||||
|
||||
- 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
|
||||
Reference in New Issue
Block a user