# AppRobotWebcam – Protokoll-Vergleich WebRTC ⟷ MJPEG

## Status

- **Auflösung fest auf 640×480** → Latenz ist jetzt **„immer akzeptabel"** (vorher schwankend/träge).
  Das bestätigt: ein Teil der gefühlten Latenz kam von zu großen Frames im Browser
  (Decode + Render). Kleineres Bild = schnellerer Browser.
- **Entscheid vorläufig: WebRTC** – skaliert besser über echtes Internet (NAT, mehrere User).
- go2rtc bleibt die Basis → **http://thinkcentre.local:1984** bleibt jederzeit als
  Vergleichs- und Debug-Oberfläche verfügbar.

> Der direkte Messvergleich WebRTC ⟷ MJPEG steht noch aus (Zeitgründen).
> Diese Datei hält fest, **wie** man ihn nachholt.

---

## Warum überhaupt vergleichen?

| Protokoll | Latenz (LAN, 480p) | Mechanik | Bandbreite |
|-----------|--------------------|----------|------------|
| **MJPEG** | am niedrigsten | Jedes Frame ein eigenständiges JPEG, kein Buffer, `<img>` rendert sofort | hoch (jedes Frame voll) |
| **WebRTC** | niedrig | H.264-Encode + Jitter-Buffer im Browser; dafür effiziente Kompression | niedrig |
| **MSE** | mittel–hoch | Für VOD optimiert, größerer Puffer | niedrig |

- **MJPEG** = theoretische Latenz-Untergrenze, aber bei mehr Usern / über Internet
  bandbreitenhungrig und ohne NAT-Traversal.
- **WebRTC** = minimal mehr Latenz durch Encode/Buffer, dafür internet-tauglich
  (NAT-Traversal via STUN/TURN, geringe Bandbreite, mehrere User).

Für **1–3 User im LAN** kann MJPEG gewinnen. Über **Internet** gewinnt WebRTC fast immer.

---

## So führst du den Vergleich durch

go2rtc stellt jeden Stream über **mehrere** Protokolle bereit. Jeweils einzeln und
direkt im Browser öffnen (für cam1: `cam0` → `cam1` ersetzen):

| Modus | URL | Was es testet |
|-------|-----|---------------|
| **MJPEG roh** | `http://thinkcentre.local:1984/api/stream.mjpeg?src=cam0` | Untergrenze: reines Bild, kein Player, kein Buffer |
| **WebRTC pur** | `http://thinkcentre.local:1984/webrtc.html?src=cam0` | WebRTC isoliert |
| **MSE pur** | `http://thinkcentre.local:1984/mse.html?src=cam0` | MSE isoliert (Referenz) |
| **Alle Links** | `http://thinkcentre.local:1984/links.html?src=cam0` | go2rtc listet selbst alle Endpunkte auf |

> Hinweis zur go2rtc-Startseite: Die Checkboxen (WebRTC/MSE/MJPEG) oben filtern nur,
> welche Technologien der **kombinierte** Player `stream.html` ausprobieren darf –
> sichtbar ändert sich dabei nichts, weil er automatisch die erste passende nimmt.
> Für einen echten Vergleich **die obigen Einzel-URLs** verwenden.

### Latenz messen (objektiv, in ms)

1. Handy-Stoppuhr mit Millisekunden-Anzeige vor die Kamera halten.
2. MJPEG-URL und WebRTC-URL in zwei Tabs/Fenstern nebeneinander öffnen.
3. Einen Screenshot machen, der **die echte Stoppuhr** und **beide Stream-Bilder**
   gleichzeitig zeigt (Handy + Monitor zusammen abfotografieren ist am einfachsten).
4. Differenz „echte Zeit ↔ Bild im Stream" ablesen = Gesamt-Latenz pro Protokoll.

### Ergebnis-Tabelle ✅ gemessen 2026-06-03

Methode: Handy-Stoppuhr (ms) vor Kamera, Foto von Monitor + Stoppuhr.

| Kamera | MJPEG | WebRTC | MSE | Sieger |
|--------|-------|--------|-----|--------|
| cam0+1 | ~200 ms | ~130 ms | — | **WebRTC** |

MSE nicht gemessen (erwartet schlechter als beide, für Live nicht relevant).

---

## Entscheidungslogik nach dem Test

- **WebRTC ≈ MJPEG (Differenz < ~50 ms):**
  → Bei **WebRTC** bleiben. Vorteil Internet-Skalierung überwiegt die paar ms.

- **MJPEG deutlich schneller (Differenz > ~100 ms) UND nur LAN-Nutzung:**
  → Optional **MJPEG-Viewer** zusätzlich anbieten (simple `<img>`-Seite).
  go2rtc liefert MJPEG ohnehin schon unter `/api/stream.mjpeg?src=camN`.

- **Auflösung weiter drücken:**
  → In `docker-compose.yaml` unter `configs:` `video_size=640x480` → `320x240`.
  Test wiederholen. Kleiner = weniger Browser-Last = weniger Latenz.

---

## Weitere Latenz-Stellschrauben (falls WebRTC noch zu träge)

1. **Keyframe-Intervall senken** – H.264 startet erst beim nächsten Keyframe.
   In der go2rtc-Quelle den Encoder mit `-g 15` (Keyframe alle 0.5 s @30fps) zwingen.
2. **Kamera-natives H.264** – falls die Webcam H.264 direkt liefert (UVC H.264),
   kann go2rtc ohne Re-Encode durchreichen → minimale CPU + Latenz.
   Prüfen mit: `v4l2-ctl -d /dev/video0 --list-formats`
3. **`zerolatency`-Tuning** im Encoder (ultrafast + tune zerolatency).
4. **WebRTC statt über Proxy direkt** – Jitter-Buffer des Browsers ist Fixkosten,
   lässt sich nur begrenzt beeinflussen.

---

## Wichtig: go2rtc bleibt erhalten

Da der finale Aufbau weiter auf go2rtc setzt, bleibt **http://thinkcentre.local:1984**
dauerhaft als Debug-/Vergleichs-UI nutzbar. Der Protokoll-Vergleich kann also
**jederzeit später** nachgeholt werden, ohne etwas umzubauen.