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:

# 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

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

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

3.2 KiB Raw Blame History Unescape Escape