Codecs, die von WebRTC verwendet werden

Medien ohne Container

WebRTC verwendet rohe MediaStreamTrack-Objekte für jeden Track, der von einem Peer zum anderen geteilt wird, ohne einen Container oder sogar einen MediaStream, der mit den Tracks assoziiert ist. Welche Codecs in diesen Tracks enthalten sein können, wird durch die WebRTC-Spezifikation nicht vorgeschrieben. Allerdings legt RFC 7742 fest, dass alle WebRTC-kompatiblen Browser VP8 und H.264s Constrained Baseline-Profil für Video unterstützen müssen, und RFC 7874 spezifiziert, dass Browser mindestens den Opus-Codec sowie die PCMA- und PCMU-Formate von G.711 unterstützen müssen.

Diese beiden RFCs legen auch Optionen fest, die für jeden Codec unterstützt werden müssen, sowie bestimmte Benutzerkomfort-Funktionen wie Echo-Unterdrückung. Dieser Leitfaden überprüft die Codecs, die Browser implementieren müssen, sowie andere Codecs, die einige oder alle Browser für WebRTC unterstützen.

Während Kompression immer notwendig ist, wenn es um Medien im Web geht, ist sie beim Videokonferenzieren von zusätzlicher Bedeutung, um sicherzustellen, dass die Teilnehmer ohne Verzögerung oder Unterbrechungen kommunizieren können. Von sekundärer Bedeutung ist das Bedürfnis, Video und Audio zu synchronisieren, sodass Bewegungen und alle Zusatzinformationen (z. B. Folien oder eine Projektion) gleichzeitig mit dem zugehörigen Audio präsentiert werden.

Allgemeine Codec-Anforderungen

Bevor wir uns die codec-spezifischen Fähigkeiten und Anforderungen ansehen, gibt es einige allgemeine Anforderungen, die von allen Codec-Konfigurationen erfüllt werden müssen, die mit WebRTC verwendet werden.

Sofern das SDP nichts anderes angibt, muss der Webbrowser, der einen WebRTC-Videostream empfängt, in der Lage sein, Video mit 20 FPS bei einer Mindestauflösung von 320 Pixel Breite und 240 Pixel Höhe zu verarbeiten. Es wird empfohlen, Video mit einer Bildrate und Größe nicht unter diesem Niveau zu kodieren, da dies im Wesentlichen die untere Grenze darstellt, die WebRTC im Allgemeinen erwartet.

