Webcam-Realstream-Test — was die Gegenseite wirklich sieht

Das Bild in Ihrer Webcam-Vorschau ist eine lokale Aufnahmeansicht — der Kamera-Feed, wie ihn getUserMedia() liefert — nicht die Rohsensorausgabe. Das Bild, das Ihr Videoanruf-Empfänger sieht, ist ein browser-encodierter Stream, der von WebRTC stillschweigend ausgehandelt, komprimiert und möglicherweise herabgestuft wurde. Dieser Leitfaden erklärt, wie die WebRTC-Codec-Aushandlung funktioniert, wie Sie getStats() auf einer RTCPeerConnection nutzen, um echte Stream-Parameter zu messen, und wie Sie häufige Ursachen von Qualitätsverlust beheben. Beachten Sie, dass das Webcam-Tool dieser Seite nur den lokalen Aufnahme-Track und die Browser-Bildrate prüft; es misst nicht den ausgehenden WebRTC-encodierten Stream.

Sie nehmen am Videoanruf teil. Ihr Browserfenster zeigt ein Vorschaubild von Ihnen, das scharf und lebendig aussieht — 1080p, sagt das Kamera-Setup. Dann sagt der Kollege: „Können Sie näher ans Licht rücken? Das Bild ist ganz verschwommen.” Sie wechseln zur Kamera-Vorschau, und alles sieht perfekt aus. Das ist kein technischer Fehler — es ist eine Trennung von Ansichten, die in WebRTC eingebaut ist.

Ihre Kamera-Vorschau ist die lokale Ansicht. Sie zeigt den Frame, den Ihre Kamera erzeugt, wie ihn getUserMedia() dem Browser liefert, vor jeder Netzwerk-Encodierung. Was Ihr Kollege sieht, ist der Stream — das Video nachdem der Browser es encodiert und WebRTC Qualität auf Basis der wahrgenommenen Netzwerkbedingungen ausgehandelt hat. Diese zwei Videos desselben Motivs können dramatisch unterschiedlich sein.

Die Vorschau ist nicht die Rohsensorausgabe. Der Sensor erzeugt ein Bild; der Browser wendet dann eine Verarbeitungskette an — Skalierung, Farbkonvertierung, möglicherweise Beschneidung und die eingestellten Constraints — bevor ein Frame zur Encodierung freigegeben wird. Diese Verarbeitung ist ein Teil des Capture-Modells des Browsers, das die tatsächliche Frame-Ankunft verzögern oder verändern kann. Das ist normal; das Bild, das Sie sehen, ist schon ein verarbeitetes Bild. Der eigentliche Unterschied liegt zwischen dem lokalen Pfad und dem, was die Netzwerk-Encodierung daraus macht.

Dieser Leitfaden erklärt, warum diese Trennung existiert, wie Sie die tatsächliche Stream-Qualität messen und wie Sie die häufigsten Ursachen von Qualitätsverlust beheben. Beachten Sie, dass das Webcam-Tool dieser Seite den lokalen Aufnahme-Track prüft: Es zeigt Bildrate und Frames, die der Browser von Ihrer Kamera erhält, nicht die Qualität, die Sie in einen WebRTC-Anruf senden. Die Encodierungsseite ist die Aufgabe dieses Leitfadens.

Warum die Vorschau lügt

Die Vorschau zeigt die lokale Capture-Ansicht: einen Frame, der von Ihrer Kamera erzeugt, über getUserMedia() geliefert und vom Browser verarbeitet wurde, bevor er Ihr Fenster erreicht. Sie zeigt die Fähigkeiten Ihres Geräts, nicht die Zustellung an den Gesprächspartner.

Der Stream ist eine andere Pipeline. Der Browser encodiert die lokalen Frames mit einem Codec — typischerweise VP8 oder H.264, auf neueren Geräten AV1 — und WebRTC entscheidet auf Basis von Netzwerkbedingungen, welche Bitrate, Auflösung und Bildrate gesendet werden. Was Sie im Vorschaubild sehen, und was nach der Encodierung über das Netzwerk geht, sind zwei verschiedene Videos: eins vor, eins nach der Encodierung.

