# 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`)