Eine intelligentere, sicherere Video API

Video in Echtzeit kann eine Herausforderung sein. Die Teilnehmer nehmen von verschiedenen Geräten, über verschiedene Netzwerke und in verschiedenen Teilen der Welt teil. Die Bedingungen ändern sich während eines Anrufs: Ein mobiles Gerät kann von Wi-Fi auf Mobilfunkdaten umschalten (z. B. von 5G auf 4G), eine Unternehmens-Firewall kann bestimmte UDP-Pfade blockieren, und ein Low-End-Laptop kann unter CPU-Last leiden.

Die Video API von Vonage basiert auf einer Reihe intelligenter, sich ergänzender Funktionen, die eine kontinuierliche Anpassung der Sitzung an sich ändernde Bedingungen ermöglichen. Diese Funktionen sind in drei Schichten organisiert, die jeweils eine andere Ebene des Stacks adressieren:

  • Topologie-Ebene: Sitzungsinfrastruktur, Routing-Optimierungen und Server-Lebenszyklus. Diese betreffen alle Teilnehmer einer Sitzung und erfordern keine Konfiguration pro Stream.
  • Peer-Verbindungsebene: Wie einzelne Clients eine Verbindung zum Media Router herstellen und mit ihm verhandeln. Diese Einstellungen gelten einmal pro Client, aber es kann mehrere Clients innerhalb desselben Endgeräts geben.
  • Stromebene: Qualitätsregler pro Stream: Codec, Auflösung, Bitrate und mehr. Diese können unabhängig für jeden Herausgeber und Abonnenten eingestellt werden.

Die Bausteine

Die Funktionen sind in drei konzentrischen Schichten organisiert. Die äußeren Schichten wirken sich auf alle Teilnehmer aus; die inneren Schichten können pro Stream eingestellt werden.

╔══════════════════════════════════════════════════════════════════════╗
║  TOPOLOGY LAYER                                                      ║
║  Routed vs. Relayed · Adaptive media routing · Media Mesh            ║
║  Session migration                                                   ║
║  ┌──────────────────────────────────────────────────────────────┐    ║
║  │  PEER-CONNECTION LAYER                                       │    ║
║  │  Single peer connection (SPC) · Codec negotiation            │    ║
║  │  ┌────────────────────────────────────────────────────┐      │    ║
║  │  │  STREAM LAYER                                      │      │    ║
║  │  │  Scalable video · Bitrate presets                  │      │    ║
║  │  │  Publisher resolution/frame rate                   │      │    ║
║  │  │  Subscriber preferred resolution/frame rate        │      │    ║
║  │  │  Audio fallback · FEC / NACK / DTX                 │      │    ║
║  │  └────────────────────────────────────────────────────┘      │    ║
║  └──────────────────────────────────────────────────────────────┘    ║
║  Monitoring: client observability · sender-side stats · MOS          ║
╚══════════════════════════════════════════════════════════════════════╝

Die Überwachungsebene erstreckt sich über alle drei Ebenen und bietet Einblick in die Qualität auf jeder Ebene.

Unter der Haube: Der WebRTC-Stack

Viele der Zuverlässigkeitsgarantien stammen von Funktionen, die in den WebRTC-Stack integriert sind und keinen expliziten API-Aufruf erfordern. Wenn Sie diese verstehen, können Sie das Qualitätsverhalten besser einschätzen und die APIs auf höherer Ebene effektiver nutzen.

Staukontrolle und Ratenanpassung

WebRTC-Implementierungen verwenden standardmäßig Google Congestion Control (GCC). GCC prüft kontinuierlich die verfügbare Bandbreite, schätzt den aktuellen Engpass und signalisiert dem Encoder, seine Zielbitrate zu erhöhen oder zu senken. Dies ist der wichtigste Mechanismus, der eine Sitzung bei vorübergehenden Engpässen aufrechterhält. Jede Vonage Video API-Einstellung, die die Bitrate beeinflusst, wirkt wie eine Decke auf dem GCC, und der GCC passt sich unterhalb dieser Obergrenze weiterhin dynamisch an.

Vorwärts-Fehlerkorrektur (FEC)

Audiostreams versuchen standardmäßig, Opus FEC auszuhandeln. Der Opus-Codec bettet eine qualitativ schlechtere Kopie jedes Audio-Frames in die nächste Rahmen. Wenn der erste Frame bei der Übertragung verloren geht, rekonstruiert der Empfänger ihn aus der Kopie des folgenden Pakets, was mit einem geringen Bandbreiten-Overhead verbunden ist. Dies ist besonders effektiv bei zufälligen Paketverlusten, wie sie in überlasteten Wi-Fi- oder Mobilfunknetzen auftreten.

