Von WebRTC verwendete Codecs

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

Diese beiden RFCs legen auch Optionen fest, die für jeden Codec unterstützt werden müssen, sowie spezifische Benutzerkomfortfunktionen wie Echounterdrückung. Dieser Leitfaden bietet einen Überblick über die Codecs, die Browser implementieren müssen, sowie über andere Codecs, die von einigen oder allen Browsern für WebRTC unterstützt werden.

Während die Komprimierung bei der Arbeit mit Medien im Web immer eine Notwendigkeit ist, ist sie bei Videokonferenzen von besonderer Bedeutung, um sicherzustellen, dass die Teilnehmer ohne Verzögerungen oder Unterbrechungen kommunizieren können. Von sekundärer Bedeutung ist es, Audio und Video synchron zu halten, sodass die Bewegungen und alle zusätzlichen Informationen (wie Folien oder eine Projektion) gleichzeitig mit dem entsprechenden Audio angezeigt werden.

Bevor auf codec-spezifische Fähigkeiten und Anforderungen eingegangen wird, gibt es ein paar allgemeine Anforderungen, die von jedem mit WebRTC verwendeten Codec erfüllt werden müssen.

Sofern im SDP nicht anders angegeben, muss der Webbrowser, der einen WebRTC-Videostream empfängt, in der Lage sein, Video mit mindestens 20 FPS und einer minimalen Auflösung von 320 Pixeln Breite und 240 Pixeln Höhe zu verarbeiten. Es wird empfohlen, das Video mit einer Bildrate und Größe nicht niedriger als diese zu codieren, da dies im Wesentlichen die Untergrenze dessen ist, was WebRTC im Allgemeinen erwartet zu verarbeiten.

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

WebRTC legt eine Grundmenge von Codecs fest, die alle kompatiblen Browser unterstützen müssen. Einige Browser können auch die Verwendung weiterer Codecs zulassen.

Unten sind die Video-Codecs 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 nachfolgenden Abschnitten, indem Sie die Links zu den Namen der einzelnen Codecs folgen.

Vollständige Details, welche Video-Codecs und Konfigurationen WebRTC unterstützen muss, finden Sie in RFC 7742: WebRTC Video Processing and Codec Requirements. Es ist erwähnenswert, dass das RFC eine Vielzahl von video-bezogenen Anforderungen abdeckt, darunter Farbräume (sRGB ist der bevorzugte, aber nicht vorgeschriebene Standardfarbraum), Empfehlungen für Webcam-Verarbeitungsfunktionen (automatischer Fokus, automatischer Weißabgleich, automatisches Lichtniveau) usw.

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

VP8, den wir allgemein beschreiben im Haupt-Leitfaden zu auf dem Web verwendeten Videocodecs, hat einige spezifische Anforderungen, die erfüllt werden müssen, wenn er zur Kodierung oder Dekodierung eines Videotracks in einer WebRTC-Verbindung verwendet wird.

Sofern nicht anders signalisiert, verwendet VP8 quadratische Pixel (d.h. Pixel mit einem Seitenverhältnis von 1:1).

Weitere Hinweise

Das Netzwerk-Payload-Format zur Freigabe von VP8 unter Verwendung von RTP (wie bei der Verwendung von WebRTC) wird in RFC 7741: RTP Payload Format for VP8 Video beschrieben.

Die Unterstützung für das Constrained Baseline (CB)-Profil von AVC ist in allen vollständig konformen WebRTC-Implementierungen erforderlich. CB ist eine Teilmenge des Hauptprofils und speziell für Anwendungen mit niedriger Komplexität und geringer Verzögerung konzipiert, wie z. B. mobile Videos und Videokonferenzen, sowie für Plattformen mit geringerer Leistungsfähigkeit bei der Videobearbeitung.

Unsere Übersicht über AVC und seine Funktionen finden Sie im Hauptleitfaden für Videocodecs.

