Codecs verwendet von WebRTC

WebRTC verwendet nackte MediaStreamTrack-Objekte für jeden Track, der von einem Peer zum anderen geteilt wird, ohne einen Container oder sogar ohne einen MediaStream, der mit den Tracks verbunden ist. Welche Codecs in diesen Tracks enthalten sein können, wird von der WebRTC-Spezifikation nicht festgelegt. Allerdings spezifiziert RFC 7742, dass alle mit WebRTC kompatiblen Browser VP8 und das Constrained Baseline-Profil von H.264 für Video unterstützen müssen, und RFC 7874, dass Browser mindestens den Opus-Codec sowie das PCMA- und PCMU-Format 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 spezielle Benutzerkomfortfunktionen wie Echounterdrückung. Dieser Leitfaden überprüft die Codecs, die von Browsern implementiert werden müssen, sowie andere Codecs, die einige oder alle Browser für WebRTC unterstützen.

Obwohl Kompression immer eine Notwendigkeit bei der Verarbeitung von Medien im Web ist, ist sie von besonderer Bedeutung beim Videokonferieren, um sicherzustellen, dass die Teilnehmer ohne Verzögerungen oder Unterbrechungen kommunizieren können. Von sekundärer Bedeutung ist die Notwendigkeit, Video und Audio zu synchronisieren, damit die Bewegungen und alle zusätzlichen Informationen (wie Folien oder eine Projektion) gleichzeitig mit dem entsprechenden Audio präsentiert werden.

Bevor die codecspezifischen Fähigkeiten und Anforderungen betrachtet werden, gibt es einige allgemeine Anforderungen, die von jeder mit WebRTC verwendeten Codec-Konfiguration erfüllt werden müssen.

Sofern das SDP nicht speziell etwas anderes signalisiert, muss der Webbrowser, der einen WebRTC-Video-Stream empfängt, in der Lage sein, Videos mit 20 FPS bei einer Mindestauflösung von 320 Pixel Breite und 240 Pixel Höhe zu verarbeiten. Es wird empfohlen, dass Videos mit einer Bildrate und Größe nicht niedriger als diese kodiert werden, da dies im Wesentlichen die Untergrenze von dem ist, was WebRTC im Allgemeinen zu verarbeiten erwartet wird.

