Von WebRTC verwendete Codecs

Medien ohne Container

WebRTC verwendet für jeden Track, der zwischen Peers geteilt wird, einzelne MediaStreamTrack-Objekte – ohne Container und sogar ohne einen den Tracks zugeordneten MediaStream. Die WebRTC-Spezifikation schreibt nicht vor, welche Codecs diese Tracks enthalten dürfen. RFC 7742 legt jedoch fest, dass alle WebRTC-kompatiblen Browser für Video VP8 und das Constrained-Baseline-Profil von H.264 unterstützen müssen. Nach RFC 7874 müssen Browser mindestens den Codec Opus sowie die Formate PCMA und PCMU von G.711 unterstützen.

Diese beiden RFCs legen außerdem fest, welche Optionen für die einzelnen Codecs unterstützt werden müssen, und behandeln Funktionen für eine angenehmere Nutzung, etwa die Echounterdrückung. Dieser Leitfaden behandelt die Codecs, die Browser implementieren müssen, sowie weitere Codecs, die einige oder alle Browser für WebRTC unterstützen.

Bei Medien im Web ist Komprimierung immer notwendig. Bei Videokonferenzen ist sie besonders wichtig, damit die Teilnehmer ohne Verzögerungen oder Unterbrechungen kommunizieren können. Außerdem müssen Video und Audio synchron bleiben, damit Bewegungen und begleitende Informationen – beispielsweise Folien oder eine Projektion – gleichzeitig mit dem zugehörigen Ton wiedergegeben werden.

Allgemeine Anforderungen an Codecs

Bevor wir die Fähigkeiten und Anforderungen einzelner Codecs betrachten, sind einige allgemeine Anforderungen zu beachten, die für jede mit WebRTC verwendete Codec-Konfiguration gelten.

Sofern das SDP nicht ausdrücklich etwas anderes signalisiert, muss ein Webbrowser, der einen WebRTC-Videostream empfängt, Video mit mindestens 20 FPS und einer Auflösung von mindestens 320 × 240 Pixeln verarbeiten können. Es wird empfohlen, Video nicht mit einer geringeren Bildrate oder Auflösung zu codieren, da dies im Wesentlichen die Untergrenze dessen ist, was WebRTC üblicherweise verarbeiten können sollte.

SDP bietet eine codecunabhängige Möglichkeit, bevorzugte Videoauflösungen anzugeben (RFC 6236). Dazu wird ein SDP-Attribut a=image-attr gesendet, das die maximal akzeptable Auflösung angibt. Der Sender muss diesen Mechanismus allerdings nicht unterstützen. Sie sollten daher darauf vorbereitet sein, Medien in einer anderen als der angeforderten Auflösung zu empfangen. Über diese Anforderung einer maximalen Auflösung hinaus können einzelne Codecs weitere Möglichkeiten bieten, bestimmte Medienkonfigurationen anzufordern.

Unterstützte Video-Codecs

WebRTC legt eine Grundausstattung an Codecs fest, die alle konformen Browser unterstützen müssen. Manche Browser unterstützen darüber hinaus weitere Codecs.

Die folgende Tabelle zeigt die Video-Codecs, die in jedem vollständig WebRTC-konformen Browser erforderlich sind, die jeweils erforderlichen Profile und die Browser, die diese Anforderungen tatsächlich erfüllen.

Einzelheiten zu WebRTC-spezifischen Aspekten der Codecs finden Sie in den folgenden Unterabschnitten, die über die Codec-Namen verlinkt sind.

Alle Anforderungen an Video-Codecs und -Konfigurationen, die WebRTC unterstützen muss, finden Sie in RFC 7742: WebRTC Video Processing and Codec Requirements. Der RFC behandelt auch weitere Anforderungen rund um Video, darunter Farbräume (sRGB ist der bevorzugte, aber nicht vorgeschriebene Standardfarbraum) sowie Empfehlungen für Webcam-Funktionen wie automatischen Fokus, automatischen Weißabgleich und automatische Belichtungsanpassung.