Unterstützungsanforderungen für spezielle Parameter

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 in bestimmter Weise behandeln. Manchmal bedeutet das, dass ein Parameter unterstützt (oder nicht unterstützt) werden muss. Manchmal bedeutet es, einen spezifischen Wert für einen Parameter zu verlangen oder dass eine bestimmte Menge von Werten erlaubt ist. Und manchmal sind die Anforderungen komplexer.

Parameter, die nützlich, aber nicht erforderlich sind

Diese Parameter müssen vom WebRTC-Endpunkt nicht unterstützt werden, und ihre Verwendung ist ebenfalls nicht erforderlich. Ihre Verwendung kann die Benutzererfahrung in verschiedener Hinsicht verbessern, muss jedoch nicht verwendet werden. Tatsächlich sind einige von ihnen ziemlich kompliziert zu verwenden.

max-br

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

max-cpb

Wenn angegeben und von der Software unterstützt, gibt max-cpb die maximale Größe des codierten Bildpuffers an. Dies ist ein ziemlich komplexer 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 Größe des dekodierten Bildpuffers 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, gibt max-fs die maximale Größe eines einzelnen Videoframes an, ausgedrückt als Anzahl von Makroblöcken.

max-mbps

Wenn angegeben und von der Software unterstützt, ist dieser Wert eine ganze Zahl, die die maximale Rate angibt, mit der Makroblöcke pro Sekunde (in Makroblöcken pro Sekunde) verarbeitet werden sollten.

max-smbps

Wenn angegeben und von der Software unterstützt, gibt dieser Wert eine ganze Zahl an, die die maximale Verarbeitungsgeschwindigkeit für statische Makroblöcke in statischen Makroblöcken pro Sekunde angibt (unter der hypothetischen Annahme, dass alle Makroblöcke statische Makroblöcke sind).

Parameter mit besonderen Anforderungen

Diese Parameter können erforderlich oder optional sein, haben jedoch einige spezielle Anforderungen, wenn sie verwendet werden.

packetization-mode

Alle Endpunkte müssen Modus 1 (nicht verschachtelter Modus) unterstützen. Die Unterstützung anderer Packetisierungsmodi ist optional, und 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 gesendet werden. Wenn AVC mit WebRTC verwendet wird, müssen diese Informationen in-band signalisiert werden; der Parameter sprop-parameter-sets darf daher nicht in das SDP aufgenommen werden.

Parameter, die angegeben werden müssen

Diese Parameter müssen jedes Mal angegeben werden, wenn AVC in einer WebRTC-Verbindung verwendet wird.

profile-level-id

Alle WebRTC-Implementierungen sind verpflichtet, diesen Parameter in ihrem SDP anzugeben und zu interpretieren, um das verwendete Sub-Profil des Codecs zu identifizieren. Der spezifische Wert, der gesetzt wird, ist nicht definiert; was wichtig ist, ist, dass der Parameter überhaupt verwendet wird. Dies ist nützlich zu beachten, da in RFC 6184 ("RTP-Payload-Format für H.264-Video") profile-level-id völlig optional ist.

Weitere Anforderungen

Um die Unterstützung beim Wechseln zwischen Hoch- und Querformat zu gewährleisten, gibt es zwei Methoden, die verwendet werden können. Die erste ist die Videoorientierung (CVO) Kopfzeilenerweiterung des RTP-Protokolls. Wenn dies jedoch nicht im SDP als unterstützt signalisiert wird, wird empfohlen, dass Browser Display-Orientierung SEI-Nachrichten unterstützen, auch wenn dies nicht erforderlich ist.

Sofern nicht anders signalisiert, ist das Pixel-Seitenverhältnis 1:1, was anzeigt, dass die Pixel quadratisch sind.

Weitere Hinweise

Das für AVC in WebRTC verwendete Payload-Format ist in RFC 6184: RTP Payload Format for H.264 Video beschrieben. AVC-Implementierungen für WebRTC müssen die speziellen "Füller-Payload" und "Volle Frame-Einfrier"-SEI-Nachrichten unterstützen; diese werden verwendet, um einen nahtlosen Wechsel zwischen mehreren Eingabeströmen zu unterstützen.