Diese Trennung existiert, weil die Encodierung die einzige Stelle ist, an der Qualität und Bandbreite gegeneinander abgewogen werden. Ohne Herabstufung würde ein Videoanruf bei schlechten Netzwerkbedingungen einfrieren. Der Preis ist, dass der Qualitätsverlust in der Vorschau unsichtbar bleibt — die Vorschau wird vom lokalen Capture gespeist, nicht vom encodierten Output, weshalb Sie die Qualität, die der Gesprächspartner sieht, aus dem Vorschaubild nicht ablesen können. Wenn die Auflösung Ihres Anrufs niedriger ist als Ihre Kamera-Einstellungen, ist die Ursache typischerweise bandbreitenbezogen — was Ihr Browser ausgeben darf und ob Ihre Verbindung den Stream trägt, den Sie zu senden glauben — aber CPU-Last, Encoder-Auswahl, Plattform-Richtlinien und Constraint-Konfiguration können ebenfalls beitragen oder dominieren.

Die Vorschau ist das Versprechen; der Stream ist die Lieferung. Sie sind unterschiedlich, weil sie aus unterschiedlichen Pfaden gespeist werden. Der Encoder verhandelt im Hintergrund drei Parameter, und jeder kann sich während eines Anrufs ohne Benachrichtigung ändern:

• Auflösung — Breite und Höhe der encodierten Frames, die von 1920×1080 auf 1280×720 oder 640×480 fallen können.
• Bildrate — wie viele Bilder pro Sekunde die Encodierung überstehen, fällt häufig zuerst (von 30 auf 15 oder weniger), da eine Halbierung der Bildrate die Datenrate halbiert, ohne die Auflösung zu ändern — einige Implementierungen reduzieren jedoch die Auflösung, je nach Codec und Plattform.
• Bitrate — wie viele Bits pro Sekunde der Encoder ausgeben darf, was das Gesamtkompressionsniveau bestimmt. Diese drei Werte bestimmen alles, was die Gegenseite sieht. Ein 1080p-Bild, das auf eine niedrige Bitrate komprimiert wird, wirkt weich und verschmiert. Ein 30-fps-Stream, der plötzlich mit 10 fps läuft, wirkt ruckelig und unnatürlich. Wenn Sie verstehen, dass die Vorschau keinen dieser Werte anzeigt, löst sich das Rätsel des schlechten Anrufs mit einer guten Kamera auf.

SDP verhandelt, bevor Sie ein Frame senden

Die Aushandlung beginnt, bevor das erste Frame gesendet wird. Wenn Sie einem Anruf beitreten, tauschen Plattform und Browser ein Session Description Protocol (SDP)-Offer und -Answer aus. Das SDP wirbt für die Codecs und Medienfähigkeiten, die jede Seite unterstützt; tatsächliche Auflösung und Bildrate werden dann über Sende- und Empfangsparameter weiterverhandelt und durch Bandbreitenschätzung begrenzt. Die tatsächliche Codec-Auswahl hängt vom Browser, der Plattform, den SDP-Parametern und den Hardwarefähigkeiten ab. Häufige Wahlmöglichkeiten sind VP9, H.264, VP8 und AV1, aber es gibt keine feste Präferenzreihenfolge über alle Plattformen hinweg. Codec-Auswahl ist erst der Anfang. Sobald der Anruf läuft, übernimmt ein zweiter Mechanismus: Bandbreitenschätzung. WebRTC überwacht kontinuierlich den Netzwerkpfad in beide Richtungen und führt einen Überlaststeuerungsalgorithmus — meistens Google Congestion Control —, der drei Messungen fortlaufend durchführt:

• Paketverlust, vom Empfänger über RTCP-Feedback-Nachrichten gemeldet.
• Round-Trip-Zeit, die Verzögerung zwischen dem Senden eines Pakets und dem Empfang einer Bestätigung.
• Durchsatz, die effektive Rate, mit der Daten die Verbindung tatsächlich überqueren. Der Algorithmus speist diese Messungen in ein Modell, das schätzt, wie viel Bandbreite das Netzwerk aktuell tragen kann. Diese Schätzung wird als Ziel-Bitrate an den Encoder übergeben, der seinen Output anpasst. Die Schleife ist kontinuierlich und schnell: Fällt die Schätzung, encodiert der Encoder innerhalb von Bruchteilen einer Sekunde mit niedrigerer Bitrate neu. Die Schwellen sind ungefähr und hängen vom jeweiligen Überlaststeuerungsalgorithmus ab. Anhaltender Paketverlust über etwa fünf Prozent kann eine Senkung der Ziel-Bitrate auslösen, aber das genaue Verhalten — wie stark die Rate fällt, ob auch Auflösung oder Bildrate sich ändern und bei welchem Verlustgrad — variiert je nach Algorithmus, Codec und Plattform. Ein 1080p-Stream bei 30 fps benötigt typischerweise etwa vier bis sechs Megabit pro Sekunde Upload-Bandbreite, um sauber auszusehen. Kommt der Schätzer zum Schluss, dass nur ein Megabit verfügbar ist, erzwingt er nicht den Stream, sondern senkt das Ziel, und der Encoder antwortet mit einer Senkung auf 480p und 15 fps (Google: WebRTC Congestion Control Whitepaper, 2019; RFC 8888: Congestion Control Feedback for RTP).