Für Video unterstützen alle Codecs RTP RED FEC, wenn es ausgehandelt wurde. FEC ist für Ihre Anwendung transparent und fügt dem Medienstrom Redundanz hinzu, so dass der Empfänger verlorene oder beschädigte Pakete wiederherstellen kann, ohne dass eine erneute Übertragung erforderlich ist. Für weitere Informationen lesen Sie bitte die RFC 8854.

NACK und RTX (Rückübertragung)

Wenn ein Videopaket verloren geht, sendet der Empfänger ein Negative ACK (NACK), um eine erneute Übertragung anzufordern. NACK/RTX führt zu einer zusätzlichen Latenzzeit, die proportional zur Umlaufzeit ist (normalerweise zwischen 50 und 200 ms).

Diskontinuierliche Übertragung (DTX)

Opus DTX erkennt die Stille am Mikrofon und stoppt das Senden von Audiopaketen in ruhigen Zeiten, wodurch die Audiobandbreite auf nahezu Null reduziert wird. Sie können DTX über das Menü enableDtx Einstellung des SDK Ihrer Wahl, wenn Sie den Publisher initialisieren.

DTLS-SRTP und sicheres Echtzeit-Transportprotokoll

Alle Medien werden standardmäßig mit DTLS-SRTP verschlüsselt. Die Aushandlung der Verschlüsselungsschlüssel erfolgt als Teil des WebRTC-Handshakes, bevor die Medien übertragen werden. Zur Erhöhung der Sicherheit wird der AES-256 Add-on-Feature bietet 256-Bit-Verschlüsselung. Diese Verschlüsselungsmethoden auf der Transportebene (DTLS-SRTP und AES-256) funktionieren zusammen mit der optionalen Funktion End-to-End Encryption (E2EE), die eine zusätzliche Verschlüsselungsebene auf Anwendungsebene bietet. Siehe die Leitfaden zur End-to-End-Verschlüsselung für weitere Einzelheiten.

ICE und TURN

Interactive Connectivity Establishment (ICE) versucht mehrere Pfade zwischen Endpunkten (direktes UDP, STUN-reflexiv, TURN-Relay) und wählt den besten aus. Wenn sich der beste Pfad während des Gesprächs ändert (was häufig der Fall ist, wenn ein mobiles Gerät das Netz wechselt), kann ICE neu starten und einen neuen Pfad finden, ohne den Anruf zu unterbrechen. Für Sitzungen, die restriktive Firewalls durchqueren, siehe den Abschnitt Anleitung für konfigurierbare TURN-Server und die Leitfaden für eingeschränkte Netzwerke.

Optimierungen auf Topologieebene

Die Merkmale auf Topologieebene bestimmen die Infrastruktur durch die Medien fließen. Sie werden beim Aufbau einer Sitzung oder beim Verbindungsaufbau festgelegt und betreffen alle Teilnehmer gleichermaßen. Die richtige Topologie ist das Fundament, auf dem alles andere aufbaut.

Medien-Modus: Routed vs. Relayed

Die grundlegendste Entscheidung über die Topologie ist Medienbetrieb.

  • Vermittelte Sitzungen: Clients versuchen, Audio-/Videoströme direkt zueinander zu senden (Peer-to-Peer) und greifen auf TURN-Relay zurück, wenn eine Firewall den direkten Pfad blockiert. Relayed-Sitzungen haben eine geringere Latenz für kleine Gruppen, können aber kein skalierbares Video, Subscriber Audio Fallback, eine einzelne Peer-Verbindung oder senderseitige Statistiken verwenden.
  • Geplante Sitzungen: Medien fließen durch den Vonage Video Media Router. Dadurch wird der gesamte Smart-Feature-Stack freigeschaltet: skalierbares Video, Subscriber Audio Fallback, Single Peer Connection (SPC), senderseitige Statistiken, Live-Streaming-Übertragungen, Archivierung, SIP-Interconnect und mehr.

Für Sitzungen mit drei oder mehr Teilnehmern sollten Sie immer eine geroutete Sitzung verwenden. Siehe die Erstellen eines Sitzungsleitfadens.

Adaptives Medien-Routing

In gerouteten Sitzungen (ab SDK v2.24.7+ für Web und v2.27.0+ für native) verwendet die Plattform automatisch adaptives Medien-Routing um den Datenverkehr zwischen den Teilnehmern zu optimieren. Wenn Publisher nur einen Abonnenten haben und keine reinen Routing-Funktionen (Archivierung, Live-Streaming, SIP usw.) aktiviert sind, werden die Medien direkt zwischen Publishern und Abonnenten geroutet, ohne dass im Vorfeld eine Relayed Session deklariert wird. Sobald ein Herausgeber mehr als einen Abonnenten hat oder eine reine Routing-Funktion aktiviert ist, übernimmt der Media Router nahtlos das Routing. In Konversationsanwendungsfällen (alle Teilnehmer veröffentlichen und abonnieren gleichzeitig) ohne "Routed-only"-Funktionen wird die Sitzung beispielsweise nahtlos zum Media Router verschoben, sobald der dritte Teilnehmer hinzukommt.