AV1 ist allgemein beschrieben im Haupt-Leitfaden zu auf dem Web verwendeten Videocodecs.

Abhängigkeit Descriptor RTP Header Erweiterung

WebRTC unterstützt zwei Haupttechnologien zum effizienten Senden von Videos für Empfänger mit unterschiedlichen Fähigkeiten und Netzbedingungen.

AV1 verwendet die Dependency Descriptor (DD) RTP Header Erweiterung, um die Frame-Abhängigkeitsinformationen bereitzustellen, die erforderlich sind, um Anwendungsfälle für Mehrparteienkonferenzen zu unterstützen.

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

Siehe unten für weitere Details zu eventuellen WebRTC-spezifischen Überlegungen, die für jeden oben aufgeführten Codec bestehen.

Es ist nützlich zu beachten, dass RFC 7874 mehr als eine Liste von Audio-Codecs definiert, die ein WebRTC-kompatibler Browser unterstützen muss; es bietet auch Empfehlungen und Anforderungen für spezielle Audiofunktionen wie Echounterdrückung, Rauschreduzierung und Audiopegelung.

Zusätzlich zu den obligatorischen Audio-Codecs unterstützen einige Browser auch zusätzliche Codecs. Diese sind in der folgenden Tabelle aufgeführt.

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

Der Internet Speech Audio Codec (iSAC) ist ein weiterer Codec, der von Global IP Solutions entwickelt wurde und jetzt Google gehört, welches es als Open-Source angeboten hat. Es wird von Google Talk, QQ und anderen Instant-Messaging-Clients verwendet und ist speziell für Sprachübertragungen konzipiert, die in einem RTP-Stream gekapselt sind.

Komfortrauschen (CN) ist eine Form von künstlichem Hintergrundrauschen, das verwendet wird, um Lücken in einer Übertragung zu füllen, anstatt reine Stille zu verwenden. Dies hilft, einen erschreckenden Effekt zu vermeiden, der auftreten kann, wenn die Sprachaktivierung und ähnliche Funktionen einen Stream vorübergehend stoppen lassen - eine Fähigkeit, die als Diskontinuierliche Übertragung (DTX) bekannt ist. In RFC 3389 ist eine Methode zur Bereitstellung eines geeigneten Füllers während der Stille beschrieben.

Komfortrauschen wird mit G.711 verwendet und kann potenziell mit anderen Codecs verwendet werden, die keine eingebaute CN-Funktion haben. Opus, zum Beispiel, hat seine eigene CN-Fähigkeit; daher wird die Verwendung von RFC 3389 CN mit dem Opus-Codec nicht empfohlen.

Ein Audiosender muss niemals diskontinuierliche Übertragung oder Komfortrauschen verwenden.

Das Opus-Format, definiert durch RFC 6716 ist das primäre Format für Audio in WebRTC. Das RTP-Payload-Format für Opus findet sich in RFC 7587. Allgemeine Informationen über Opus und seine Fähigkeiten sowie darüber, wie andere APIs Opus unterstützen können, finden Sie im entsprechenden Abschnitt unseres Leitfadens zu auf dem Web verwendeten Audiocodecs.

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

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

Empfehlungen zur Bitrate

Bei einer Bildgröße von 20 Millisekunden zeigt die folgende Tabelle die empfohlenen Bitraten für verschiedene Medienformen.

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

G.711 definiert das Format für Pulscodemodulation (PCM)-Audio als eine Reihe von 8-Bit-Ganzzahlsamples, die bei einer Abtastrate von 8.000 Hz aufgenommen werden und eine Bitrate von 64 kbps ergeben. Sowohl µ-law als auch A-law-Kodierungen sind erlaubt.

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