SDP unterstützt eine codec-unabhängige Möglichkeit, bevorzugte Videoauflösungen zu spezifizieren (RFC 6236. Dies geschieht durch das Senden eines a=image-attr SDP-Attributs, um die maximal akzeptable Auflösung anzugeben. Der Sender ist jedoch nicht verpflichtet, diesen Mechanismus zu unterstützen, daher müssen Sie darauf vorbereitet sein, Medien in einer anderen als der angeforderten Auflösung zu empfangen. Zusätzlich zu dieser maximalen Auflösungsanforderung können spezifische Codecs weitere Möglichkeiten bieten, spezifische Medienkonfigurationen anzufordern.

Unterstützte Video-Codecs

WebRTC legt eine Basislinie von Codecs fest, die alle konformen Browser unterstützen müssen. Einige Browser können auch andere Codecs zulassen.

Nachfolgend sind die Videocodecs aufgeführt, die in jedem vollständig WebRTC-konformen Browser erforderlich sind, sowie die Profile, die erforderlich sind und die Browser, die die Anforderung tatsächlich erfüllen.

Details zu WebRTC-bezogenen Überlegungen für jeden Codec finden Sie in den Unterabschnitten, indem Sie den Links auf den Namen jedes Codecs folgen.

Vollständige Details darüber, welche Videocodecs und Konfigurationen WebRTC unterstützen muss, finden Sie in RFC 7742: WebRTC Video Processing and Codec Requirements. Es ist bemerkenswert, dass das RFC eine Vielzahl von videobezogenen Anforderungen abdeckt, einschließlich Farbräume (sRGB ist der bevorzugte, aber nicht erforderliche Standardfarbraum), Empfehlungen für Webcam-Verarbeitungsfunktionen (automatischer Fokus, automatischer Weißabgleich, automatische Lichtpegel) usw.

Zusätzlich zu den Pflichtcodecs unterstützen einige Browser auch weitere Codecs. Diese sind in der folgenden Tabelle aufgeführt.

VP8

VP8, das wir allgemein beschreiben im Haupt-Leitfaden zu Videocodecs, die im Web verwendet werden, hat einige spezifische Anforderungen, die befolgt werden müssen, wenn es zum Kodieren oder Dekodieren eines Videotracks in einer WebRTC-Verbindung verwendet wird.

Sofern nicht anders signalisiert, verwendet VP8 quadratische Pixel (das heißt, Pixel mit einem Seitenverhältnis von 1:1).

Weitere Hinweise

Das Netzwerknutzlastformat zum Teilen von VP8 über RTP (wie bei der Verwendung von WebRTC) wird in RFC 7741: RTP Payload Format for VP8 Video beschrieben.

AVC / H.264

Unterstützung für das Constrained Baseline (CB)-Profil von AVC ist in allen vollständig konformen WebRTC-Implementierungen erforderlich. CB ist ein Unterset des Hauptprofils und speziell entwickelt für Anwendungen mit geringer Komplexität und niedriger Verzögerung wie mobile Video- und Videokonferenzen sowie für Plattformen mit geringer Leistungsfähigkeit in der Videobearbeitung.

Unser Überblick über AVC und seine Funktionen finden Sie im Hauptleitfaden für Videocodecs.

HEVC / H.265

Unser Überblick über HEVC und seine Funktionen finden Sie im Hauptleitfaden für Videocodecs.

Spezielle Unterstützung von Parameteranforderungen

AVC bietet eine breite Palette von Parametern zur Steuerung optionaler Werte. Um die Zuverlässigkeit des WebRTC-Medienaustauschs über mehrere Plattformen und Browser hinweg zu verbessern, ist es erforderlich, dass WebRTC-Endpunkte, die AVC unterstützen, bestimmte Parameter auf spezifische Weise handhaben. Manchmal bedeutet dies, dass ein Parameter zwingend unterstützt werden muss (oder nicht). Manchmal bedeutet es, einen bestimmten Wert für einen Parameter zu verlangen oder dass ein bestimmter Satz von Werten zugelassen wird. Und manchmal sind die Anforderungen komplexer.

Parameter, die nützlich, aber nicht erforderlich sind

Diese Parameter müssen nicht vom WebRTC-Endpunkt unterstützt werden, und ihre Verwendung ist ebenfalls nicht erforderlich. Ihre Verwendung kann das Benutzererlebnis auf verschiedene Weise verbessern, muss aber nicht verwendet werden. Tatsächlich sind einige davon recht kompliziert in der Anwendung.

max-br

Wenn angegeben und vom Software unterstützt, spezifiziert der max-br-Parameter die maximale Videobitrate in Einheiten von 1.000 bps für VCL und 1.200 bps für NAL. Details finden Sie auf Seite 47 von RFC 6184.

max-cpb

Wenn angegeben und von der Software unterstützt, spezifiziert max-cpb die maximale Größe des kodierten Bildpuffers. Dies ist ein ziemlich komplizierter Parameter, dessen Einheitengröße variieren kann. Siehe Seite 45 von RFC 6184 für Details.

max-dpb

Wenn angegeben und unterstützt, gibt max-dpb die maximale dekodierte Bildpuffergröße an, in Einheiten von 8/3 Makroblöcken. Siehe RFC 6184, Seite 46 für weitere Details.

max-fs

Wenn angegeben und von der Software unterstützt, spezifiziert max-fs die maximale Größe eines einzelnen Videorahmens, angegeben als Anzahl der Makroblöcke.

max-mbps

Wenn angegeben und von der Software unterstützt, gibt dieser Wert eine Ganzzahl an, die die maximale Anzahl an Makroblöcken angibt, die pro Sekunde verarbeitet werden sollten (in Makroblöcken pro Sekunde).

max-smbps

Wenn angegeben und von der Software unterstützt, gibt dies eine Ganzzahl an, die die maximale statische Makroblockverarbeitungsrate in statischen Makroblöcken pro Sekunde angibt (unter der hypothetischen Annahme, dass alle Makroblöcke statische Makroblöcke sind).

Parameter mit spezifischen Anforderungen

Diese Parameter müssen zwar nicht zwingend erforderlich sein, haben aber bei Verwendung spezielle Anforderungen.

packetization-mode

Alle Endpunkte müssen Modus 1 (nicht-verschachtelten Modus) unterstützen. Die Unterstützung für andere Paketisierungsmodi ist optional, und der Parameter selbst muss nicht zwingend angegeben werden.

sprop-parameter-sets

Sequenz- und Bildinformationen für AVC können entweder im Band oder außerhalb des Bandes gesendet werden. Wenn AVC mit WebRTC verwendet wird, müssen diese Informationen im Band signalisiert werden; der sprop-parameter-sets-Parameter darf daher nicht im SDP enthalten sein.

Parameter, die spezifiziert werden müssen

Diese Parameter müssen bei der Verwendung von AVC in einer WebRTC-Verbindung immer angegeben werden.

profile-level-id

Alle WebRTC-Implementierungen sind verpflichtet, diesen Parameter in ihrem SDP zu spezifizieren und zu interpretieren, um das Subprofil zu identifizieren, das vom Codec verwendet wird. Der spezifische Wert, der gesetzt wird, ist nicht definiert; was zählt, ist, dass der Parameter überhaupt verwendet wird. Dies ist bemerkenswert, da in RFC 6184 ("RTP Payload Format for H.264 Video") profile-level-id völlig optional ist.

Weitere Anforderungen

Um die Unterstützung des Wechsels zwischen Hoch- und Querformat zu ermöglichen, gibt es zwei Methoden, die verwendet werden können. Die erste ist die Videoorientierung (CVO) Header-Erweiterung zum RTP-Protokoll. Wenn dies jedoch nicht im SDP signalisiert wird, wird empfohlen, dass Browser Display Orientation SEI-Nachrichten unterstützen, obwohl dies nicht erforderlich ist.

Sofern nicht anders signalisiert, beträgt das Pixel-Seitenverhältnis 1:1, was darauf hinweist, dass die Pixel quadratisch sind.

Weitere Hinweise

Das Nutzlastformat, das für AVC in WebRTC verwendet wird, wird in RFC 6184: RTP Payload Format for H.264 Video beschrieben. AVC-Implementierungen für WebRTC müssen die speziellen SEI-Nachrichten "Füll- Payload" und "Vollbild-Freeze" unterstützen; diese werden verwendet, um das nahtlose Umschalten zwischen mehreren Eingabestreams zu unterstützen.

AV1

AV1 wird allgemein beschrieben im Haupt-Leitfaden zu Videocodecs, die im Web verwendet werden.

Abhängigkeit-Descriptor RTP Header-Erweiterung

WebRTC unterstützt zwei Haupttechnologien für die effiziente Übertragung von Video für Empfänger mit unterschiedlichen Fähigkeiten und Netzwerkbedingungen.

AV1 verwendet die Dependency Descriptor (DD) RTP Header Extension, um die für mehrteilige Konferenzanwendungsfälle benötigten Frame-Abhängigkeitsinformationen bereitzustellen.

Unterstützte Audio-Codecs

Die Audio-Codecs, die RFC 7874 vorschreibt, die alle WebRTC-kompatiblen Browser unterstützen müssen, sind in der folgenden Tabelle aufgeführt.

Unten finden Sie weitere Details zu eventuell bestehenden WebRTC-spezifischen Überlegungen für jeden der oben aufgeführten Codecs.

Es ist erwähnenswert, dass RFC 7874 nicht nur eine Liste von Audio-Codecs definiert, die ein WebRTC-konformer Browser unterstützen muss; es bietet auch Empfehlungen und Anforderungen für spezielle Audiofunktionen wie Echo-Unterdrückung, Rauschunterdrückung und Audiopegel-Kontrolle.

Zusätzlich zu den Pflichtaudio-Codecs unterstützen einige Browser auch andere Codecs. Diese sind in der folgenden Tabelle aufgeführt.

Der Internet Low Bitrate Codec (iLBC) ist ein Open-Source-Schmalband-Codec, der von Global IP Solutions und jetzt Google entwickelt wurde, speziell für das Streaming von Sprach-Audio. Google und einige andere Browser-Entwickler haben ihn für WebRTC übernommen.

Der Internet Speech Audio Codec (iSAC) ist ein weiterer Codec, der von Global IP Solutions entwickelt wurde und nun im Besitz von Google ist, welches ihn als Open Source zur Verfügung gestellt hat. Er wird von Google Talk, QQ und anderen Instant-Messaging-Clients genutzt und ist speziell für Sprachübertragungen ausgelegt, die in einen RTP-Stream gekapselt sind.

Komfortgeräusch (CN) ist eine Form von künstlichem Hintergrundgeräusch, das anstelle von reiner Stille verwendet wird, um Lücken in einer Übertragung zu füllen. Dies hilft, einen abrupten Effekt zu vermeiden, der auftreten kann, wenn Sprachaktivierung und ähnliche Funktionen dazu führen, dass ein Stream vorübergehend das Senden von Daten stoppt – eine Fähigkeit, die als Diskontinuierliche Übertragung (DTX) bekannt ist. In RFC 3389 wird eine Methode bereitgestellt, um eine geeignete Füllung während der Stille anzubieten.

Komfortgeräusch wird mit G.711 verwendet und kann potenziell auch mit anderen Codecs verwendet werden, die keine integrierte CN-Funktion haben. Opus beispielsweise hat eine eigene CN-Fähigkeit; daher wird die Verwendung von RFC 3389 CN mit dem Opus-Codec nicht empfohlen.

Ein Audio-Sender ist niemals verpflichtet, diskontinuierliche Übertragung oder Komfortgeräusch zu verwenden.

Opus

Das Opus-Format, definiert durch RFC 6716 ist das primäre Format für Audio in WebRTC. Das RTP-Nutzlastformat für Opus ist in RFC 7587 zu finden. Sie finden weitere allgemeine Informationen über Opus und seine Fähigkeiten sowie darüber, wie andere APIs Opus unterstützen können, in dem entsprechenden Abschnitt unseres Leitfadens für Audio-Codecs, die im Web verwendet werden.

Sowohl der Sprach- als auch der allgemeine Audiomodus sollten unterstützt werden. Die Skalierbarkeit und Flexibilität von Opus sind nützlich, wenn es um Audio geht, das unterschiedliche Komplexitätsgrade aufweisen kann. Die Unterstützung von In-Band-Stereosignalen ermöglicht die Unterstützung von Stereo, ohne den Demultiplexing-Prozess zu verkomplizieren.

Der gesamte von Opus unterstützte Bitratenbereich (6 kbps bis 510 kbps) wird in WebRTC unterstützt, wobei die Bitrate dynamisch geändert werden kann. Höhere Bitraten verbessern typischerweise die Qualität.

Bitratenempfehlungen

Bei einer Rahmenlänge von 20 Millisekunden zeigt die folgende Tabelle die empfohlenen Bitraten für verschiedene Medienformen.

Die Bitrate kann jederzeit angepasst werden. Um Netzwerkkonflikte zu vermeiden, sollte die durchschnittliche Audiobitrate die verfügbare Netzwerkbandbreite nicht überschreiten (abzüglich jeglicher anderer bekannter oder erwarteter zusätzlicher Bandbreitenanforderungen).

G.711

G.711 definiert das Format für Puls-Code-Modulation (PCM) Audio als eine Serie von 8-Bit-Integer-Samples, die bei einer Abtastrate von 8.000 Hz genommen werden, was zu einer Bitrate von 64 kbps führt. Sowohl µ-law als auch A-law Encodings sind erlaubt.

G.711 ist von der ITU definiert und sein Nutzlastformat ist in RFC 3551, Abschnitt 4.5.14 definiert.

WebRTC erfordert, dass G.711 8-Bit-Samples bei der standardmäßigen 64 kbps-Rate verwendet, obwohl G.711 einige andere Variationen unterstützt. Weder G.711.0 (verlustfreie Kompression), G.711.1 (Breitbandfähigkeit) noch irgendeine andere Erweiterung des G.711-Standards sind durch WebRTC vorgeschrieben.

Aufgrund seiner niedrigen Abtastrate und der Samplegröße wird die Audioqualität von G.711 nach modernen Maßstäben allgemein als schlecht angesehen, obwohl es ungefähr dem entspricht, wie sich ein Festnetztelefon anhört. Es wird im Allgemeinen als kleinster gemeinsamer Nenner verwendet, um sicherzustellen, dass Browser eine Audioverbindung herstellen können, ungeachtet von Plattformen und Browsern, oder im Allgemeinen als Fallback-Option.

Spezifizierung und Konfiguration von Codecs

Abrufen der unterstützten Codecs

Da ein bestimmter Browser und eine Plattform möglicherweise eine unterschiedliche Verfügbarkeit unter den potenziellen Codecs aufweisen und möglicherweise mehrere Profile oder Ebenen für einen bestimmten Codec unterstützen, besteht der erste Schritt bei der Konfiguration von Codecs für eine RTCPeerConnection darin, die Liste der verfügbaren Codecs zu erhalten. Dazu müssen Sie zuerst eine Verbindung herstellen, auf der Sie die Liste erhalten können.

Es gibt einige Möglichkeiten, dies zu tun. Der effizienteste Weg ist die Verwendung der statischen Methode RTCRtpSender.getCapabilities() (oder der äquivalenten RTCRtpReceiver.getCapabilities() für einen Empfänger), bei der der Medientyp als Eingabeparameter spezifiziert wird. Um beispielsweise die unterstützten Codecs für Video zu ermitteln, können Sie dies tun:

codecList = RTCRtpSender.getCapabilities("video").codecs;

Jetzt ist codecList ein Array von codec-Objekten, die jeweils eine Codec-Konfiguration beschreiben. Auch in der Liste werden Einträge für Retransmission (RTX), redundante Kodierung (RED) und Vorwärtsfehlerkorrektur (FEC) vorhanden sein.

Wenn sich die Verbindung im Prozess des Startens befindet, können Sie das icegatheringstatechange-Ereignis verwenden, um auf den Abschluss der ICE-Kandidatensammlung zu achten und dann die Liste abzurufen.

let codecList = null;

peerConnection.addEventListener("icegatheringstatechange", (event) => {
  if (peerConnection.iceGatheringState === "complete") {
    const senders = peerConnection.getSenders();

    senders.forEach((sender) => {
      if (sender.track.kind === "video") {
        codecList = sender.getParameters().codecs;
      }
    });
  }

  codecList = null;
});

Der Ereignishandler für icegatheringstatechange wird etabliert; darin überprüfen wir, ob der ICE-Sammlungsstatus complete ist, was darauf hinweist, dass keine weiteren Kandidaten gesammelt werden. Die Methode RTCPeerConnection.getSenders() wird aufgerufen, um eine Liste aller RTCRtpSender-Objekte zu erhalten, die von der Verbindung verwendet werden.

Mit dieser Liste in der Hand gehen wir die Liste der Sender durch und suchen nach dem ersten, dessen MediaStreamTrack angibt, dass sein kind video ist, was darauf hinweist, dass die Track-Daten Videomedien sind. Wir rufen dann die getParameters()-Methode dieses Senders auf und setzen codecList auf die codecs-Eigenschaft im zurückgegebenen Objekt und kehren dann zum Aufrufer zurück.

Wenn kein Videotrack gefunden wird, setzen wir codecList auf null.

Am Ende ist codecList entweder null, was darauf hinweist, dass keine Videotracks gefunden wurden, oder es ist ein Array von RTCCodecStats-Objekten, die jeweils eine zulässige Codec-Konfiguration beschreiben. Von besonderer Bedeutung in diesen Objekten ist die payloadType-Eigenschaft, die ein Ein-Byte-Wert ist, der die beschriebene Konfiguration eindeutig identifiziert.

Anpassung der Codecliste

Sobald Sie eine Liste der verfügbaren Codecs haben, können Sie diese ändern und dann die überarbeitete Liste an RTCRtpTransceiver.setCodecPreferences() senden, um die Präferenzreihenfolge der Codecs zu ändern. Dies ändert die Reihenfolge der Präferenz der Codecs und ermöglicht es Ihnen, WebRTC anzuweisen, einen anderen Codec anderen vorzuziehen.

function changeVideoCodec(mimeType) {
  const transceivers = peerConnection.getTransceivers();

  transceivers.forEach((transceiver) => {
    const kind = transceiver.sender.track.kind;
    let sendCodecs = RTCRtpSender.getCapabilities(kind).codecs;
    let recvCodecs = RTCRtpReceiver.getCapabilities(kind).codecs;

    if (kind === "video") {
      sendCodecs = preferCodec(sendCodecs, mimeType);
      recvCodecs = preferCodec(recvCodecs, mimeType);
      transceiver.setCodecPreferences([...sendCodecs, ...recvCodecs]);
    }
  });

  // Manually trigger a new negotiation (setCodecPreferences() does not automatically do so).
  peerConnection.onnegotiationneeded();
}

In diesem Beispiel nimmt die Funktion changeVideoCodec() als Eingabe den MIME-Typ des gewünschten Codecs an. Der Code beginnt mit dem Abrufen einer Liste aller RTCRtpTransceiver des RTCPeerConnection.

Dann erhalten wir für jeden Transceiver die Art der Medien, die durch den Transceiver vom RTCRtpSender's Track's kind repräsentiert werden. Wir erhalten auch die Listen aller Codecs, die für das Senden und Empfangen von Videos vom Browser unterstützt werden, durch die Nutzung der getCapabilities()-statischen Methode sowohl des RTCRtpSender als auch des RTCRtpReceiver.

Wenn es sich bei den Medien um Video handelt, rufen wir eine Methode namens preferCodec() sowohl für die Sender- als auch die Empfängerliste der Codecs auf; diese Methode ordnet die Codecliste in der gewünschten Weise um (siehe unten).

Schließlich rufen wir die RTCRtpTransceiver's setCodecPreferences()-Methode auf, um anzugeben, dass die angegebenen Send- und Empfangscodecs in der neu umgeordneten Reihenfolge zulässig sind.

Das wird für jeden Transceiver auf der RTCPeerConnection durchgeführt; sobald alle Transceiver aktualisiert wurden, rufen wir den onnegotiationneeded-Ereignishandler auf, der ein neues Angebot erstellt, die lokale Beschreibung aktualisiert, das Angebot an den entfernten Peer sendet und so weiter, wodurch die Neuverhandlung der Verbindung ausgelöst wird.

Die preferCodec()-Funktion, die vom oben gezeigten Code aufgerufen wird, sieht so aus, um einen bestimmten Codec an die Spitze der Liste zu verschieben (um bei der Verhandlung priorisiert zu werden):

function preferCodec(codecs, mimeType) {
  let otherCodecs = [];
  let sortedCodecs = [];

  codecs.forEach((codec) => {
    if (codec.mimeType.toLowerCase() === mimeType.toLowerCase()) {
      sortedCodecs.push(codec);
    } else {
      otherCodecs.push(codec);
    }
  });

  return sortedCodecs.concat(otherCodecs);
}

Dieser Code teilt einfach die Codecliste in zwei Arrays: eines, das Codecs enthält, deren MIME-Typ mit dem angegebenen mimeType-Parameter übereinstimmt, und das andere mit allen anderen Codecs. Sobald die Liste aufgeteilt wurde, werden sie wieder zusammengefügt, wobei die Einträge, die mit dem angegebenen mimeType übereinstimmen, zuerst kommen, gefolgt von allen anderen Codecs. Die umgeordnete Liste wird dann an den Aufrufer zurückgegeben.

Standard-Codecs

Sofern nicht anders angegeben, werden die von jeder Browser-Implementierung von WebRTC angeforderten Standard- oder, genauer gesagt, bevorzugten Codecs in der folgenden Tabelle aufgeführt.

Den richtigen Codec wählen

Bevor Sie sich für einen Codec entscheiden, der nicht einer der Pflichtcodecs ist (VP8 oder AVC für Video und Opus oder PCM für Audio), sollten Sie die potenziellen Nachteile ernsthaft in Betracht ziehen: Insbesondere können nur diese Codecs allgemein angenommen werden, auf fast allen Geräten verfügbar zu sein, die WebRTC unterstützen.

Wenn Sie sich dafür entscheiden, einen anderen als die Pflichtcodecs zu bevorzugen, sollten Sie zumindest den Rückgriff auf einen der Pflichtcodecs ermöglichen, falls keine Unterstützung für den bevorzugten Codec vorhanden ist.

Audio

Im Allgemeinen sollten Sie, wenn es verfügbar ist und das Audio, das Sie senden möchten, eine Abtastrate von mehr als 8 kHz aufweist, ernsthaft in Betracht ziehen, Opus als Ihren primären Codec zu verwenden. Für sprachbasierte Verbindungen in einer eingeschränkten Umgebung kann die Verwendung von G.711 bei einer 8 kHz-Abtastrate ein akzeptables Erlebnis für Gespräche bieten, aber typischerweise wird G.711 als Fallback-Option verwendet, da es andere Optionen gibt, die effizienter sind und besser klingen, wie Opus in seinem Schmalbandmodus.

Video

Es gibt eine Reihe von Faktoren, die berücksichtigt werden müssen, wenn es darum geht, einen Video-Codec (oder eine Reihe von Codecs) zu unterstützen.

Lizenzbedingungen

Bevor Sie einen Videocodec auswählen, sollten Sie sich über eventuell vorhandene Lizenzanforderungen rund um den von Ihnen gewählten Codec im Klaren sein. Sie finden Informationen über mögliche Lizenzierungsbedenken in unserem Haupt-Leitfaden zu Videocodecs, die im Web verwendet werden. Von den beiden Pflichtcodecs für Video – VP8 und AVC/H.264 – ist nur VP8 völlig frei von Lizenzierungsanforderungen. Wenn Sie AVC auswählen, sollten Sie sich über mögliche Gebühren im Klaren sein, die Sie möglicherweise zahlen müssen; dennoch haben die Patentinhaber im Allgemeinen gesagt, dass die meisten typischen Website-Entwickler sich keine Sorgen um die Zahlung von Lizenzgebühren machen sollten, die in der Regel eher auf die Entwickler der Kodierungs- und Dekodierungssoftware abzielen.

Energiebedarf und Akkulaufzeit

Ein weiterer zu berücksichtigender Faktor, insbesondere auf mobilen Plattformen, ist die Auswirkung eines Codecs auf die Akkulaufzeit. Wenn ein Codec auf einer bestimmten Plattform in Hardware verarbeitet wird, ermöglicht dieser Codec wahrscheinlich eine viel bessere Akkulaufzeit und weniger Wärmeentwicklung.

Beispielsweise führte Safari für iOS und iPadOS WebRTC mit AVC als einzigem unterstütztem Videocodec ein. AVC hat den Vorteil, dass es auf iOS und iPadOS in Hardware kodiert und dekodiert werden kann. Safari 12.1 führte innerhalb von IRC Unterstützung für VP8 ein, was die Interoperabilität verbessert, jedoch auf Kosten – VP8 hat auf iOS-Geräten keine Hardware-Unterstützung, daher verursacht seine Verwendung eine erhöhte Prozessorbelastung und verringerte Akkulaufzeit.

Leistung

Glücklicherweise sind VP8 und AVC aus Endbenutzersicht ähnlich leistungsfähig und für den Einsatz in Videokonferenzen und anderen WebRTC-Lösungen gleich gut geeignet. Die endgültige Entscheidung liegt bei Ihnen. Welchen auch immer Sie wählen, stellen Sie sicher, dass Sie die in diesem Artikel bereitgestellten Informationen zu eventuell erforderlichen Konfigurationsproblemen beachten, mit denen Sie für diesen Codec konfrontiert sein könnten.

Beachten Sie, dass die Auswahl eines Codecs, der nicht auf der Liste der Pflichtcodecs steht, wahrscheinlich das Risiko birgt, einen Codec auszuwählen, der von einem Browser, den Ihre Benutzer bevorzugen könnten, nicht unterstützt wird. Sehen Sie sich den Artikel Probleme mit der Medienunterstützung in Webinhalten behandeln an, um zu erfahren, wie Sie Unterstützung für Ihre bevorzugten Codecs anbieten können, während Sie dennoch auf Browser zurückgreifen können, die diesen Codec nicht implementieren.

Sicherheitsimplikationen

Es gibt interessante potenzielle Sicherheitsprobleme, die bei der Auswahl und Konfiguration von Codecs auftreten können. WebRTC-Video ist durch Datagram Transport Layer Security (DTLS) geschützt, aber es ist theoretisch möglich, dass eine motivierte Partei die Menge an Veränderung, die von Frame zu Frame auftritt, von variablen Bitraten (VBR) Codecs ableiten kann, indem sie die Bitrate des Streams und wie sie sich über die Zeit verändert, überwacht. Dies könnte potenziell einem Angreifer ermöglichen, etwas über den Inhalt des Streams abzuleiten, angesichts der Auf- und Abbewegungen der Bitrate.

Weitere Informationen zu Sicherheitsüberlegungen beim Einsatz von AVC in WebRTC finden Sie in RFC 6184, Abschnitt 9: RTP Payload Format for H.264 Video: Security Considerations.

Medienformate für RTP-Nutzlast

Es kann nützlich sein, auf die IANA-Liste der RTP-Nutzlastformats-Medientypen zu verweisen; dies ist eine vollständige Liste der MIME-Medientypen, die für die potenzielle Verwendung in RTP-Streams, wie sie in WebRTC verwendet werden, definiert sind. Die meisten davon werden in WebRTC-Kontexten nicht verwendet, aber die Liste kann dennoch nützlich sein.

Siehe auch RFC 4855, das die Registrierung von Medientypen behandelt.

Siehe auch

• WebRTC API
• Einführung in WebRTC-Protokolle
• WebRTC-Konnektivität
• Leitfaden für Videocodecs, die im Web verwendet werden
• Leitfaden für Audiocodecs, die im Web verwendet werden
• Digitale Videokonzepte
• Digitale Audiokonzepte