Neben den obligatorischen Codecs unterstützen manche Browser weitere Codecs. Diese sind in der folgenden Tabelle aufgeführt.

VP8

VP8 wird im allgemeinen Überblick unseres Leitfadens zu Video-Codecs im Web beschrieben. Für das Codieren oder Decodieren eines Video-Tracks in einer WebRTC-Verbindung gelten darüber hinaus einige besondere Anforderungen.

Sofern nichts anderes signalisiert wird, verwendet VP8 quadratische Pixel, also Pixel mit einem Seitenverhältnis von 1:1.

Weitere Hinweise

Das Netzwerk-Payload-Format für die Übertragung von VP8 über RTP, beispielsweise bei der Verwendung von WebRTC, ist in RFC 7741: RTP Payload Format for VP8 Video beschrieben.

AVC / H.264

Alle vollständig konformen WebRTC-Implementierungen müssen das Constrained-Baseline-Profil (CB) von AVC unterstützen. CB ist eine Teilmenge des Main-Profils und wurde speziell für Anwendungen mit geringer Komplexität und niedriger Latenz entwickelt, beispielsweise mobile Videoanwendungen und Videokonferenzen. Es eignet sich auch für Plattformen mit weniger leistungsfähiger Videoverarbeitung.

Einen Überblick über AVC und seine Funktionen finden Sie im allgemeinen Leitfaden zu Video-Codecs.

HEVC / H.265

Einen Überblick über HEVC und seine Funktionen finden Sie im allgemeinen Leitfaden zu Video-Codecs.

Besondere Anforderungen an die Unterstützung von Parametern

AVC bietet zahlreiche Parameter zur Steuerung optionaler Werte. Damit die Freigabe von WebRTC-Medien über verschiedene Plattformen und Browser hinweg zuverlässiger funktioniert, müssen WebRTC-Endpunkte, die AVC unterstützen, bestimmte Parameter auf festgelegte Weise behandeln. Manchmal muss ein Parameter unterstützt werden – oder darf gerade nicht unterstützt werden. In anderen Fällen ist ein bestimmter Wert vorgeschrieben oder eine bestimmte Menge von Werten zulässig. Einige Anforderungen sind noch komplexer.

Nützliche, aber nicht erforderliche Parameter

WebRTC-Endpunkte müssen diese Parameter nicht unterstützen; ihre Verwendung ist ebenfalls nicht erforderlich. Sie können die Benutzererfahrung auf verschiedene Weise verbessern, müssen aber nicht verwendet werden. Einige davon sind tatsächlich recht kompliziert in der Anwendung.

max-br

Falls der Parameter angegeben und von der Software unterstützt wird, legt max-br die maximale Video-Bitrate fest, in Einheiten von 1.000 bps für VCL und 1.200 bps für NAL. Einzelheiten finden Sie auf Seite 47 von RFC 6184.

max-cpb

Falls der Parameter angegeben und von der Software unterstützt wird, legt max-cpb die maximale Größe des Puffers für codierte Bilder fest. Dieser Parameter ist recht komplex; die Größe seiner Einheit kann variieren. Einzelheiten finden Sie auf Seite 45 von RFC 6184.

max-dpb

Falls der Parameter angegeben und unterstützt wird, bezeichnet max-dpb die maximale Größe des Puffers für decodierte Bilder, angegeben in Einheiten von 8/3 Makroblöcken. Weitere Einzelheiten finden Sie auf Seite 46 von RFC 6184.

max-fs

Falls der Parameter angegeben und von der Software unterstützt wird, legt max-fs die maximale Größe eines einzelnen Videoframes als Anzahl von Makroblöcken fest.

max-mbps