SDP unterstützt eine codec-unabhängige Möglichkeit, bevorzugte Videoauflösungen anzugeben (RFC 6236. Dies geschieht durch 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, daher müssen Sie darauf vorbereitet sein, Medien in einer anderen Auflösung zu empfangen als die, die Sie angefordert haben. Über diese maximale Auflösungsanforderung hinaus können spezifische Codecs weitere Möglichkeiten bieten, spezifische Medieneinstellungen anzufordern.

WebRTC legt eine Reihe von Basis-Codecs fest, die alle kompatiblen Browser unterstützen müssen. Einige Browser können auch andere Codecs zulassen.

Unten sind die Video-Codec, die in jedem vollständig WebRTC-kompatiblen Browser erforderlich sind, sowie die Profile, die erforderlich sind, und die Browser, die diese Anforderungen tatsächlich erfüllen.

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

Vollständige Details zu den Video-Codecs und Konfigurationen, die WebRTC unterstützen muss, finden Sie in RFC 7742: WebRTC Video Processing and Codec Requirements. Es ist bemerkenswert, dass das RFC eine Vielzahl von video-bezogenen Anforderungen abdeckt, einschließlich Farbräume (sRGB ist der bevorzugte, aber nicht erforderliche Standardfarbraum), Empfehlungen für Webcam-Verarbeitungsfunktionen (automatischer Fokus, automatischer Weißabgleich, automatisches Lichtniveau) und so weiter.

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

VP8, das wir allgemein beschreiben im Haupt-Leitfaden zu den auf dem Web verwendeten Video-Codecs, hat einige spezifische Anforderungen, die befolgt werden müssen, wenn es verwendet wird, um einen Video-Track in einer WebRTC-Verbindung zu kodieren oder zu dekodieren.

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

Weitere Hinweise

Das Netzwerk-Payload-Format zum Teilen von VP8 mit RTP (wie beim Verwenden von WebRTC) wird beschrieben in RFC 7741: RTP Payload Format for VP8 Video.

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 ist speziell für Anwendungen mit niedriger Komplexität und niedriger Latenz wie mobile Videos und Videokonferenzen sowie für Plattformen mit geringeren Leistungsfähigkeiten zur Videobearbeitung entwickelt.

Unser Überblick über AVC und seine Funktionen finden Sie im Hauptleitfaden zu den Video-Codecs.

Besondere Anforderungen an die Unterstützung von Parametern

AVC bietet eine Vielzahl von Parametern zur Steuerung optionaler Werte. Um die Zuverlässigkeit der gemeinsamen Nutzung von WebRTC-Medien auf mehreren Plattformen und Browsern zu verbessern, ist es erforderlich, dass WebRTC-Endpunkte, die AVC unterstützen, bestimmte Parameter auf bestimmte Weise verarbeiten. Manchmal bedeutet dies, dass ein Parameter unterstützt werden muss (oder nicht unterstützt werden darf). Manchmal bedeutet es, dass ein bestimmter Wert für einen Parameter erforderlich ist, oder dass ein bestimmter Satz von Werten erlaubt ist. Und manchmal sind die Anforderungen komplizierter.

Parameter, die nützlich, aber nicht erforderlich sind

Diese Parameter müssen von dem WebRTC-Endpunkt nicht unterstützt werden, und ihre Verwendung ist auch nicht erforderlich. Ihre Verwendung kann die Benutzererfahrung auf verschiedene Weise verbessern, muss jedoch nicht verwendet werden. Tatsächlich sind einige davon ziemlich kompliziert zu verwenden.

max-br

Wenn angegeben und von der Software unterstützt, gibt der max-br-Parameter die maximale Videobitrate in Einheiten von 1.000 bps für VCL und 1.200 bps für NAL an. Details hierzu 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 Einheitsgröß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 decodierten Bildpuffers an, angegeben 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 Videobildes an, angegeben 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 verarbeitet werden sollen (in Makroblöcken pro Sekunde).

max-smbps

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

Parameter mit spezifischen Anforderungen

Diese Parameter können erforderlich sein oder nicht, haben aber bei Verwendung spezielle Anforderungen.

packetization-mode

Alle Endpunkte müssen den Modus 1 (nicht-interleaved Mode) unterstützen. Die Unterstützung anderer Paketisierungsmodi ist optional und der Parameter selbst muss nicht angegeben werden.

sprop-parameter-sets

Sequenz- und Bildinformationen für AVC können entweder innerhalb oder außerhalb des Bandes gesendet werden. Wenn AVC mit WebRTC verwendet wird, muss diese Information im 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 immer angegeben werden, wenn AVC in einer WebRTC-Verbindung verwendet wird.

profile-level-id

Alle WebRTC-Implementierungen müssen diesen Parameter in ihrem SDP angeben und interpretieren, um das Unterprofil zu identifizieren, das vom Codec verwendet wird. Der spezifische Wert, der festgelegt wird, ist nicht definiert; wichtig ist, dass der Parameter überhaupt verwendet wird. Dies ist nützlich zu beachten, da in RFC 6184 ("RTP Payload Format for H.264 Video") profile-level-id vollständig optional ist.

Andere Anforderungen

Zur Unterstützung des Umschaltens zwischen Portrait- und Landschaftsorientierung gibt es zwei Methoden, die verwendet werden können. Die erste ist die Video-Orientierungs-Erweiterung (CVO) für das RTP-Protokoll. Falls dies jedoch nicht im SDP als unterstützt signalisiert wird, wird empfohlen, dass Browser SEI-Meldungen zur Display-Orientierung unterstützen, obwohl dies nicht erforderlich ist.

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

Weitere Hinweise

Das für AVC in WebRTC verwendete Payload-Format wird in RFC 6184: RTP Payload Format for H.264 Video beschrieben. WebRTC-AVC-Implementierungen müssen die speziellen "Filler-Payload"- und "Full Frame Freeze"-SEI-Nachrichten unterstützen; diese werden verwendet, um das reibungslose Umschalten zwischen mehreren Eingabeströmen zu unterstützen.

AV1 wird allgemein beschrieben im Hauptleitfaden zu den im Web verwendeten Video-Codecs](/de/docs/Web/Media/Guides/Formats/Video_codecs).

Dependency Descriptor RTP Header-Erweiterung

WebRTC unterstützt zwei Haupttechnologien für das effiziente Senden von Videos für Empfänger, die mit unterschiedlichen Fähigkeiten und Netzwerkbedingungen arbeiten.

AV1 verwendet die Dependency Descriptor (DD) RTP Header-Erweiterung, um Frame-Abhängigkeitsinformationen bereitzustellen, die zur Unterstützung von Multi-Party-Konferenzfällen benötigt werden.

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

