Die WebCodecs-API im Detail

WebCodecs ist eine browserbasierte JavaScript-API, die Entwicklern direkten Zugriff auf die im Browser eingebauten Video- und Audio-Codecs gibt – über rohe VideoEncoder-, VideoDecoder-, AudioEncoder- und AudioDecoder-Objekte, ohne den vollständigen WebRTC-Stack oder das <video>-Element zu durchlaufen. Sie existiert, weil immer mehr Entwickler eine Kontrolle auf Frame-Ebene brauchen, die WebRTC bewusst abstrahiert: eigener Transport, Verarbeitung pro Frame, maschinelles Lernen auf rohen Pixeln – nichts davon passt sauber in eine API, die Peer-to-Peer-Calls einfach machen soll. Dieser Artikel betrachtet, was die WebCodecs-API tatsächlich ist, was sie Ihnen bietet, wie sie sich zu WebRTC verhält und wann es realistisch lohnt, zu ihr zu greifen.

Inhaltsverzeichnis

1. Das Problem, das WebCodecs löst
   
2. Die zentralen Bausteine
   
3. WebCodecs vs. WebRTC
   
4. Was Sie damit tatsächlich bauen würden
   
5. Browser-Unterstützung und die Vorbehalte aus der Praxis
   
6. Brauchen Sie WebCodecs oder eine Plattform, die das für Sie übernimmt?
   
7. Fazit
   
8. Häufig gestellte Fragen

Das Problem, das WebCodecs löst

WebRTC und das <video>-Element sind konzeptbedingt All-in-one. WebRTC bündelt Erfassung, Codierung, Transport, Jitter-Buffering und Rendering in einer einzigen Pipeline und hält die Codec-Ebene bewusst außer Reichweite: Sie konfigurieren Präferenzen, berühren aber nie einen rohen codierten Frame. Für einen Standard-Videocall ist genau das richtig: Niemand, der ein Meeting-Produkt baut, möchte die Überlastungssteuerung selbst schreiben. Aber es wird zur Einschränkung, sobald Sie etwas brauchen, das WebRTC nicht offenlegen sollte – etwa Frames in ein Machine-Learning-Modell zu geben, bevor sie gesendet werden, codierte Ausgabe in ein eigenes Dateiformat zu muxen oder Medien über einen Transport zu übertragen, den WebRTC nicht nutzt.

WebCodecs löst das, indem es die Schritte des Codierens und Decodierens für sich allein offenlegt, losgelöst von Erfassung und Transport. Sie erhalten rohen Codec-Zugriff und sind selbst dafür verantwortlich, die Pipeline drumherum zu bauen – genau der Kompromiss, den Entwickler, die zu dieser API greifen, eingehen wollen.

Die zentralen Bausteine

Die API-Oberfläche ist kleiner, als es klingen mag. Zwei Objektfamilien erledigen die Arbeit:

• Rohe Medieneinheiten. VideoFrame und AudioData halten unkomprimierte Medien. Ein VideoFrame trägt Pixeldaten plus Metadaten wie Zeitstempel und Dauer, gebunden an den Speicher, den der Browser in diesem Moment gerade nutzt.
• Encoder und Decoder. VideoEncoder und VideoDecoder erledigen die eigentliche Codec-Arbeit. Ein VideoEncoder nimmt VideoFrame-Objekte und wandelt sie in EncodedVideoChunk-Instanzen um (die komprimierten Bytes plus etwas Metadaten, insbesondere, ob ein Chunk ein Keyframe oder ein Delta-Frame ist). Ein VideoDecoder macht das Umgekehrte und wandelt EncodedVideoChunk-Objekte zurück in VideoFrame-Objekte. AudioEncoder und AudioDecoder spiegeln das für Audio und arbeiten mit AudioData und EncodedAudioChunk.

Eine minimale Pipeline sieht so aus:

1. Ein VideoFrame erfassen oder erzeugen.
2. Es an einen konfigurierten VideoEncoder übergeben.
3. In einem Callback ein EncodedVideoChunk zurückerhalten.
4. Diesen Chunk dorthin senden, wo Sie ihn brauchen – etwa über WebTransport, einen WebSocket oder einen Data Channel – oder ihn in eine Muxing-Bibliothek für eine Datei leiten.
5. Auf der Empfangsseite jeden Chunk in einen VideoDecoder geben, der Ihnen VideoFrame-Objekte zurückgibt.

Was Sie von dort aus mit diesen Frames tun, bleibt Ihnen überlassen: sie auf ein Canvas zeichnen, sie als Textur an WebGPU oder WebGL für GPU-seitige Effekte übergeben, ihre rohen Pixel für ein ML-Modell auslesen oder sie in einen MediaStreamTrackGenerator geben, um sie wieder in einen gewöhnlichen Videostream zu verwandeln. Alles läuft asynchron und wird am besten außerhalb des Haupt-Threads in einem Web Worker ausgeführt, da Encode- und Decode-Callbacks viele Male pro Sekunde feuern können und die Seite sonst träge machen würden.

Nichts davon ist jedoch frei geformt. Sowohl Encoder als auch Decoder müssen mit einem bestimmten Codec-String konfiguriert werden, bevor sie etwas annehmen, und dieser String muss nicht nur die Codec-Familie benennen, sondern auch das Profil und das Level (bei anderen Codecs als VP8), da der Hardware-Decoder eines Browsers oft nur ein schmales Band an Konfigurationen unterstützt. Das falsch zu machen bringt die Seite nicht zum Absturz; der Encoder oder Decoder meldet schlicht, dass er die angeforderte Konfiguration nicht unterstützen kann – weshalb die meisten realen Implementierungen die Unterstützung prüfen, bevor sie sich auf einen Codec festlegen, statt das Scheitern mitten im Stream zu entdecken.

WebCodecs vs. WebRTC: wie sie zusammenhängen (nicht konkurrieren)

Die häufigste Verwechslung ist, dies als direkten Ersatz für WebRTC zu behandeln. Das ist es nicht. WebRTC besitzt weiterhin die Echtzeit-Peer-Verbindungen, die NAT-Traversierung via ICE, die Überlastungssteuerung und die gesamte SDP-Offer/Answer-Aushandlung, und WebCodecs versucht nicht, irgendetwas davon nachzubilden. WebCodecs ist nur die Codec-Ebene, jetzt direkt erreichbar statt in WebRTCs Pipeline eingeschlossen. Wenn Sie Peer-to-Peer-Calling mit sinnvollen Voreinstellungen brauchen, bleibt WebRTC das Werkzeug; WebCodecs nutzen Sie, wenn Sie etwas bauen wollen, das WebRTCs Blackbox nicht bietet – und bereit sind, Transport- und Fehlerbehebungslogik selbst zu liefern.

Genau diese Lücke füllt das aufkommende Muster aus WebCodecs plus WebTransport. WebTransport gibt dem Browser ein QUIC-basiertes HTTP/3-Transport-Primitiv ohne WebRTCs Aushandlungs-Overhead, wobei es ein Client-Server-Transport ist (Browser-zu-Server statt Peer-to-Peer) und WebRTC damit ergänzt, statt es rundweg zu ersetzen. Es mit WebCodecs zu koppeln ergibt eine stärker entbündelte Alternative zu WebRTC für bestimmte Low-Latency-Streaming-Szenarien: Es ist der browserseitige Stack, auf dem neuere Protokolle wie Media over QUIC aufbauen. Wir haben WebRTC und Media over QUIC an anderer Stelle ausführlich behandelt, daher gehen wir das hier nicht erneut durch, abgesehen von dem Hinweis, wie die Teile zusammenpassen.

Was Sie damit tatsächlich bauen würden

In der Praxis taucht WebCodecs in einer recht bestimmten Reihe von Projekten auf:

• Low-Latency-Live-Streaming mit eigenem Transport. Das ist der Paradefall: WebCodecs mit WebTransport zu koppeln lässt Sie eine Auslieferungs-Pipeline bauen, die auf Ihre eigenen Kompromisse bei Latenz und Qualität abgestimmt ist, statt WebRTCs Voreinstellungen hinzunehmen.
• Verarbeitung auf Frame-Ebene, etwa Hintergrundentfernung oder Computer-Vision-Analyse, die rohe Pixel prüfen oder verändern muss, bevor sie codiert werden. Findet diese Verarbeitung innerhalb eines laufenden WebRTC-Calls statt, kann WebRTCs eigene Insertable-Streams-API das oft ohne WebCodecs erledigen (mehr dazu im Entscheidungsabschnitt weiter unten). WebCodecs verdient seinen Platz bei Frame-Ebenen-Arbeit, die ganz außerhalb eines laufenden Calls liegt, wo WebRTCs Abstraktion von vornherein nie im Spiel war.
• Cloud-Gaming und Remote-Rendering. Diese Workloads legen intensiven Wert auf Encode-Latenz und wollen keinen universellen Konferenz-Stack im Weg haben, sodass hardwarebeschleunigtes Encoding reizvoll ist. In der Praxis ist hardwareAcceleration in einer Codec-Konfiguration jedoch nur ein Hinweis, den der Browser ignorieren darf, und die tatsächliche Hardware-Unterstützung variiert je nach Gerät und Betriebssystem. Eine produktive Pipeline muss weiterhin isConfigSupported() prüfen und einen Software-Encode-Fallback bereithalten, statt anzunehmen, dass die Hardwarebeschleunigung einfach da ist.
• Aufzeichnung oder Transcoding im Browser. Einen Stream zu nehmen und ihn vollständig clientseitig in einen anderen Codec oder Container umzucodieren, ist heute auf eine Weise praktikabel, wie es das vor WebCodecs schlicht nicht war – als die Alternative darin bestand, Medien an einen Server zu schicken oder einen WebAssembly-Encoder mitzuliefern.

Browser-Unterstützung und die Vorbehalte aus der Praxis

Die Unterstützung ist über Chromium hinweg stark und ausgereift: Chrome, Edge und Opera bieten vollen Codec-Zugriff seit Chrome 94, inzwischen also seit mehreren Jahren. Firefox hat auf dem Desktop erst später aufgeschlossen, mit voller Unterstützung ab Firefox 130, wobei Firefox für Android es weiterhin nicht implementiert. Safaris Weg dauerte am längsten: Mehrere Jahre lang lieferte Safari nur teilweise, rein videobezogene Unterstützung, volle Parität einschließlich Audio kam erst mit Safari 26. Praktisch heißt das: WebCodecs ist heute eine sichere Wahl für ein Chromium-first- oder Desktop-first-Produkt, aber prüfen Sie vor der Festlegung die aktuellen Kompatibilitätstabellen für Ihre konkreten Zielbrowser und -versionen – besonders, wenn mobiles Firefox oder ältere Safari-Versionen in Ihrer Nutzerbasis vertreten sind.

WebTransport, die Transporthälfte der oben besprochenen Kopplung aus WebCodecs plus WebTransport, brauchte noch länger, um universell zu werden. Es erreichte erst im März 2026 den Baseline-Status, also die Unterstützung über Chrome, Edge, Firefox und Safari hinweg, als Safari 26.4 es schließlich auslieferte. Chromium hat es seit 2022 und Firefox seit 2023. Dieser kombinierte Stack ist also erst seit einigen Monaten breit einsetzbar, nicht seit Jahren – was der Erwägung wert ist, bevor Sie ein Produktivsystem darauf setzen.