Falls der Parameter angegeben und von der Software unterstützt wird, gibt dieser ganzzahlige Wert die maximale Rate an, mit der Makroblöcke pro Sekunde verarbeitet werden sollen (in Makroblöcken pro Sekunde).

max-smbps

Falls der Parameter angegeben und von der Software unterstützt wird, legt dieser ganzzahlige Wert die maximale Verarbeitungsrate statischer Makroblöcke pro Sekunde fest. Dabei wird hypothetisch angenommen, dass alle Makroblöcke statisch sind.

Parameter mit besonderen Anforderungen

Diese Parameter können erforderlich sein oder nicht; bei ihrer Verwendung gelten jedoch besondere Anforderungen.

packetization-mode

Alle Endpunkte müssen Modus 1 (nicht verschachtelter Modus) unterstützen. Die Unterstützung anderer Paketierungsmodi ist optional; auch der Parameter selbst muss nicht angegeben werden.

sprop-parameter-sets

Sequenz- und Bildinformationen für AVC können entweder in-band oder out-of-band übertragen werden. Wird AVC mit WebRTC verwendet, müssen diese Informationen in-band signalisiert werden. Der Parameter sprop-parameter-sets darf daher nicht im SDP enthalten sein.

Parameter, die angegeben werden müssen

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

profile-level-id

Alle WebRTC-Implementierungen müssen diesen Parameter in ihrem SDP angeben und auswerten, um das vom Codec verwendete Unterprofil zu identifizieren. Welcher konkrete Wert gesetzt wird, ist nicht festgelegt; entscheidend ist, dass der Parameter verwendet wird. Das ist bemerkenswert, weil profile-level-id in RFC 6184 („RTP Payload Format for H.264 Video“) vollständig optional ist.

Weitere Anforderungen

Für den Wechsel zwischen Hoch- und Querformat stehen zwei Methoden zur Verfügung. Die erste ist die Header-Erweiterung für die Videoausrichtung (CVO) im RTP-Protokoll. Falls die Unterstützung dafür nicht im SDP signalisiert wird, wird Browsern empfohlen, Display-Orientation-SEI-Nachrichten zu unterstützen; vorgeschrieben ist dies jedoch nicht.

Sofern nichts anderes signalisiert wird, beträgt das Pixelseitenverhältnis 1:1. Die Pixel sind also quadratisch.

Weitere Hinweise

Das für AVC in WebRTC verwendete Payload-Format wird in RFC 6184: RTP Payload Format for H.264 Video beschrieben. AVC-Implementierungen für WebRTC müssen die speziellen SEI-Nachrichten „filler payload“ und „full frame freeze“ unterstützen. Diese ermöglichen einen nahtlosen Wechsel zwischen mehreren Eingabestreams.

AV1

AV1 wird im allgemeinen Überblick unseres Leitfadens zu Video-Codecs im Web beschrieben.

Dependency-Descriptor-RTP-Header-Erweiterung

WebRTC unterstützt zwei wesentliche Technologien, um Video effizient an Empfänger mit unterschiedlichen Fähigkeiten und Netzwerkbedingungen zu übertragen.

AV1 verwendet die Dependency-Descriptor-(DD-)RTP-Header-Erweiterung, um Informationen über Abhängigkeiten zwischen Frames bereitzustellen. Diese werden für Videokonferenzen mit mehreren Teilnehmern benötigt.

Unterstützte Audio-Codecs

Die folgende Tabelle zeigt die Audio-Codecs, die nach RFC 7874 von allen WebRTC-kompatiblen Browsern unterstützt werden müssen.

Weitere Einzelheiten zu WebRTC-spezifischen Aspekten der aufgeführten Codecs finden Sie in den folgenden Abschnitten.

RFC 7874 enthält nicht nur eine Liste der Audio-Codecs, die ein WebRTC-konformer Browser unterstützen muss. Er formuliert auch Empfehlungen und Anforderungen für spezielle Audiofunktionen wie Echounterdrückung, Rauschunterdrückung und Pegelanpassung.