Das bedeutet, dass Sie praktisch für alle Fälle eine geroutete Sitzung deklarieren können und trotzdem eine fast zeitgleiche Latenz für 1:1-Anrufe erhalten. Das adaptive Medien-Routing ist standardmäßig aktiviert und erfordert keine Konfiguration. Siehe die Erstellen eines Sitzungsleitfadens.

Media Mesh

Die Plattform verwendet Media Mesh um jeden Teilnehmer automatisch mit dem ihm nächstgelegenen Media Router-Rechenzentrum zu verbinden (Sie können die hier die Liste aller verfügbaren Rechenzentren). Bei einer geografisch verteilten Sitzung (z. B. mit Teilnehmern in New York, Frankfurt und Sydney) stellt Media Mesh sicher, dass jeder Client die Medien über den nächstgelegenen regionalen Server leitet, anstatt ein einzelnes, möglicherweise weit entferntes Rechenzentrum zu durchlaufen. Das Ergebnis sind geringere Latenzzeiten und eine bessere Qualität für alle Teilnehmer, insbesondere bei großen internationalen Sitzungen.

Media Mesh ist standardmäßig aktiviert und erfordert keine Konfiguration. Wenn Sie mehr Kontrolle darüber benötigen, wohin die Medien geleitet werden, haben Sie zwei Personalisierungsoptionen:

  • Hinweis auf den Standort (Best-Effort): Sie können ein bevorzugtes Signalisierungsdatenzentrum als Hinweis angeben. Die Plattform wird versuchen, den angefragten Standort zu verwenden, wenn dies möglich ist. Dies ist jedoch nicht garantiert und kann auf der Grundlage von Verfügbarkeit, Kapazität oder anderen betrieblichen Überlegungen auf ein anderes Rechenzentrum zurückgreifen. Siehe die Erstellen eines Sitzungsleitfadens für weitere Informationen.

  • Regionale Medienzone (erzwungen): Wenn Sie das Medien-Routing innerhalb einer bestimmten Region halten müssen (aus Gründen der Datenresidenz oder der Einhaltung von Vorschriften), konfigurieren Sie eine regionale Medienzone. Diese Einstellung ist erzwungen: Signalisierung und Medien werden durch die ausgewählte Zone geroutet, anstatt automatisch das nächstgelegene Rechenzentrum zu wählen. Zusätzliche Dokumentation finden Sie in der Leitfaden für regionale Medienzonen.

Sitzung Migration

Was es bewirkt: Überträgt alle Teilnehmer einer Sitzung transparent auf einen neuen Media Router-Server, wenn ein geplanter Serverwechsel stattfindet, ohne die Verbindung zu unterbrechen. Es ist keine anwendungsseitige Handhabung erforderlich (d. h., Anwendungen müssen keine eigene Übertragungs-/Verbindungslogik implementieren; die Plattform führt dies für sie durch).

Warum das wichtig ist: Eine Cloud-Infrastruktur ist nie statisch. Server werden gepatcht, skaliert und ersetzt. Ohne Sitzungsmigration zwingt eine Serverrotation jeden Teilnehmer dazu, die Verbindung zu unterbrechen und wiederherzustellen, was bei einer Sitzung von mehr als 8 Stunden zu einer Störung führen kann. Bei aktivierter Sitzungsmigration (SDK v2.30.0+) ist der Übergang unsichtbar: Streams werden fortgesetzt, es werden keine Ereignisse zur erneuten Verbindung ausgelöst, und vorhandenes Audio/Video wird nicht unterbrochen.

Was noch einen Neustart erfordert: Aufzeichnungen (Archive), Live-Streaming-Übertragungen und Experience Composer-Instanzen enden, wenn eine Sitzung migriert wird, und müssen über den Sitzungsbenachrichtigungs-Callback neu gestartet werden. Automatische Archive automatisch neu starten.

Wie man sie aktiviert: Pass sessionMigration: true in den Sitzungsinitialisierungsoptionen für jeden Client. Standardmäßig ist dies false. Siehe die Leitfaden für Serverrotation und Sitzungsmigration für die vollständige SDK-spezifische Syntax, das manuelle Auslösen und für Details zur Handhabung des Sitzungsbenachrichtigungs-Callbacks.

Automatische Wiederherstellung der Verbindung

Was es bewirkt: Wenn ein Client unerwartet die Verbindung zu einer Sitzung verliert, versucht das SDK automatisch, die Verbindung wiederherzustellen, ohne dass ein Anwendungscode erforderlich ist.