Der größere Vorbehalt ist keine Browser-Lücke. Es ist das, was Sie selbst übernehmen, sobald Sie unter WebRTCs Abstraktion sinken. WebRTC gibt Ihnen Verlustwiederherstellung, Synchronisation, Jitter-Buffering und Überlastungssteuerung gratis, über mehr als ein Jahrzehnt Produktiveinsatz hinweg abgestimmt. Greifen Sie stattdessen zu WebCodecs und WebTransport, kommt nichts davon eingebaut mit: Sie besitzen die Bitratenanpassung, die Behandlung von Paketverlust und das Synchronhalten von Audio und Video, weil der Browser diese Entscheidungen bewusst nicht mehr für Sie trifft. WebTransport selbst hat noch keine Entsprechungen zu WebRTCs Algorithmen für Bandbreitenschätzung und adaptive Bitrate, sodass eine ernsthafte eigene Pipeline typischerweise bedeutet, diese Logik zu implementieren oder zu übernehmen, statt anzunehmen, der Transport erledige das. Das ist der ehrliche Kompromiss: mehr systemnahe Kontrolle im Tausch dafür, dass Sie die schwierigen Teile besitzen, die ein gebündelter Stack früher stillschweigend erledigt hat.

Brauchen Sie WebCodecs oder eine Plattform, die das für Sie übernimmt?

Das lohnt sich als echte Build-vs-Embed-Entscheidung zu rahmen, statt anzunehmen, roher Zugriff sei immer die bessere Antwort. WebCodecs verdient seine Komplexität für Teams, die eine wirklich eigene Medien-Pipeline bauen, ein proprietäres Streaming-Protokoll, einen Verarbeitungsschritt, der auf rohen Frames stattfinden muss, oder eine Produktform, in die WebRTC schlicht nicht passt.

Es gibt jedoch einen Mittelweg, den man kennen sollte, bevor man zu WebCodecs greift. Wenn Sie nur Zugriff auf Frame-Ebene innerhalb eines ansonsten gewöhnlichen Videocalls brauchen, etwa Hintergrund-Weichzeichnung oder einen Computer-Vision-Effekt, hat WebRTC bereits einen Weg, das zu tun, ohne den eigenen Transport aufzugeben. Insertable Streams (MediaStreamTrackProcessor und MediaStreamTrackGenerator) und WebRTC Encoded Transform lassen Sie Frames mitten im Call lesen und verändern, während WebRTC weiterhin Überlastungssteuerung, NAT-Traversierung und Synchronisation übernimmt. WebCodecs ist die richtige Wahl, wenn Sie mehr brauchen: eine Pipeline, die ganz außerhalb eines laufenden WebRTC-Calls lebt, einen eigenen Transport oder ein Containerformat, das WebRTC nie erzeugen sollte.

Die meisten Produkte, die einfach nur Standard-Videocalls brauchen, brauchen nichts davon, weil WebRTC (oder ein darauf aufbauendes eingebettetes SDK) Codierung, Transport und Verlustwiederherstellung bereits übernimmt, ohne dass dieser Code ein zweites Mal geschrieben werden muss.

Der Echtzeit-Stack von Digital Samba fällt in genau diese letzte Kategorie: Eine WebRTC-basierte Pipeline mit SFU-Architektur und VP8 als Basis-Codec, plus eingebauter Aufzeichnung und Restreaming, deckt die Standardfälle für Konferenzen und Broadcasting ab, ohne dass ein Team die Codec-Handhabung selbst schreiben muss. Das ist keine Behauptung, dass Digital Samba WebCodecs intern nutzt oder braucht, sondern schlicht die andere Seite der Entscheidung, auf die dieser Artikel hingearbeitet hat: Wissen Sie, in welche Kategorie Ihr Produkt fällt, bevor Sie Ihre Werkzeuge wählen.

Fazit

WebCodecs schaltet rohes Codieren und Decodieren auf Frame-Ebene im Browser frei: echte Power für Teams, die eigene Low-Latency-Streaming- oder Pro-Frame-Verarbeitungs-Pipelines bauen, unnötiges Gewicht für alle, die einfach nur Standard-Videocalls betreiben. Die API-Oberfläche ist klein und klar definiert, und die Browser-Unterstützung ist außerhalb einiger mobiler und veralteter Lücken inzwischen solide – aber die Verantwortung, die mit dem Absinken unter WebRTCs Abstraktion kommt, ist real. Mehr dazu, wie sich das zur Transportebene verhält, in unserem Leitfaden zu Media over QUIC und in unserem Video-Codec-Leitfaden für den Codec-Kontext darunter.