Zusätzlich zu Codec und Bandbreitenschätzung beeinflussen weitere Faktoren die Codierung: Die Plattform-Politik von Videokonferenz-Tools setzt oft eigene Qualitätsgrenzen durch — Bildraten-Caps, Auflösungsgrenzen oder Bitraten-Obergrenzen. Auch die CPU Ihres Endgeräts encodiert in Echtzeit; bei hoher Last kann der Encoder die Bildrate oder Auflösung senken, selbst wenn Bandbreite reichlich vorhanden ist. Keine dieser Entscheidungen zeigt eine Meldung an. Die Vorschau sieht weiterhin großartig aus. Jeder Frame, den Sie senden, durchläuft folgende Stufen:

1. Der Kamerasensor erfasst ein Bild; der Browser liefert es über getUserMedia() mit der angeforderten Auflösung und Bildrate, was Skalierung, Farbkonvertierung und Constraint-Verarbeitung umfassen kann.
2. Der Browser empfängt das Bild über die getUserMedia()-API und reicht es an die WebRTC-Engine. Ihre lokale Vorschau wird aus dieser Stufe gespeist — deshalb sieht sie immer perfekt aus.
3. Der WebRTC-Encoder komprimiert das Bild mit einem ausgehandelten Codec, bei einer ausgehandelten Auflösung, Bildrate und Bitrate.
4. Das encodierte Bild wird in RTP-Pakete aufgeteilt und über das Netzwerk gesendet, meistens über einen Medienserver, der es an alle anderen weiterleitet.
5. Jeder Empfänger decodiert die Pakete zurück in ein Bild und stellt es auf seinem Bildschirm dar.

Drei versteckte Fehlermuster

Die Vorschau bleibt bei drei typischen Fehlern makellos, weil sie vor dem Encoder abgegriffen wird. Erst der gesendete Stream zeigt den Schaden. Die Symptome unterscheiden sich, deshalb muss auch die Diagnose unterschiedlich ausfallen.

Die Bitratenfalle

Symptome: Ihre Vorschau ist scharf, die CPU hat Reserven, doch die Gegenseite sieht dauerhaft ein unscharfes Bild. Lokale Aufnahmen sind sauber, nur der Anruf bleibt schlecht. Diagnose: Die Bandbreitenschätzung begrenzt die Zielbitrate, sodass der Encoder die Auflösung senkt. Prüfen Sie den Upload und vergleichen Sie ihn mit den groben 4–6 Mbit/s, die 1080p30 häufig benötigt. Andere Streams, Downloads und Synchronisationen teilen sich dieses Budget.

Die Verlustschwelle

Symptome: Einzelbilder wirken brauchbar, Bewegung ruckelt jedoch. Audio bleibt stabil, während das Video kurz einfriert und danach mit weniger Bildern pro Sekunde zurückkommt. Diagnose: Paketverlust überschreitet zeitweise etwa fünf Prozent. Die Überlaststeuerung senkt wiederholt die Zielbitrate, und der Encoder verwirft Frames. Prüfen Sie WLAN-Störungen, ein fehlerhaftes Ethernet-Kabel oder ein VPN. Der konkrete Schwellenwert ist algorithmus- und plattformabhängig.

Das Keyframe-Einfrieren

Symptome: Nach dem Beitritt oder einer Bildschirmfreigabe bleibt das Bild zwei bis fünf Sekunden eingefroren oder stark verschmiert und wird dann plötzlich scharf. Diagnose: Keyframes enthalten das vollständige Bild, Delta-Frames nur Änderungen. Verlorene Delta-Pakete können eine erneute Übertragung (NACK) oder einen neuen Keyframe (PLI/FIR) auslösen. Wenn die Anfrage nicht rechtzeitig ankommt, wartet der Empfänger auf den nächsten Keyframe. Kürzere Intervalle erholen sich schneller, kosten aber Bandbreite; längere Intervalle sind effizienter, machen Verluste sichtbarer. Das ist Codec-Verhalten, nicht zwingend ein Defekt.

Den echten Stream mit getStats() messen

Die WebRTC-API stellt mit getStats() Messwerte des Encoders bereit. Filtern Sie im Bericht der aktiven RTCPeerConnection den Eintrag outbound-rtp mit kind: video und vergleichen Sie ihn mit media-source:

• framesPerSecond bei media-source zeigt, was die Kamera dem Encoder liefert. Liegt der Wert unter 30 bei einer 30-fps-Kamera, ist der Capture-Pfad das Problem — häufig ein Fall von USB-Bandbreitenkonkurrenz; unser Leitfaden zur USB-Bandbreitenkonkurrenz erklärt, wie Sie das diagnostizieren.
• framesPerSecond bei outbound-rtp zeigt, was der Encoder tatsächlich erzeugt. Ist dieser Wert niedriger als die Eingangsrate, verwirft der Encoder Frames.
• frameWidth und frameHeight bei outbound-rtp sind die echte gesendete Auflösung.
• bytesSent zweimal mit einer Sekunde Abstand ergibt über die Differenz mal acht die Bitrate.
• packetsSent und packetsLost — beachten Sie, dass packetsLost im outbound-rtp-Eintrag nicht immer befüllt ist; die Verlustrate ist zuverlässiger aus remote-inbound-rtp zu lesen.
• currentRoundTripTime im candidate-pair beschreibt die Netzwerklaufzeit.

Unterschiedliche Browser lassen Felder weg oder benennen sie leicht anders. Chrome und Edge zeichnen die Werte unter chrome://webrtc-internals samt Zeitverlauf auf. Messen Sie einmal im Leerlauf und einmal während eines ausgelasteten Meetings. Wenn outbound-rtp von 30 auf 18 fps fällt, während media-source bei 30 bleibt, liegt die Begrenzung hinter der lokalen Aufnahme. Das Webcam-Testwerkzeug liefert dafür nur die lokale Referenz, nicht den ausgehenden WebRTC-Stream.

Zoom, Meet und Teams sind drei verschiedene Kameras

Die gleiche Kamera kann in verschiedenen Anwendungen unterschiedlich aussehen, weil jede Plattform eigene Regeln über WebRTC legt:

• Zoom priorisiert häufig Stabilität und kann je nach Version, Konto und Meeting-Einstellung die Auflösung begrenzen.
• Google Meet passt sich der gemessenen Bandbreite an und senkt die Auflösung oft früh, stellt sie bei besseren Bedingungen aber wieder her.
• Microsoft Teams verwendet eine eigene Encodierungs- und Nachbearbeitungskette und kann zusätzlich komprimieren.
• Reines Browser-WebRTC hat keine zusätzliche Plattformpolitik und ist daher der beste Referenzpunkt für Hardware und Netzwerk.

Das ist kein Kameravergleich, sondern ein Vergleich von Encodierungsentscheidungen. Ist der Rohstream sauber und nur eine Plattform schlecht, liegt die Grenze wahrscheinlich dort. Plattformregeln hängen von Version, Konto und Teilnehmerzahl ab und sind daher nur allgemeine Tendenzen.

Sieben Schritte zu einem stabilen Stream

1. Zuerst messen: Auflösung, Bildrate und Bitrate in chrome://webrtc-internals oder getStats() notieren.
2. Upload prüfen: Für 720p etwa 1 Mbit/s, für 1080p grob 4 Mbit/s oder mehr einplanen; nach Möglichkeit Ethernet verwenden.
3. Licht verbessern: Ein hell ausgeleuchtetes Gesicht lässt sich stärker komprimieren als ein dunkles, rauschendes Bild.
4. Video-Rauschunterdrückung deaktivieren, wenn Raum und Licht bereits ruhig sind; die Option ist plattformabhängig.
5. Virtuellen Hintergrund ausschalten: Segmentierung kostet GPU-Zeit und kann den effektiven Bitratenbedarf erhöhen.
6. Codec prüfen: VP9 ist oft effizienter, H.264 codiert auf vielen Geräten schneller; kein Codec ist universell überlegen.
7. Andere Plattform testen: Gute Werte auf einer Plattform und schlechte auf einer anderen sprechen für deren Richtlinie, nicht für einen Kameradefekt.

Fazit

Die Vorschau zeigt den lokalen Capture-Track. Der Stream zeigt, was nach Aushandlung, Encodierung und Netzwerkbedingungen tatsächlich ankommt. Öffnen Sie chrome://webrtc-internals, prüfen Sie outbound-rtp und vergleichen Sie Auflösung und Bildrate mit Ihrer Kameraeinstellung. Bandbreite ist häufig der Auslöser, aber CPU-Last, Codec, Plattformregeln und Constraints können ebenso entscheidend sein.