Warum das wichtig ist: Ohne automatische Wiederherstellung der Verbindung würde ein kurzes Netzproblem den Benutzer zwingen, die Sitzung manuell wieder aufzunehmen. Bei der automatischen Wiederherstellung der Verbindung übernimmt das SDK die Wiederherstellung auf transparente Weise. Streams, die abonniert wurden, werden angehalten und automatisch wieder aufgenommen, wenn die Verbindung wiederhergestellt ist.

Wie es funktioniert: Es ist keine Konfiguration erforderlich. Wenn die Verbindung unterbrochen wird und der Client versucht, eine neue Verbindung herzustellen:

  • Das Session-Objekt sendet eine sessionReconnecting Veranstaltung.
  • Wenn die Verbindung wiederhergestellt ist, sendet das Session-Objekt eine sessionReconnected Veranstaltung.
  • Wenn die Verbindung nicht wiederhergestellt werden kann, trennt der Client die Verbindung und der sessionDisconnected Ereignis ausgelöst wird.

Ihre Anwendung kann optional auf diese Ereignisse warten, um dem Benutzer Statusanzeigen zu liefern:

session.on({
  sessionReconnecting: function() {
    // Display a "reconnecting..." indicator
  },
  sessionReconnected: function() {
    // Hide the indicator
  },
  sessionDisconnected: function() {
    // Handle permanent disconnection
  }
});

Signale, die bei vorübergehend unterbrochener Verbindung gesendet werden, werden in eine Warteschlange gestellt und zugestellt, sobald die Verbindung wiederhergestellt ist. Siehe die Beitritt zu einem Sitzungsleiter für vollständige Beispiele und SDK-spezifische Ereignisnamen.

Strategien auf der Ebene der Peer-Verbindungen

Funktionen auf Peer-Verbindungsebene bestimmen, wie die WebRTC-Verbindungen eines Clients zum Media Router strukturiert sind und welche Codecs sie aushandeln. Diese Einstellungen gelten einmal pro Client (nicht pro Stream) und haben einen weitreichenden Einfluss auf den Ressourcenverbrauch und die Kompatibilität.

Einzel-Peer-Verbindung (SPC)

Was es bewirkt: Bündelt alle Abonnenten-Streams für einen Client in einer einzigen WebRTC-Peer-Verbindung zum Media Router, anstatt einer Verbindung pro Stream.

Warum das wichtig ist: Jede zusätzliche Peer-Verbindung verursacht zusätzlichen Aufwand: separate ICE-Kandidaten, DTLS-Handshakes und Socket-Status auf Betriebssystemebene. Auf einem mobilen Gerät, das zehn Streams abonniert, können zehn Peer-Verbindungen das Gerät belasten und viel Strom verbrauchen. SPC reduziert dies auf eine Verbindung, was den Ressourcenverbrauch senkt und größere Sitzungen auf nativen mobilen Clients ermöglicht.

Zusätzlicher Vorteil - Ratenkontrolle: Bei einer einzigen Verbindung sieht der WebRTC-Überlastungscontroller alle eingehende Datenströme als ein einziges Bündel und kann Entscheidungen zur Ratenanpassung in besserer Kenntnis der Sachlage treffen. Beim Modell mit mehreren Verbindungen führt jede Verbindung unabhängig voneinander Tests und Anpassungen durch, was zu Oszillationen und einer suboptimalen gemeinsamen Nutzung der Bandbreite führen kann.

Wie man sie aktiviert: SPC ist standardmäßig ausgeschaltet. einstellen singlePeerConnection: true beim Initialisieren der Sitzung. Für das Web-SDK übergeben Sie es als Eigenschaft in der OT.initSession() Options-Objekt. Für andere SDKs:

  • Android: Session.Builder.setSinglePeerConnection(true)
  • iOS: OTSessionSettings.singlePeerConnection = YES
  • Fenster: SinglePeerConnection Eigentum an Session.Builder
  • Linux/macOS: otc_session_settings_set_single_peer_connection()
  • React Native: enableSinglePeerConnection in der OTS-Sitzung options Stütze

Siehe die Erstellen eines Sitzungsleitfadens für vollständige Beispiele.

Wann es zu verwenden ist: Aktivieren Sie SPC immer dann, wenn Sie mehr als eine Handvoll Abonnenten in einer gerouteten Sitzung haben - insbesondere auf mobilen Plattformen. Die Vorteile steigen mit der Anzahl der Streams.

Codec-Auswahl

Was es bewirkt: Wählt den Videocodec aus, der zwischen jedem Publisher-Teilnehmer-Paar verwendet wird.