Häufig gestellte Fragen

Was ist die WebCodecs-API?

Es ist eine browserbasierte JavaScript-API, die die im Browser eingebauten Video- und Audio-Encoder und -Decoder direkt offenlegt und Entwicklern Kontrolle auf Frame-Ebene gibt, ohne WebRTC oder das <video>-Element zu durchlaufen.

Wie unterscheidet sich WebCodecs von WebRTC?

WebRTC ist ein vollständiger, gebündelter Echtzeit-Kommunikations-Stack, bei dem Erfassung, Codierung, Transport und Rendering gemeinsam gehandhabt werden. WebCodecs ist nur die Codec-Ebene – Codieren und Decodieren für sich allein – und überlässt Transport und alles andere dem Entwickler.

Wofür werden VideoEncoder und VideoDecoder verwendet?

VideoEncoder wandelt rohe VideoFrame-Objekte in komprimierte EncodedVideoChunk-Objekte um; VideoDecoder macht das Umgekehrte und wandelt codierte Chunks zurück in darstellbare Frames.

Welche Browser unterstützen die WebCodecs-API?

Chrome, Edge und Opera unterstützen sie seit Chrome 94 vollständig. Firefox hat volle Desktop-Unterstützung ab Firefox 130 ergänzt, allerdings noch nicht unter Android. Safaris Unterstützung war mehrere Jahre lang rein videobezogen und erreichte erst mit Safari 26 volle Parität einschließlich Audio.

Funktioniert WebTransport schon in allen Browsern?

Ja, seit März 2026, als Safari 26.4 es auslieferte und WebTransport über Chrome, Edge, Firefox und Safari hinweg den Baseline-Status erreichte. Chromium unterstützt es seit 2022 und Firefox seit 2023, auch unter Android, aber als vollständiger browserübergreifender Stack ist es ein junger Zugang.

Wann sollten Sie WebCodecs statt eines eingebetteten Video-SDK nutzen?

Greifen Sie zu WebCodecs, wenn Sie eine wirklich eigene Medien-Pipeline, einen proprietären Transport, Verarbeitung auf Frame-Ebene oder eine Produktform bauen, in die Standard-Videocalls nicht passen. Die meisten Produkte, die gewöhnliche Videocalls brauchen, sind mit einem eingebetteten SDK, das Codierung und Transport bereits übernimmt, besser bedient.

Lässt sich WebCodecs mit WebTransport für Live-Streaming nutzen?

Ja, die Kopplung von WebCodecs mit WebTransport ist das aufkommende Muster hinter neueren Low-Latency-Streaming-Ansätzen wie Media over QUIC und gibt Entwicklern einen QUIC-basierten Transport gepaart mit direktem Codec-Zugriff statt WebRTCs gebündelter Pipeline.

Quellen

1. Mozilla Developer Network. (o. D.). WebCodecs API.
2. Mozilla Developer Network. (o. D.). Using the WebCodecs API.
3. Mozilla Developer Network. (o. D.). Video processing concepts.
4. Mozilla Developer Network. (o. D.). VideoEncoder.
5. Chrome for Developers. (22. Januar 2025). Video processing with WebCodecs.
6. Can I use. (o. D.). WebCodecs API.
7. TestMu AI. (30. April 2026). WebCodecs: browser support, features, use cases.
8. WebRTC.ventures. (23. April 2026). WebTransport is now Baseline. Here's what that means for real-time media.
9. Fora Soft. (28. Mai 2026). WebTransport and WHIP-over-WebTransport.
10. Fluendo. (1. Juni 2026). WebTransport support in GStreamer.
11. Digital Samba. (22. August 2025). WebRTC explained: how WebRTC works and its applications.
12. Digital Samba. (29. Mai 2026). Media over QUIC (MoQ) explained.
13. Digital Samba. (August 2026). AV1 vs H.264 vs VP9 vs VP8: video codec guide.