Nachstehend finden Sie weitere Einzelheiten zu möglichen WebRTC-spezifischen Überlegungen für jeden der oben aufgeführten Codecs.

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

Zusätzlich zu den verpflichtenden 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 quelloffener 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 Browser-Entwickler haben es für WebRTC übernommen.

Der Internet Speech Audio Codec (iSAC) ist ein weiterer Codec, der von Global IP Solutions entwickelt und jetzt von Google übernommen wurde, das ihn quelloffen gemacht hat. Es wird von Google Talk, QQ und anderen Instant-Messaging-Clients verwendet und speziell für Sprachübertragungen entwickelt, die in einen RTP-Stream gekapselt sind.

Comfort Noise (CN) ist eine Form von künstlichem Hintergrundrauschen, das verwendet wird, um Lücken in einer Übertragung anstelle von reinem Schweigen zu füllen. Dies hilft, einen erschreckenden Effekt zu vermeiden, der auftreten kann, wenn Sprachaktivierung und ähnliche Funktionen einen Stream vorübergehend stoppen, um eine Fähigkeit namens Diskontinuierliche Übertragung (DTX) zu ermöglichen. In RFC 3389 wird eine Methode zur Bereitstellung eines geeigneten Fillers während der Stille beschrieben.

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

Ein Audio-Sender ist nie verpflichtet, diskontinuierliche Übertragung oder Komfortrauschen zu verwenden.

Das Opus-Format, definiert durch RFC 6716 ist das Hauptformat für Audio in WebRTC. Das RTP-Payload-Format für Opus ist in RFC 7587 zu finden. Allgemeine Informationen zu Opus und seinen Fähigkeiten und wie andere APIs Opus unterstützen können, finden Sie im entsprechenden Abschnitt unseres Leitfadens zu den im Web verwendeten Audio-Codecs.

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 gearbeitet wird, das unterschiedliche Komplexitätsgrade aufweisen kann. Seine Unterstützung von In-Band-Stereo-Signalen ermöglicht die Unterstützung von Stereo ohne die Demultiplexing-Prozess zu komplizieren.

Der gesamte Bereich der von Opus unterstützten Bitraten (6 kbps bis 510 kbps) wird in WebRTC unterstützt, wobei es möglich ist, die Bitrate dynamisch zu ändern. Höhere Bitraten verbessern in der Regel die Qualität.

Bitratempfehlungen

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

Die Bitrate kann jederzeit angepasst werden. Um Netzwerküberlastung zu vermeiden, sollte die durchschnittliche Audio-Bitrate nicht die verfügbare Netzwerkbandbreite überschreiten (abzüglich aller anderen bekannten oder erwarteten Bandbreitenanforderungen).

G.711 definiert das Format für Puls-Code-Modulation (PCM) Audio als eine Reihe von 8-Bit-Ganzzahlen, die bei einer Abtastrate von 8.000 Hz aufgenommen wurden, was zu einer Bitrate von 64 kbps führt. Sowohl µ-law als auch A-law Kodierungen sind erlaubt.

G.711 wird 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 Variationen unterstützt. Weder G.711.0 (verlustfreie Kompression), G.711.1 (Breitbandfähigkeit) noch andere Erweiterungen des G.711-Standards sind durch WebRTC vorgeschrieben.

Aufgrund seiner niedrigen Abtastrate und Größe wird die Audioqualität von G.711 nach modernen Maßstäben allgemein als schlecht angesehen, obwohl sie ungefähr dem entspricht, was ein Festnetztelefon klingt. Es wird im Allgemeinen als kleinster gemeinsamer Nenner verwendet, um sicherzustellen, dass Browser eine Audioverbindung unabhängig von Plattformen und Browsern erreichen können, oder als allgemeine Fallback-Option.

Da ein gegebener Browser und eine Plattform möglicherweise unterschiedliche Verfügbarkeiten unter den potenziellen Codecs haben und möglicherweise mehrere Profile oder Levels für einen gegebenen Codec unterstützt werden, besteht der erste Schritt bei der Konfiguration von Codecs für eine RTCPeerConnection darin, die Liste der verfügbaren Codecs abzurufen. Dazu müssen Sie zuerst eine Verbindung herstellen, um die Liste abzurufen.

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

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

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