Warum das wichtig ist: Die Wahl des Codecs beeinflusst die Qualität bei einer bestimmten Bitrate, die CPU-Nutzung, die Verfügbarkeit von Hardware-Beschleunigung und die Kompatibilität mit skalierbarem Video. VP8 ist der sicherste Standard: Er wird allgemein unterstützt, ist auf den meisten Plattformen hardwarebeschleunigt und mit skalierbarem Video kompatibel. VP9 bietet eine bessere Qualität bei gleicher Bitrate, allerdings mit höheren CPU-Kosten. H.264 profitiert von Hardware-Encodern auf iOS- und einigen Android-Geräten, die den Akkuverbrauch reduzieren, unterstützt aber kein skalierbares Video.

So funktioniert es automatisch: Die Vonage-Plattform handelt den Codec für jedes Publisher-Teilnehmer-Paar aus und berücksichtigt dabei die Präferenz auf Projektebene, während sie auf VP8 zurückgreift, wenn der bevorzugte Codec nicht von beiden Endpunkten unterstützt wird.

Wann man eingreifen sollte: Siehe die Video-Codecs-Leitfaden für vollständige Entscheidungskriterien, die VP9 Skalierbares Video Anleitung für VP9-spezifisches Verhalten, und die SDK Codec-Präferenz-API pro Verlag zu überschreiben.

End-to-End-Verschlüsselung (E2EE)

Was es bewirkt: Verschlüsselt die Medien-Nutzdaten auf dem Client, so dass sie im gesamten Medien-Router verschlüsselt bleiben und nur von anderen Teilnehmern derselben Sitzung entschlüsselt werden können. Dies bietet eine zusätzliche Verschlüsselungsschicht über der Standard-DTLS-SRTP-Transportverschlüsselung.

Warum das wichtig ist: In standardmäßig gerouteten Sitzungen kann der Media Router auf unverschlüsselte Medien zugreifen (was für Funktionen wie Archivierung, Transkodierung und skalierbare Videoschichtauswahl erforderlich ist). E2EE verhindert, dass der Media Router auf den Medieninhalt zugreift, was für Anwendungsfälle erforderlich ist, bei denen ein strenger Datenschutz Ende-zu-Ende gewährleistet sein muss.

Wichtige Zwänge: Wenn E2EE aktiviert ist, sind Funktionen, die eine Mediendekodierung am Media Router erfordern, nicht verfügbar: Archivierung, Live-Streaming-Übertragungen, Experience Composer, Audio Connector und SIP-Interconnect. Stellen Sie sicher, dass Sie diese Einschränkungen berücksichtigen, bevor Sie E2EE aktivieren.

Wie man sie aktiviert: E2EE ist eine Zusatzfunktion, die zunächst für Ihren Vonage Video Account aktiviert werden muss. Nach der Aktivierung erstellen Sie die Sitzung mit e2ee: true mit der serverseitigen Vonage Video API, und legen Sie das Verschlüsselungsgeheimnis bei der Initialisierung der Sitzung im Client fest:

vonage.video.createSession({ mediaMode: "routed", e2ee: true });

Alle Teilnehmer der Sitzung müssen das gleiche Verschlüsselungsgeheimnis verwenden, um verständliche Medien zu erhalten. Das Geheimnis kann im laufenden Betrieb gewechselt werden, sobald die Sitzung verbunden ist. Siehe die Leitfaden zur End-to-End-Verschlüsselung für vollständige Installationsanweisungen und SDK-spezifische Beispiele.

Qualitätskontrollen auf Fließgewässer-Ebene

Die Funktionen auf Streamebene sind die feinsten verfügbaren Regler. Sie können unabhängig für jeden Herausgeber und Teilnehmer eingestellt werden, und viele können während eines Anrufs dynamisch geändert werden. Dies ist die Ebene, auf der Ihre Anwendung aktiv am Qualitätsmanagement beteiligt ist.

Skalierbares Video

Was es bewirkt: Der Herausgeber kodiert mehrere räumliche und zeitliche Schichten desselben Streams. Jeder Abonnent erhält die Schicht, die seinen Anforderungen an Bandbreite und Anzeige entspricht, ohne dass der Herausgeber doppelte Streams mit voller Auflösung sendet.

Warum das wichtig ist: Bei einer Sitzung mit zehn Abonnenten ist das Senden von zehn unabhängigen Full-HD-Streams vom Herausgeber eine Verschwendung, während die Anpassung eines einzelnen Streams an den am meisten eingeschränkten Abonnenten alles andere als optimal ist. Skalierbares Video sendet einen Stream mit mehreren Qualitätsebenen; der Media Router wählt die entsprechende Ebene aus und leitet sie an jeden Teilnehmer weiter. Wenn sich das Netzwerk eines Abonnenten verschlechtert, senkt der Medien-Router die Qualität seiner Schicht in Echtzeit, während der Herausgeber davon unberührt bleibt und weiterhin alle seine Schichten sendet, damit der Medien-Router seine Entscheidung treffen kann.