Neben den obligatorischen Audio-Codecs unterstützen manche Browser weitere Codecs. Diese sind in der folgenden Tabelle aufgeführt.

Der Internet Low Bitrate Codec (iLBC) ist ein Open-Source-Schmalbandcodec, der von Global IP Solutions und später Google speziell für das Streaming von Sprache entwickelt wurde. Google und einige andere Browserentwickler haben ihn für WebRTC übernommen.

Der Internet Speech Audio Codec (iSAC) ist ein weiterer Codec, der von Global IP Solutions entwickelt wurde. Er gehört inzwischen Google, das seinen Quellcode veröffentlicht hat. Er wird von Google Talk, QQ und anderen Instant-Messaging-Clients verwendet und wurde speziell für Sprachübertragungen innerhalb eines RTP-Streams entwickelt.

Comfort Noise (CN) ist künstliches Hintergrundrauschen, das Übertragungslücken statt völliger Stille ausfüllt. Dadurch lässt sich ein störender Effekt vermeiden, der auftreten kann, wenn Sprachaktivierung oder ähnliche Funktionen bewirken, dass ein Stream vorübergehend keine Daten sendet. Diese Fähigkeit wird als Discontinuous Transmission (DTX) bezeichnet. RFC 3389 beschreibt eine Methode, um für Sprechpausen ein geeignetes Füllsignal bereitzustellen.

Comfort Noise wird mit G.711 verwendet und kann möglicherweise auch mit anderen Codecs ohne integrierte CN-Funktion eingesetzt werden. Opus verfügt beispielsweise über eine eigene CN-Funktion; die Verwendung von CN nach RFC 3389 mit dem Opus-Codec wird daher nicht empfohlen.

Ein Audio-Sender muss weder Discontinuous Transmission noch Comfort Noise verwenden.

Opus

Das in RFC 6716 definierte Opus-Format ist das wichtigste Audioformat für WebRTC. Das RTP-Payload-Format für Opus ist in RFC 7587 beschrieben. Allgemeinere Informationen über Opus, seine Fähigkeiten und seine Unterstützung durch andere APIs finden Sie im entsprechenden Abschnitt unseres Leitfadens zu Audio-Codecs im Web.

Sowohl der Sprachmodus als auch der allgemeine Audiomodus sollten unterstützt werden. Die Skalierbarkeit und Flexibilität von Opus sind besonders bei Audio mit unterschiedlicher Komplexität nützlich. Da Opus Stereo-Signale in-band unterstützt, lässt sich Stereo ohne zusätzlichen Aufwand beim Demultiplexing verwenden.

WebRTC unterstützt den gesamten von Opus abgedeckten Bitratenbereich von 6 kbps bis 510 kbps. Die Bitrate kann dynamisch geändert werden. Höhere Bitraten verbessern in der Regel die Qualität.

Empfehlungen zur Bitrate

Bei einer Frame-Dauer von 20 Millisekunden gelten für verschiedene Medienarten die folgenden empfohlenen Bitraten.

Die Bitrate kann jederzeit angepasst werden. Um eine Überlastung des Netzwerks zu vermeiden, sollte die durchschnittliche Audio-Bitrate die verfügbare Netzwerkbandbreite nicht überschreiten, abzüglich des bekannten oder voraussichtlichen zusätzlichen Bandbreitenbedarfs.

G.711

G.711 definiert das Format für Audio mit Pulse Code Modulation (PCM) als Folge von 8-Bit-Integer-Samples mit einer Abtastrate von 8.000 Hz. Daraus ergibt sich eine Bitrate von 64 kbps. Sowohl die µ-law- als auch die A-law-Codierung sind zulässig.

G.711 ist von der ITU definiert; sein Payload-Format ist in RFC 3551, Abschnitt 4.5.14 festgelegt.