Wenn die Verbindung im Begriff ist, gestartet zu werden, können Sie das icegatheringstatechange-Ereignis verwenden, um auf das Abschließen des Prozesses des Einsammelns von ICE-Kandidaten zu achten, 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 Ereignis-Handler für icegatheringstatechange ist festgelegt; darin schauen wir nach, ob der ICE-Sammelstatus complete ist, was anzeigt, dass keine weiteren Kandidaten mehr gesammelt werden. Die Methode RTCPeerConnection.getSenders() wird aufgerufen, um eine Liste aller RTCRtpSender-Objekte, die von der Verbindung verwendet werden, zu erhalten.

Mit dieser Liste in der Hand gehen wir durch die Liste der Sender und suchen nach dem ersten, dessen MediaStreamTrack anzeigt, dass sein kind video ist, was anzeigt, 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 Video-Track gefunden wird, setzen wir codecList auf null.

Nach der Rückkehr ist codecList also entweder null, um anzuzeigen, dass keine Videotracks gefunden wurden, oder es ist ein Array von RTCCodecStats-Objekten, jede beschreibt eine zulässige Codec-Konfiguration. Von besonderer Bedeutung in diesen Objekten: die payloadType-Eigenschaft, die ein Ein-Byte-Wert ist, der die beschriebene Konfiguration eindeutig identifiziert.

Sobald Sie eine Liste der verfügbaren Codecs haben, können Sie sie ändern und dann die überarbeitete Liste an RTCRtpTransceiver.setCodecPreferences() senden, um die Codec-Liste zu verändern. Dies ändert die Präferenzreihenfolge der Codecs und ermöglicht es Ihnen, WebRTC zu bitten, einen anderen Codec allen 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(mimeType);
      recvCodecs = preferCodec(mimeType);
      transceiver.setCodecPreferences([...sendCodecs, ...recvCodecs]);
    }
  });

  peerConnection.onnegotiationneeded();
}

In diesem Beispiel nimmt die Funktion changeVideoCodec() als Eingabe den MIME-Typ des Codecs, den Sie verwenden möchten. Der Code beginnt damit, eine Liste aller Transceiver in der RTCPeerConnection zu erhalten.

Dann, für jeden Transceiver, erhalten wir die Art des Mediums, das durch den Transceiver repräsentiert wird, von der RTCRtpSender's Track's kind. Wir erhalten auch die Listen aller Codecs, die vom Browser sowohl für das Senden als auch für das Empfangen von Video unterstützt werden, indem wir die statische Methode getCapabilities() von sowohl RTCRtpSender als auch RTCRtpReceiver verwenden.

Wenn das Medium Video ist, rufen wir eine Methode namens preferCodec() für die Codec-Listen des Senders und des Empfängers auf; diese Methode ordnet die Codec-Liste so an, wie wir es möchten (siehe unten).

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

Dies wird für jeden Transceiver in der RTCPeerConnection gemacht; nachdem alle Transceiver aktualisiert wurden, rufen wir den onnegotiationneeded-Event-Handler auf, der ein neues Angebot erstellt, die lokale Beschreibung aktualisiert, das Angebot zum entfernten Peer sendet und so weiter, wodurch die Neuverhandlung der Verbindung ausgelöst wird.

Die preferCodec()-Funktion, die vom obigen Code aufgerufen wird, sieht so aus, um einen bestimmten Codec an die Spitze der Liste zu verschieben (um während der Aushandlung 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 einfach die Codec-Liste in zwei Arrays auf: eines, das Codecs enthält, deren MIME-Typ mit dem übereinstimmt, der vom mimeType-Parameter spezifiziert wird, und das andere mit allen anderen Codecs. Sobald die Liste aufgeteilt ist, werden sie mit den Einträgen, die mit dem angegebenen mimeType übereinstimmen, zuerst wieder zusammengefügt, gefolgt von allen anderen Codecs. Die neu angeordnete Liste wird dann zum Aufrufer zurückgegeben.

Sofern nicht anders angegeben, sind die von jedem Browser bevorzugten — oder korrekter die bevorzugten — Codecs für die Implementierung von WebRTC in der folgenden Tabelle aufgeführt.

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

Wenn Sie sich entscheiden, einen anderen Codec als die verpflichtenden zu bevorzugen, sollten Sie zumindest einen Fallback auf einen der verpflichtenden Codecs erlauben, 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 größer als 8 kHz hat, sollten Sie ernsthaft erwägen, Opus als Ihren Hauptcodec zu verwenden. Für stimmbezogene Verbindungen in einer eingeschränkten Umgebung kann G.711 bei einer Abtastrate von 8 kHz ein akzeptables Erlebnis für Gespräche bieten, aber in der Regel verwenden Sie G.711 als Fallback-Option, da es andere Optionen gibt, die effizienter sind und besser klingen, wie Opus im Schmalbandmodus.

Es gibt eine Reihe von Faktoren, die bei der Entscheidung über einen Video-Codec (oder eine Reihe von Codecs) zu unterstützen berücksichtigt werden müssen.

Lizenzbestimmungen

Bevor Sie einen Video-Codec wählen, stellen Sie sicher, dass Sie sich über die Lizenzanforderungen für den ausgewählten Codec im Klaren sind; Sie finden Informationen über mögliche Lizenzierungsprobleme in unserem Hauptleitfaden zu den im Web verwendeten Video-Codecs](/de/docs/Web/Media/Guides/Formats/Video_codecs). Von den beiden verpflichtenden Codecs für Video—VP8 und AVC/H.264—hat nur VP8 keine Lizenzierungsanforderungen. Wenn Sie AVC wählen, stellen Sie sicher, dass Sie sich möglicher Gebühren bewusst sind, die Sie zahlen müssen; allerdings haben die Patentinhaber im Allgemeinen gesagt, dass die meisten typischen Website-Entwickler sich nicht um Lizenzgebühren kümmern müssen, die sich in der Regel mehr auf die Entwickler der Kodierungs- und Dekodierungssoftware konzentrieren.