So funktioniert es automatisch: In gerouteten Sitzungen mit mehr als zwei Teilnehmern ermöglicht der Media Router automatisch skalierbares Video (die Auto Projekteinstellung). Das SDK des jeweiligen Herausgebers handelt die Skalierbarkeitsstruktur aus (VP8 Simulcast verwendet L1T1/L2T1/L3T1-Schichten; VP9 SVC kann auch räumliche Schichten verwenden).

Wann man eingreifen sollte: Aktivieren Sie bei Streams zur gemeinsamen Nutzung von Bildschirmen ausdrücklich die Skalierbarkeit, wenn der Media Router die Streams für Teilnehmer mit geringerer Bandbreite herunterskalieren soll. Siehe die Skalierbare Videoanleitung.

Bitratenvoreinstellungen und maximale Bitrate des Herausgebers

Was es bewirkt: Ermöglicht es Ihnen, die maximale Bitrate zu begrenzen, die ein Publisher für Kamera-Videos verwendet, indem Sie benannte Voreinstellungen (DEFAULT, BW_SAVER, EXTRA_BW_SAVER) oder Rohwerte.

Warum das wichtig ist: Bei einer gebührenpflichtigen oder überlasteten Verbindung konkurriert ein nicht eingeschränkter Publisher mit allen anderen Anwendungen auf dem Gerät um Bandbreite. Wenn Sie eine niedrigere Voreinstellung wählen, verringert sich Ihr Video-Footprint und Sie haben mehr Spielraum für andere Anwendungen auf demselben Gerät. Entscheidend ist, dass bei der Verwendung von VP8 mit aktiviertem skalierbarem Video die Voreinstellung auch steuert, welche Codierungsebenen aktiv sind, so dass BW_SAVER den Stream effektiv auf zwei räumliche Ebenen (niedrig und mittel) begrenzt und EXTRA_BW_SAVER begrenzt es auf eins (niedrig).

Interaktion mit der Ratenkontrolle: Google Congestion Control (GCC) passt sich auch unterhalb der voreingestellten Obergrenze dynamisch an. Einstellung BW_SAVER ist eine Obergrenze, kein Boden.

Verwenden Sie keine Bitratenvorgaben für die Bildschirmfreigabe. Encoder für die gemeinsame Nutzung von Bildschirmen funktionieren anders; die Anwendung einer Bitratenbegrenzung auf eine gemeinsame Nutzung von Bildschirmen kann zu einer verschwommenen Ausgabe mit niedriger Bildrate führen, ohne dass die erwartete Bandbreiteneinsparung erzielt wird. Siehe die Leitfaden für die maximale Bitrate des Herausgebers.

Publisher Auflösung und Frame Rate Kontrollen

Neben den Bitratenvorgaben können Sie die Auflösung und die Bildrate, mit der ein Publisher das Video kodiert, direkt steuern. Es gibt zwei Möglichkeiten: Sie können sie zum Zeitpunkt der Veröffentlichung festlegen oder sie dynamisch anpassen, nachdem die Veröffentlichung begonnen hat.

Einstellung von Auflösung und Bildrate zum Zeitpunkt der Veröffentlichung (Web SDK):

const publisher = OT.initPublisher(targetElement, {
  resolution: '1280x720', // '1920x1080', '1280x720', '640x480', '320x240'
  frameRate: 15,          // 30, 15, 7, or 1
});

Initialisieren Sie den Herausgeber immer bei der maximal Auflösung und Bildrate, die Sie jemals benötigen könnten (das SDK kann nur den Ausgangswert reduzieren, nicht darüber hinaus erhöhen).

Dynamische Anpassung von Auflösung und Bildrate (Web SDK):

Nachdem die Veröffentlichung begonnen hat, können Sie die vom Herausgeber bevorzugte Auflösung und Bildrate ändern, ohne den Stream neu zu starten:

// Reduce resolution
await publisher.setPreferredResolution({ width: 320, height: 180 });

// Reduce frame rate
await publisher.setPreferredFrameRate(7);

Häufige Szenarien, in denen eine dynamische Anpassung hilfreich ist:

  • Reagieren auf qualityLimitationReason: "cpu" aus den Verlagsstatistiken: Reduzieren Sie die Bildrate, um die CPU zu entlasten.
  • Reagieren auf einen plötzlichen Bandbreitenabfall, bevor der Audio-Fallback ausgelöst wird.

Hinweise zu Videoinhalten (Web SDK): Für Screen-Sharing-Streams setzen Sie den Inhaltshinweis, um die Kodierungsstrategie des Browsers zu steuern:

publisher.setVideoContentHint("text");    // Prioritises sharp text/static content
publisher.setVideoContentHint("motion");  // Prioritises smooth motion (default camera behaviour)
publisher.setVideoContentHint("detail");  // Prioritises fine detail at lower frame rates

Siehe die Leitfaden zu den Videoeinschränkungen des Herausgebers und die Veröffentlichen eines Streams - Webguide.