WebRTC erfordert, dass G.711 8-Bit-Samples bei der Standardrate von 64 kbps verwendet, obwohl G.711 einige andere Varianten unterstützt. Weder G.711.0 (verlustfreie Komprimierung), G.711.1 (Breitband-Fähigkeit) noch andere Erweiterungen des G.711-Standards sind von WebRTC vorgeschrieben.

Aufgrund seiner niedrigen Abtastrate und Samplegröße wird die G.711-Audioqualität nach modernen Standards allgemein als schlecht angesehen, auch wenn sie in etwa dem Klang entspricht, den ein Festnetztelefon bietet. Sie wird im Allgemeinen als kleinster gemeinsamer Nenner verwendet, um sicherzustellen, dass Browser eine Audi

overbindung unabhängig von Plattformen und Browsern herstellen können, oder als allgemeine Fallback-Option.

Da ein bestimmter Browser und eine Plattform eine unterschiedliche Verfügbarkeit unter den möglichen Codecs haben können — und möglicherweise mehrere Profile oder Ebenen für einen bestimmten Codec unterstützt werden — besteht der erste Schritt bei der Konfiguration von Codecs für ein RTCPeerConnection darin, die Liste der verfügbaren Codecs zu erhalten. Dazu müssen Sie zunächst eine Verbindung herstellen, um die Liste zu erhalten.

Es gibt ein paar Möglichkeiten, dies zu tun. Die effizienteste Methode ist, die statische Methode RTCRtpSender.getCapabilities() (oder das Äquivalent RTCRtpReceiver.getCapabilities() für einen Empfänger) zu verwenden, wobei der Medientyp als Eingabeparameter angegeben wird. Um z. B. die unterstützten Codecs für Video zu ermitteln, können Sie dies tun:

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

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

Wenn sich die Verbindung im Aufbau befindet, können Sie das icegatheringstatechange-Ereignis verwenden, um zu überwachen, wann das Sammeln von ICE-Kandidaten abgeschlossen ist, und dann 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;
        return;
      }
    });
  }

  codecList = null;
});

Der Ereignishandler für icegatheringstatechange wird festgelegt. Darin prüfen wir, ob der ICE-Sammelzustand complete ist, was anzeigt, 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 durchlaufen wir die Liste der Sender und suchen nach dem ersten, dessen MediaStreamTrack anzeigt, dass sein Typ video ist, was darauf hinweist, dass die Daten des Tracks Videomedien sind. Dann rufen wir die Methode getParameters() 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.

Bei der Rückkehr ist codecList entweder null, was anzeigt, dass keine Videotracks gefunden wurden, oder es handelt sich um ein Array aus RTCCodecStats-Objekten, die jeweils eine zugelassene Codec-Konfiguration beschreiben. Besonders wichtig in diesen Objekten ist die payloadType-Eigenschaft, die einen Ein-Byte-Wert darstellt, der die beschriebene Konfiguration eindeutig identifiziert.

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 Codec-Liste neu zu ordnen. Dies ändert die Präferenzreihenfolge der Codecs und lässt Sie WebRTC mitteilen, dass ein anderer Codec bevorzugt wird.

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(mimeType);
      recvCodecs = preferCodec(mimeType);
      transceiver.setCodecPreferences([...sendCodecs, ...recvCodecs]);
    }
  });

  peerConnection.onnegotiationneeded();
}

In diesem Beispiel nimmt die Funktion changeVideoCodec() als Eingabe den MIME-Typ des gewünschten Codecs entgegen. Der Code beginnt damit, eine Liste aller Transceiver der RTCPeerConnection abzurufen.

Dann holen wir uns für jeden Transceiver den Medientyp, den der Transceiver darstellt, von der Spur des RTCRtpSender, indem wir den Typ des Tracks erhalten. Ebenso holen wir die Listen aller von dem Browser unterstützten Codecs, sowohl für das Senden als auch Empfangen von Video, mithilfe der getCapabilities()-statischen Methode von sowohl RTCRtpSender als auch RTCRtpReceiver ein.

