# 📦 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