Publisher Video Degradation Präferenz

Was es bewirkt: Steuert, wie die Video-Engine zwischen der Verringerung der Auflösung und der Verringerung der Bildrate bei eingeschränkten Bandbreiten- oder CPU-Ressourcen priorisiert.

Warum das wichtig ist: Wenn das Netzwerk oder das Gerät die aktuelle Videoqualität nicht aufrechterhalten kann, muss der Encoder etwas verschlechtern. Standardmäßig entscheidet die Video-Engine selbstständig. Mit der Degradierungseinstellung können Sie die Priorität Ihrer Anwendung ausdrücken: Eine Bildschirmfreigabesitzung profitiert beispielsweise von der Beibehaltung der Auflösung (scharfer Text ist wichtiger als flüssige Bewegungen), während eine Kameraübertragung von der Beibehaltung der Bildrate profitiert (flüssige Bewegungen sind natürlicher als blockige Standbilder).

Beziehung zum Inhalt Hinweis: Hinweise zum Videoinhalt und Degradationspräferenz dienen unterschiedlichen, aber verwandten Zwecken. Content Hint beschreibt die Art des übertragenen Inhalts (z. B., "text" für die Bildschirmfreigabe), während die Degradierungspräferenz explizit die Codierungsstrategie steuert. Wenn Sie einen Inhaltshinweis festlegen, wählt die Video-Engine automatisch eine geeignete Degradierungspräferenz aus - zum Beispiel, "text" wählt automatisch aus, um die Auflösung beizubehalten. Eine explizit eingestellte Degradierungspräferenz setzt die automatische Auswahl von Content Hint außer Kraft.

Beziehung zu skalierbarem Video: Wenn skalierbares Video aktiv ist, kann die Video-Engine beschließen, eine zeitliche oder räumliche Ebene zu entfernen, anstatt die Auflösung des verbleibenden Streams zu verringern. Die Präferenz für die Verschlechterung gilt weiterhin als Richtschnur innerhalb der aktiven Ebenen.

SDK-spezifische APIs:

Vollständige Beispiele finden Sie in den plattformspezifischen Veröffentlichungsleitfäden: Android, iOS, iOS (Swift), Linux, Windows.

Bevorzugte Auflösung und Bildrate des Teilnehmers

Wenn Sie einen skalierbaren Videostream abonnieren, können Sie dem Medienrouter mitteilen, welche Qualitätsebene für jeden Abonnenten bereitgestellt werden soll. Dies ist das wichtigste Werkzeug für die Erstellung adaptiver Layouts. Beispielsweise sollte bei einem großen Konferenzraster für die Miniaturansichten eine niedrig auflösende Ebene und für den aktiven Sprecher die volle Auflösung verwendet werden.

Einstellung der bevorzugten Auflösung bei der Anmeldung (Web SDK):

session.subscribe(stream, targetElement, {
  preferredResolution: 'auto', // Recommended: SDK picks the layer based on element size
  // Or specify explicitly:
  // preferredResolution: { width: 320, height: 240 },
  // preferredFrameRate: 7,
});

Die "auto" Einstellung wird für die meisten Fälle empfohlen: Das Web SDK leitet automatisch leitet die bevorzugte Auflösung automatisch von der gerenderte Größe des Videoelements des Abonnenten Videoelement und fordert die am besten geeignete skalierbare Videoebene an. Beachten Sie dass "auto" ist layoutabhängig. Wenn Ihre Anwendung häufig die Größe die Größe der Teilnehmerkacheln ändert (z. B. Aktivlautsprecherumschaltung, Pin/Unpin Raster-Relayouts oder animierte Übergänge), kann das SDK die wiederholt die bevorzugte Auflösung aktualisieren. Dies kann zu häufigeren Layer-Wechsel und Bandbreiten-"Ramp-up/Ramp-down"-Zyklen auf dem Media Router auslösen, was die Netzwerkbelastung erhöhen und die visuelle Stabilität verringern kann. Bei sehr dynamischen Layouts sollten Sie die Einstellung einer expliziten preferredResolution (und Aktualisierung nur, wenn sich die Benutzeroberfläche beruhigt hat), oder Begrenzung der Auflösungsrate, um schnelles Schwanken zu vermeiden.

Dynamische Anpassung nach dem Abonnieren:

// Downgrade a tile when moving it to a thumbnail position
subscriber.setPreferredResolution({ width: 320, height: 240 });
subscriber.setPreferredFrameRate(7);

// Upgrade when the subscriber becomes the active speaker
subscriber.setPreferredResolution({ width: 1280, height: 720 });
subscriber.setPreferredFrameRate(30);