WebRTC verlangt für G.711 8-Bit-Samples mit der standardmäßigen Bitrate von 64 kbps, obwohl G.711 auch andere Varianten unterstützt. Weder G.711.0 (verlustfreie Komprimierung) noch G.711.1 (Breitbandfähigkeit) oder andere Erweiterungen des G.711-Standards sind für WebRTC vorgeschrieben.

Aufgrund der niedrigen Abtastrate und Sample-Größe gilt die Audioqualität von G.711 nach heutigen Maßstäben allgemein als schlecht, auch wenn sie ungefähr der eines Festnetztelefons entspricht. G.711 dient meist als kleinster gemeinsamer Nenner, um unabhängig von Plattform und Browser eine Audioverbindung zu ermöglichen, oder allgemein als Ausweichoption.

Codecs angeben und konfigurieren

Unterstützte Codecs abrufen

Welche Codecs verfügbar sind und welche Profile oder Levels eines Codecs unterstützt werden, kann je nach Browser und Plattform variieren. Wenn Sie die Codecs für eine RTCPeerConnection konfigurieren, sollten Sie daher zuerst die Liste der verfügbaren Codecs abrufen. Dazu müssen Sie zunächst eine Verbindung herstellen, für die Sie die Liste abrufen können.

Hierfür gibt es mehrere Möglichkeiten. Am effizientesten ist die statische Methode RTCRtpSender.getCapabilities() beziehungsweise für einen Empfänger RTCRtpReceiver.getCapabilities(). Geben Sie den Medientyp als Eingabeparameter an. Um beispielsweise die unterstützten Video-Codecs zu ermitteln, gehen Sie so vor:

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

codecList ist nun ein Array von codec-Objekten, die jeweils eine Codec-Konfiguration beschreiben. Die Liste enthält außerdem Einträge für Retransmission (RTX), Redundant Coding (RED) und Forward Error Correction (FEC).

Wenn die Verbindung gerade aufgebaut wird, können Sie mit dem Ereignis icegatheringstatechange verfolgen, wann das Sammeln der ICE-Kandidaten abgeschlossen ist, und anschließend die Liste abrufen.

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;
});

Zunächst wird der Ereignishandler für icegatheringstatechange eingerichtet. Darin prüfen wir, ob der ICE-Sammelstatus complete lautet, also keine weiteren Kandidaten mehr gesammelt werden. Mit RTCPeerConnection.getSenders() rufen wir dann eine Liste aller von der Verbindung verwendeten RTCRtpSender-Objekte ab.

Anschließend durchsuchen wir die Senderliste nach dem ersten Sender, dessen MediaStreamTrack für kind den Wert video angibt. Dies zeigt an, dass der Track Videodaten enthält. Dann rufen wir die Methode getParameters() dieses Senders auf, weisen die Eigenschaft codecs des zurückgegebenen Objekts codecList zu und kehren zum Aufrufer zurück.

Wird kein Video-Track gefunden, setzen wir codecList auf null.

Nach der Rückkehr ist codecList somit entweder null, wenn kein Video-Track gefunden wurde, oder ein Array von RTCCodecStats-Objekten, die jeweils eine zulässige Codec-Konfiguration beschreiben. Besonders wichtig ist darin die Eigenschaft payloadType: Ihr Wert ist ein Byte groß und identifiziert die beschriebene Konfiguration eindeutig.

Codec-Liste anpassen

Sobald Sie die Liste der verfügbaren Codecs haben, können Sie sie ändern und die neue Liste an RTCRtpTransceiver.setCodecPreferences() übergeben. Damit ändern Sie die Reihenfolge der Codec-Präferenzen und können WebRTC anweisen, einen anderen Codec gegenüber den übrigen zu bevorzugen.

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 erwartet die Funktion changeVideoCodec() den MIME-Typ des gewünschten Codecs als Eingabe. Der Code ruft zunächst eine Liste aller Transceiver der RTCPeerConnection ab.