Wenn das Medium Video ist, rufen wir eine Methode namens preferCodec() für die Codec-Listen sowohl des Senders als auch des Empfängers auf; diese Methode ordnet die Codec-Liste in der gewünschten Weise um (siehe unten).

Schließlich rufen wir die Methode RTCRtpTransceiver's setCodecPreferences() auf, um anzugeben, dass die angegebenen Sende- und Empfangs-Codecs in der neu angeordneten Reihenfolge erlaubt sind.

Damit ist dies für jeden Transceiver auf der RTCPeerConnection abgeschlossen; sobald alle Transceiver aktualisiert wurden, rufen wir den onnegotiationneeded-Ereignishandler auf, der ein neues Angebot erstellt, die lokale Beschreibung aktualisiert, das Angebot an den Remote-Peer sendet und so weiter, was die Neuverhandlung der Verbindung auslöst.

Die vom obigen Code aufgerufene preferCodec()-Funktion sieht folgendermaßen aus, um einen angegebenen Codec an den Anfang der Liste zu verschieben (während der Verhandlung priorisiert zu werden):

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

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

  return sortedCodecs.concat(otherCodecs);
}

Dieser Code teilt nur die Codec-Liste in zwei Arrays auf: eines, das Codecs enthält, deren MIME-Typ mit dem durch den mimeType-Parameter angegebenen übereinstimmt, und das andere mit allen anderen Codecs. Sobald die Liste aufgeteilt ist, werden sie wieder zusammengefügt, wobei die Einträge, die dem gegebenen mimeType entsprechen, zuerst kommen, gefolgt von allen anderen Codecs. Die neu angeordnete Liste wird dann an den Aufrufer zurückgegeben.

Sofern nicht anders angegeben, entsprechen die standardmäßigen oder, genauer gesagt, bevorzugten Codecs, die von jeder Browser-Implementierung von WebRTC angefordert werden, den Codecs, die in der untenstehenden Tabelle angezeigt werden.