Energiebedarf und Akkulaufzeit

Ein weiterer zu berücksichtigender Faktor—besonders auf mobilen Plattformen—ist der Einfluss, den ein Codec auf die Akkulaufzeit haben kann. Wenn ein Codec auf einer bestimmten Plattform hardwareseitig gehandhabt wird, ist dieser Codec wahrscheinlich besser für die Akkulaufzeit und die Wärmeproduktion.

Zum Beispiel führte Safari für iOS und iPadOS WebRTC mit AVC als einzigem unterstützten Video-Codec ein. AVC hat den Vorteil, auf iOS und iPadOS hardwareseitig kodiert 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 mit Kosten—VP8 hat keine Hardwareunterstützung auf iOS-Geräten, so dass dessen Verwendung zu erhöhter Prozessorbelastung und verringerter Akkulaufzeit führt.

Leistung

Glücklicherweise leisten VP8 und AVC aus der Endbenutzerperspektive ähnlich und sind gleichermaßen für die Verwendung in Videokonferenzen und anderen WebRTC-Lösungen geeignet. Die endgültige Entscheidung obliegt Ihnen. Unabhängig davon, was Sie wählen, lesen Sie die in diesem Artikel bereitgestellten Informationen über etwaige spezielle Konfigurationsthemen, mit denen Sie sich bei diesem Codec auseinandersetzen müssen.

Denken Sie daran, dass die Auswahl eines Codecs, der nicht auf der Liste der verpflichtenden Codecs steht, wahrscheinlich das Risiko birgt, einen Codec auszuwählen, der nicht von einem Browser unterstützt wird, den Ihre Benutzer möglicherweise bevorzugen. Lesen Sie den Artikel Umgang mit Medienunterstützungsproblemen im Web-Content, 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.

Es gibt interessante potenzielle Sicherheitsprobleme, die sich bei der Auswahl und Konfiguration von Codecs ergeben. WebRTC-Video wird durch Datagram Transport Layer Security (DTLS) geschützt, aber theoretisch ist es für eine motivierte Partei möglich, die Menge an Veränderung abzuleiten, die von Frame zu Frame auftritt, wenn variable Bitrate (VBR)-Codecs verwendet werden, indem die Bitrate des Streams und wie sie sich im Laufe der Zeit ändert, überwacht wird. Dies könnte potenziell einem Angreifer ermöglichen, etwas über den Inhalt des Streams aus dem Auf und Ab der Bitrate abzuleiten.

Weitere Informationen zu Sicherheitsüberlegungen 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-Liste der RTP-Payload-Format-Medientypen anzusehen; dies ist eine vollständige Liste der MIME-Medientypen, die für den potenziellen Einsatz in RTP-Streams, wie sie in WebRTC verwendet werden, definiert sind. Die meisten davon werden nicht in WebRTC-Kontexten verwendet, aber die Liste kann dennoch nützlich sein.

Siehe auch RFC 4855, das sich mit dem Register der Medientypen befasst.

• WebRTC API
• Einführung in WebRTC-Protokolle
• WebRTC-Konnektivität
• Leitfaden zu den im Web verwendeten Video-Codecs
• Leitfaden zu den im Web verwendeten Audio-Codecs
• Konzepte digitaler Videos
• Konzepte digitaler Audios