Anschließend ermitteln wir für jeden Transceiver anhand von kind des Tracks seines RTCRtpSender, welchen Medientyp er verarbeitet. Außerdem rufen wir mit der statischen Methode getCapabilities() von RTCRtpSender und RTCRtpReceiver die Listen aller Codecs ab, die der Browser zum Senden beziehungsweise Empfangen von Video unterstützt.

Handelt es sich um Video, rufen wir preferCodec() sowohl für die Codec-Liste des Senders als auch für die des Empfängers auf. Diese Methode ordnet die Listen wie gewünscht neu an (siehe unten).

Abschließend rufen wir für den RTCRtpTransceiver die Methode setCodecPreferences() auf. Damit legen wir die zulässigen Sende- und Empfangs-Codecs in der neu festgelegten Reihenfolge fest.

Das geschieht für jeden Transceiver der RTCPeerConnection. Sobald alle Transceiver aktualisiert sind, rufen wir den Ereignishandler onnegotiationneeded auf. Er erstellt ein neues Angebot, aktualisiert die lokale Beschreibung, sendet das Angebot an den entfernten Peer und löst so eine erneute Aushandlung der Verbindung aus.

Die vom obigen Code aufgerufene Funktion preferCodec() sieht wie folgt aus. Sie verschiebt einen angegebenen Codec an den Anfang der Liste, damit er bei der Aushandlung bevorzugt wird:

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 die Codec-Liste in zwei Arrays auf: Das erste enthält Codecs, deren MIME-Typ dem Parameter mimeType entspricht, das zweite alle übrigen Codecs. Anschließend werden die Arrays wieder zusammengefügt, wobei die Einträge mit passendem mimeType vor allen anderen stehen. Die neu geordnete Liste wird an den Aufrufer zurückgegeben.

Standard-Codecs

Sofern nichts anderes angegeben ist, zeigt die folgende Tabelle die Codecs, die die WebRTC-Implementierung des jeweiligen Browsers standardmäßig anfordert – genauer gesagt: bevorzugt.

Den richtigen Codec auswählen

Bevor Sie einen Codec wählen, der nicht zu den obligatorischen Codecs gehört – VP8 oder AVC für Video sowie Opus oder PCM für Audio –, sollten Sie mögliche Nachteile sorgfältig abwägen. Insbesondere können Sie im Allgemeinen nur bei diesen Codecs davon ausgehen, dass sie auf praktisch allen WebRTC-fähigen Geräten verfügbar sind.

Wenn Sie einen anderen Codec bevorzugen, sollten Sie zumindest den Rückgriff auf einen der obligatorischen Codecs ermöglichen, falls der gewünschte Codec nicht unterstützt wird.

Audio

Wenn Opus verfügbar ist und das zu sendende Audio eine Abtastrate von mehr als 8 kHz hat, sollten Sie Opus in der Regel als primären Codec in Betracht ziehen. Bei reinen Sprachverbindungen unter eingeschränkten Bedingungen kann G.711 mit einer Abtastrate von 8 kHz eine für Gespräche akzeptable Qualität liefern. Meist werden Sie G.711 jedoch als Ausweichoption verwenden, da andere Möglichkeiten wie Opus im Schmalbandmodus effizienter sind und besser klingen.

Video

Bei der Entscheidung, welchen Video-Codec oder welche Kombination von Codecs Sie unterstützen möchten, spielen mehrere Faktoren eine Rolle.

Lizenzbedingungen