Beschränkung der Bildrate (Web SDK): subscriber.restrictFrameRate(true) begrenzt den Teilnehmer auf ein Bild pro Sekunde oder weniger. Dies kann für nicht aktive Teilnehmer in großen Sitzungen nützlich sein, um CPU und Bandbreite zu sparen und trotzdem eine "Präsenz"-Kachel anzuzeigen. aufrufen restrictFrameRate(false) um die normale Bildrate wiederherzustellen.

Für SDK-übergreifende APIs, siehe die Skalierbare Videoanleitung und die Qualitätsleitfaden abonnieren.

Audio-Fallback

Was es bewirkt: Wenn das Netzwerk eines Herausgebers oder Abonnenten nicht mehr in der Lage ist, Video zu übertragen, schaltet das SDK automatisch das Video für diesen Stream ab, während das Audio erhalten bleibt, und aktiviert es wieder, sobald sich die Bedingungen verbessern.

Warum das wichtig ist: Ein eingefrorenes Videobild ist störend, ein unterbrochener Audiostream unterbricht das gesamte Gespräch. Die Audio-Fallback-Funktion stellt sicher, dass die Teilnehmer einander auch dann noch hören können, wenn die Bandbreite erschöpft ist. In Kombination mit Opus FEC und DTX bleibt der Ton auch bei sehr niedrigen Bitraten verständlich.

Zwei komplementäre Modi:

  • Publisher Audio Fallback: Ausgelöst durch die eigene Netzwerkbewertung des Verlagsclients. Wenn die Überlastungsmetriken des Herausgebers zeigen, dass das Video nicht mehr tragbar ist, deaktiviert der Herausgeber seine Videospur. Verfügbar sowohl in weitergeleiteten als auch in gerouteten Sitzungen.
  • Teilnehmer-Audio-Fallback: Ausgelöst durch den Media Router im Namen eines bestimmten Teilnehmers. Nur der betroffene Teilnehmer verliert das Video, die anderen Teilnehmer können es weiterhin empfangen. Nur bei gerouteten Sitzungen verfügbar.

Beide Funktionen werden automatisch aktiviert. Weitere Informationen finden Sie in der Leitfaden für Audioausfälle.

Überwachung und Beobachtbarkeit

Die Überwachungsschicht erstreckt sich über alle drei Stack-Ebenen und bietet Einblick in die Qualität auf jeder Ebene, von der Infrastrukturtopologie bis hin zu einzelnen Stream-Metriken.

Qualitätsüberwachung und Kundenbeobachtung

Was es bewirkt: Die Client Observability API bietet einen kontinuierlichen Strom von Statistiken pro Stream - Paketverlust, Bitrate, Bildrate, dekodierte Auflösung, Freeze Counts und mehr - sowohl für Publisher als auch für Abonnenten. Das Web-SDK bietet außerdem einen Mean Opinion Score (MOS) für Video, einen Qualitätswert, der die MOS-Skala für Audio simuliert, sowie eine CPU-Leistungsüberwachung.

Warum das wichtig ist: Ohne Einblick in die Vorgänge an den einzelnen Endpunkten können Sie nicht zwischen "das Netz des Benutzers ist schlecht" und "das Gerät des Benutzers ist überlastet" unterscheiden. Anhand der Statistiken kann Ihre Anwendung intelligente Entscheidungen treffen: Sie können den Benutzer warnen, bevor sich die Qualität weiter verschlechtert, Layouts anpassen oder richtlinienbasierte Aktionen auslösen.

Wichtige Fähigkeiten:

  • Hochrangige Statistik-API: Aggregierte Metriken pro Verleger oder pro Teilnehmer, normalisiert über Peer-Verbindungsübergänge. Verwenden Sie dies für die Produktionsüberwachung und adaptive UX.
  • Videoqualität veränderte Ereignisse: Wird ausgelöst, wenn sich die Qualität mit einem Grundcode ändert (Bandbreite, CPU, Codec-Änderung, Auflösungsänderung). Verwenden Sie diese, um den UI-Status ohne Polling zu steuern.
  • Mittlere Meinungsbewertung (MOS): Ein branchenüblicher Qualitätswert von 1-5 (nur Web). Integrieren Sie ihn in Ihren Observability Stack, um Trends bei der Anrufqualität im Laufe der Zeit zu verfolgen.
  • Überwachung der CPU-Leistung: Erkennt geräteseitige CPU-Belastung, bevor sie zu Bildausfällen führt (nur Web). Reagieren Sie, indem Sie CPU-intensive Funktionen wie Hintergrundunschärfe deaktivieren.
  • Tests vor dem Anruf: Verwenden Sie die Vonage Video Netzwerk Testbibliothek zur Schätzung des MOS und zur Überprüfung der Audio-/Videoveröffentlichbarkeit, bevor der Benutzer einer Sitzung beitritt.

Siehe die Leitfaden zur Beobachtbarkeit von Kunden für die vollständige Statistikreferenz und SDK-spezifische Codebeispiele.

Weitere Lektüre