Claude: miese Auflösung

2026-06-04 06:41:15 +02:00
parent f989e4f873
commit 831dbc242b
3 changed files with 248 additions and 165 deletions
--- a/doc/02_HardwareEncoding.md
+++ b/doc/02_HardwareEncoding.md
@@ -0,0 +1,109 @@
+# 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`)