Informieren Sie sich vor der Auswahl eines Video-Codecs über die damit verbundenen Lizenzanforderungen. Hinweise auf mögliche Lizenzfragen finden Sie in unserem allgemeinen Leitfaden zu Video-Codecs im Web. Von den beiden obligatorischen Video-Codecs – VP8 und AVC/H.264 – ist nur VP8 vollständig frei von Lizenzanforderungen. Wenn Sie AVC wählen, sollten Sie sich über mögliche Gebühren informieren. Die Patentinhaber haben allerdings im Allgemeinen erklärt, dass sich die meisten typischen Website-Entwickler keine Sorgen um Lizenzgebühren machen müssen. Diese betreffen üblicherweise eher die Entwickler von Software zum Codieren und Decodieren.

Energiebedarf und Akkulaufzeit

Ein weiterer Faktor ist – insbesondere auf Mobilgeräten – der Einfluss eines Codecs auf die Akkulaufzeit. Wenn ein Codec auf einer Plattform hardwareseitig verarbeitet wird, ermöglicht er wahrscheinlich eine deutlich längere Akkulaufzeit und eine geringere Wärmeentwicklung.

Safari für iOS und iPadOS führte WebRTC beispielsweise mit AVC als einzigem unterstützten Video-Codec ein. AVC hat auf iOS und iPadOS den Vorteil, dass er hardwareseitig codiert und decodiert werden kann. Safari 12.1 führte die Unterstützung von VP8 in IRC ein. Das verbessert die Interoperabilität, hat aber einen Preis: VP8 wird auf iOS-Geräten nicht hardwareseitig unterstützt. Seine Verwendung belastet daher den Prozessor stärker und verkürzt die Akkulaufzeit.

Leistung

Glücklicherweise bieten VP8 und AVC aus Sicht der Endbenutzer eine ähnliche Leistung und eignen sich gleichermaßen für Videokonferenzen und andere WebRTC-Anwendungen. Die endgültige Entscheidung liegt bei Ihnen. Für welchen Codec Sie sich auch entscheiden: Lesen Sie die Informationen in diesem Artikel zu möglichen Besonderheiten bei seiner Konfiguration.

Bedenken Sie, dass ein Codec außerhalb der Liste der obligatorischen Codecs möglicherweise von einem Browser nicht unterstützt wird, den Ihre Benutzer bevorzugen. Im Artikel Umgang mit Problemen bei der Medienunterstützung in Webinhalten erfahren Sie, wie Sie Ihre bevorzugten Codecs unterstützen und zugleich eine Ausweichmöglichkeit für Browser anbieten, die diese Codecs nicht implementieren.

Sicherheitsaspekte

Bei der Auswahl und Konfiguration von Codecs können Sicherheitsfragen auftreten. WebRTC-Video wird durch Datagram Transport Layer Security (DTLS) geschützt. Theoretisch könnte jedoch eine entsprechend motivierte Person bei Codecs mit variabler Bitrate (VBR) aus der Bitrate des Streams und ihren Veränderungen im Zeitverlauf ableiten, wie stark sich aufeinanderfolgende Frames unterscheiden. Aus den Schwankungen der Bitrate ließen sich unter Umständen Rückschlüsse auf den Inhalt des Streams ziehen.

Weitere Informationen zu Sicherheitsaspekten bei der Verwendung von AVC in WebRTC finden Sie in RFC 6184, Abschnitt 9: RTP Payload Format for H.264 Video: Security Considerations.

Medientypen für RTP-Payload-Formate

Die Liste der IANA mit Medientypen für RTP-Payload-Formate kann hilfreich sein. Sie enthält alle MIME-Medientypen, die für eine potenzielle Verwendung in RTP-Streams wie denen von WebRTC definiert sind. Die meisten davon werden im WebRTC-Kontext nicht verwendet; die Liste kann dennoch nützlich sein.

Siehe auch RFC 4855, der das Register der Medientypen behandelt.

Siehe auch

• WebRTC API
• Einführung in WebRTC-Protokolle
• WebRTC-Konnektivität
• Leitfaden zu Video-Codecs im Web
• Leitfaden zu Audio-Codecs im Web
• Grundlagen digitaler Videos
• Grundlagen digitaler Audiosignale