207 lines
3.9 KiB
Markdown
207 lines
3.9 KiB
Markdown
# 📦 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
|