Files

chk 0a36b21996 Roadmap ReRender

2026-06-07 11:40:37 +02:00

3.9 KiB

Raw Blame History

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

{
  "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:

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)

✅ GPU-Passthrough in Docker implementieren
✅ FFmpeg-Encoding-Profil definieren (VAAPI / QSV)
✅ CameraSwitch um Encoding-Modus erweitern
✅ Config um compress erweitern
✅ UI-Checkbox hinzufügen
🔄 Tests mit:
- Intel UHD 630
- AMD 680M
🔄 Bandbreite & CPU vergleichen

3.9 KiB Raw Blame History Unescape Escape