110 lines
3.2 KiB
Markdown
110 lines
3.2 KiB
Markdown
# Hardware-Encoding — Was, Warum, Wie
|
||
|
||
## Das Problem in einem Satz
|
||
|
||
go2rtc muss jeden Kamera-Frame von **MJPEG** (was die USB-Kamera liefert) in
|
||
**H.264** umwandeln (was WebRTC im Browser braucht). Das macht standardmässig
|
||
die **CPU** — und das frisst einen ganzen Kern (~100% für 2 Kameras).
|
||
|
||
---
|
||
|
||
## Was Hardware-Encoding bedeutet
|
||
|
||
Der ThinkCentre hat eine **Intel-iGPU** (integrierter Grafikchip) mit
|
||
**Quick Sync Video** — ein dedizierter H.264-Encoder-Block auf dem Chip.
|
||
|
||
```
|
||
Software-Encoding (bisher): MJPEG → libx264 (CPU) → H.264 → WebRTC
|
||
Hardware-Encoding (neu): MJPEG → h264_vaapi (GPU) → H.264 → WebRTC
|
||
```
|
||
|
||
Das Bild ist identisch — nur wer encodiert ändert sich.
|
||
CPU-Last: ~100% → **~5–10%**. Latenz: unverändert.
|
||
|
||
---
|
||
|
||
## Warum VAAPI / renderD128
|
||
|
||
VAAPI (Video Acceleration API) ist die Linux-Schnittstelle zur GPU.
|
||
Das Device `/dev/dri/renderD128` ist der GPU-Zugriffspunkt.
|
||
|
||
Bestätigt auf dem ThinkCentre:
|
||
```
|
||
crw-rw----+ 1 root render 226, 128 /dev/dri/renderD128 ✓ vorhanden
|
||
```
|
||
|
||
FFmpeg greift via VAAPI auf den Intel Quick Sync Encoder zu.
|
||
go2rtc wählt automatisch `h264_vaapi` wenn `#hardware` gesetzt und
|
||
`/dev/dri` im Container verfügbar ist.
|
||
|
||
---
|
||
|
||
## Was sich im docker-compose ändert
|
||
|
||
**Zwei Zeilen** gegenüber der Software-Encoding-Variante:
|
||
|
||
```yaml
|
||
# 1. GPU-Device in den Container durchreichen
|
||
devices:
|
||
- /dev/video0:/dev/video0
|
||
- /dev/video2:/dev/video2
|
||
- /dev/dri:/dev/dri # ← neu
|
||
|
||
# 2. #hardware am Ende der Stream-URL
|
||
streams:
|
||
cam0: "ffmpeg:device?video=/dev/video0&input_format=mjpeg&...#video=h264#hardware"
|
||
# ^^^^^^^^
|
||
```
|
||
|
||
go2rtc liest `#hardware` und wählt automatisch den VAAPI-Encoder.
|
||
|
||
---
|
||
|
||
## Erwartetes Ergebnis
|
||
|
||
| Messgrösse | Vorher (Software) | Nachher (Hardware) |
|
||
|------------|-------------------|-------------------|
|
||
| CPU go2rtc | ~100% | ~5–10% |
|
||
| Latenz | ~130ms + Jitter | ~130ms, stabiler |
|
||
| Freezes | gelegentlich (libx264 unter Last) | deutlich seltener |
|
||
| Bandbreite | ~1.5 Mbps/Stream | ähnlich |
|
||
| On-demand (0% CPU ohne Client) | ✓ | ✓ |
|
||
|
||
---
|
||
|
||
## Verifikation nach Neustart
|
||
|
||
```bash
|
||
# 1. CPU-Last
|
||
docker stats --no-stream --format "{{.Name}} {{.CPUPerc}}" AppRobotGo2RTC
|
||
# Erwartet: <10% mit aktivem Stream
|
||
|
||
# 2. Codec im Log (h264_vaapi = Hardware aktiv)
|
||
docker logs AppRobotGo2RTC 2>&1 | grep -E "vaapi|libx264|codec|encoder"
|
||
|
||
# 3. go2rtc Web-UI zeigt Stream
|
||
# http://thinkcentre.local:1984/ → cam0 und cam1 sichtbar
|
||
|
||
# 4. Browser-Viewer
|
||
# http://thinkcentre.local:8444/ → Bild, geringe Latenz
|
||
```
|
||
|
||
---
|
||
|
||
## Fallback
|
||
|
||
Falls `#hardware` nicht funktioniert (kein Bild, Codec-Fehler im Log):
|
||
```yaml
|
||
# In docker-compose.yaml, Kommentar-Zeile aktivieren:
|
||
cam0: "ffmpeg:device?video=/dev/video0&input_format=mjpeg&video_size=640x480&framerate=30#video=h264"
|
||
```
|
||
Software-Encoding ohne `#hardware` — funktioniert immer, aber ~100% CPU.
|
||
|
||
---
|
||
|
||
## Nächste optionale Schritte
|
||
|
||
- **Hi-Res Snapshots**: `#hardware#video=mjpeg` hinzufügen für nativen JPEG-Snapshot-Track
|
||
- **GOP-Grösse**: Keyframe-Abstand `-g 50` (1.67s) via MediaMTX-Zwischenstufe verkürzen
|
||
- **Internet**: Caddy als Reverse Proxy mit TLS (Phase 4 in `01_WebcamRoadmap.md`)
|