Bevor Sie sich für einen Codec entscheiden, der nicht zu den obligatorischen Codecs gehört (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 auf allen Geräten als verfügbar vorausgesetzt werden, die WebRTC unterstützen.

Wenn Sie sich entscheiden, einen anderen Codec als die obligatorischen zu bevorzugen, sollten Sie mindestens einen Fallback zu einem der obligatorischen Codecs zulassen, wenn die Unterstützung für den bevorzugten Codec nicht vorhanden ist.

Im Allgemeinen, wenn es verfügbar ist und das Audio, das Sie senden möchten, eine Abtastrate von mehr als 8 kHz hat, sollten Sie ernsthaft in Erwägung ziehen, Opus als Ihren primären Codec zu verwenden. Für reine Sprachverbindungen in einer eingeschränkten Umgebung kann die Verwendung von G.711 bei einer Abtastrate von 8 kHz ein akzeptables Konversationserlebnis bieten, aber normalerweise verwenden Sie G.711 als Fallback-Option, da es andere Optionen gibt, die effizienter sind und besser klingen, wie zum Beispiel Opus in seinem Schmalbandmodus.

Es gibt eine Reihe von Faktoren, die bei der Auswahl eines Video-Codecs (oder einerset Codecs) zur Unterstützung berücksichtigt werden müssen.

Lizenzbedingungen

Bevor Sie sich für einen Video-Codec entscheiden, sollten Sie sicherstellen, dass Sie sich über die Lizenzanforderungen im Klaren sind, die für den gewählten Codec gelten; Informationen zu möglichen Lizenzierungsfragen finden Sie in unserem Hauptleitfaden zu auf dem Web verwendeten Videocodecs. Von den beiden obligatorischen Codecs für Video — VP8 und AVC/H.264 — hat nur VP8 keine Lizenzanforderungen. Wenn Sie AVC auswählen, stellen Sie sicher, dass Sie: sich über mögliche Gebühren im Klaren sind, die Sie möglicherweise zahlen müssen; das gesagt, die Patentinhaber haben im Allgemeinen erklärt, dass die meisten typischen Website-Entwickler sich keine Sorgen um die Lizenzgebühren machen müssen, die typischerweise mehr auf die Entwickler der Codierungs- und Decodierungssoftware ausgerichtet sind.

Leistungsanforderungen und Akkulaufzeit

Ein weiterer zu berücksichtigender Faktor – insbesondere auf mobilen Plattformen – ist die Auswirking eines Codecs auf die Akkulaufzeit. Wenn ein Codec auf einer bestimmten Plattform in Hardware verarbeitet wird, ist dies wahrscheinlich mit einer viel besseren Akkulaufzeit und weniger Wärmeerzeugung verbunden.

Zum Beispiel hat Safari für iOS und iPadOS WebRTC eingeführt, wobei AVC der einzige unterstützte Video-Codec ist. AVC hat den Vorteil, auf iOS und iPadOS in Hardware codiert und dekodiert werden zu können. Safari 12.1 führte die Unterstützung für VP8 innerhalb von IRC ein, was die Interoperabilität verbessert, jedoch zu einem Nachteil führt — VP8 hat keine Hardwareunterstützung auf iOS-Geräten, sodass die Verwendung eine erhöhte Prozessorbelastung und verringerte Akkulaufzeit verursacht.

Leistung

Glücklicherweise bieten VP8 und AVC aus Sicht des Endverbrauchers eine ähnliche Leistung und eignen sich gleichermaßen gut für Videokonferenzen und andere WebRTC-Lösungen. Die endgültige Entscheidung liegt bei Ihnen. Welchen Sie auch wählen, stellen Sie sicher, dass Sie die in diesem Artikel bereitgestellten Informationen über alle spezifischen Konfigurationsprobleme lesen, mit denen Sie bei diesem Codec konfrontiert werden könnten.

Denken Sie daran, dass bei der Auswahl eines Codecs, der nicht auf der Liste der obligatorischen Codecs steht, die Gefahr besteht, einen Codec auszuwählen, der von einem Browser, den Ihre Benutzer möglicherweise bevorzugen, nicht unterstützt wird. Lesen Sie den Artikel Umgang mit Problemen bei der Medienunterstützung in Webinhalten, um mehr darüber zu erfahren, wie Sie Unterstützung für Ihre bevorzugten Codecs bieten können, während Sie dennoch auf Browser zurückgreifen können, die diesen Codec nicht implementieren.

Bei der Auswahl und Konfiguration von Codecs gibt es interessante potenzielle Sicherheitsfragen. WebRTC-Video wird mithilfe der Datagram Transport Layer Security (DTLS) geschützt, aber es ist theoretisch möglich, dass eine motivierte Partei aus dem Bitratenverhalten der Variable-Bitrate (VBR)-Codecs ableitet, wie viel Änderung von Frame zu Frame auftritt, indem sie die Bitrate des Streams überwacht, und wie sie sich über die Zeit ändert. Dies könnte einem Angreifer potenziell ermöglichen, Rückschlüsse auf den Inhalt des Streams zu ziehen, angesichts des Schwebe- und Flussverhaltens der Bitrate.

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

Es kann nützlich sein, sich die IANA's Liste der RTP Payload-Format-Medientypen anzusehen; dies ist eine vollständige Liste der MIME-Medientypen, die für die potentielle Verwendung in RTP-Streams definiert sind, wie sie in WebRTC verwendet werden. Die meisten davon werden in WebRTC-Kontexten nicht verwendet, aber die Liste kann dennoch nützlich sein.

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

• WebRTC API
• Einführung in WebRTC-Protokolle
• WebRTC-Konnektivität
• Leitfaden zu auf dem Web verwendeten Videocodecs
• Leitfaden zu auf dem Web verwendeten Audiocodecs
• Digitale Videokonzepte
• Digitale Audiokonzepte