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)

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

Ergebnis-Tabelle (später ausfüllen)

Kamera	MJPEG roh	WebRTC	MSE	Sieger
cam0	? ms	? ms	? ms	?
cam1	? ms	? ms	? ms	?

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)

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.
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
zerolatency-Tuning im Encoder (ultrafast + tune zerolatency).
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.

4.6 KiB Raw Blame History Unescape Escape