104 lines
4.7 KiB
Markdown
104 lines
4.7 KiB
Markdown
# 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.
|