Jeder Codec-Vergleich, den du dieses Jahr gelesen hast, hat dir vermutlich gesagt: AV1 ist die Zukunft, H.264 ist Vergangenheit. Falsch ist das nicht – aber die Texte handeln vom Streaming, nicht von Videokonferenzen. Wenn du eine Echtzeit-Video-Plattform baust, bei der Encoding live passiert, jeder Frame zählt und deine Nutzer auf allem von einem Chromebook von 2019 bis zum neuesten iPhone unterwegs sind, hat die Codec-Frage eine völlig andere Antwort.
Du hast wahrscheinlich gelesen, dass AV1 eine 30- bis 50-prozentige Kompressions-Verbesserung gegenüber H.264 liefert. Stimmt – für vorab kodiertes Streaming. Versuch das jetzt in einem Live-Videocall in Echtzeit mit Software auf einem Mittelklasse-Laptop zu kodieren. Das Bild ändert sich deutlich.
In diesem Leitfaden vergleichen wir AV1, H.264, VP9 und VP8 durch die Linse, die für deine Plattform wirklich zählt: Echtzeit-Encoding-Speed, Browser-übergreifende Kompatibilität, SFU-Routing-Komplexität (Selective Forwarding Unit) und was es kostet, das Ganze in Produktion zu betreiben. Wir starten mit VP8, weil es die verpflichtende WebRTC-Baseline ist, und arbeiten uns durch H.264, VP9 und AV1 in der Reihenfolge der Deployment-Reife. Wir erklären auch, warum VP8 – der Codec, den die meisten Artikel als „Legacy" abtun – immer noch in mehr produktiven WebRTC-Deployments läuft, als die meisten Engineers vermuten. Am Ende gibt es ein praktisches Entscheidungs-Framework, das du direkt anwenden kannst.
Inhaltsverzeichnis
Die Codec-Diskussion 2026 wird von Streaming-Engineers dominiert – und das ist ein Teil davon, warum die Ratschläge, die du online findest, oft falsch für Videokonferenz-Plattformen sind.
Bei Video-on-Demand (VOD) und Live-Streaming kodierst du einmal und lieferst das Ergebnis an Tausende oder Millionen Zuschauer aus. Die CPU-Kosten des Encodings sind eine einmalige oder Batch-Investition. AV1s berüchtigt langsame Software-Encoding-Geschwindigkeit ist irrelevant, wenn deine Encoding-Farm offline läuft oder dein Encoder dedizierte AV1-Hardware hat. Die Codec-Entscheidung im Streaming dreht sich primär um Kompressions-Effizienz und Speicherkosten.
Bei Videokonferenz kodierst du in Echtzeit, pro Teilnehmer, kontinuierlich, auf dem Gerät, vor dem der Teilnehmer tatsächlich sitzt. Jede Millisekunde Encoding-Latenz erhöht die Glass-to-Glass-Verzögerung. Ein Codec, der zehnmal langsamer kodiert als eine Alternative, braucht nicht nur mehr CPU; er verschlechtert direkt die Qualität jedes Calls auf jedem Gerät, das nicht mithalten kann.
Dann ist da noch die Codec-Aushandlung. Wenn zwei Browser eine WebRTC-Verbindung aufbauen, tauschen sie einen SDP-Offer (Session Description Protocol) aus, der die unterstützten Codecs jeder Seite listet. Die SFU oder der Peer muss einen Codec wählen, den beide Endpoints unterstützen – nicht den, den du bevorzugst oder der auf deiner Benchmark-Hardware am besten läuft. Wenn User A auf Chrome ist und User B auf Safari, ergibt diese Aushandlung eine reale Einschränkung dessen, was du einsetzen kannst.
So sieht die Browser-übergreifende Realität aus, für die du 2026 designst:
Für eine Konferenz-Plattform, die Nutzer über all diese Umgebungen hinweg bedient, gibt es keine einzelne richtige Antwort. Die richtige Antwort ist eine ausgehandelte Mischung – und die reale Position jedes Codecs zu verstehen, ist der Weg, das intelligent aufzusetzen.
VP8 wurde 2010 von Google veröffentlicht und durch das WebM-Projekt open-sourced. Ursprünglich als lizenzfreie Alternative zu H.264 designt, wurde er zum ersten verpflichtenden Video-Codec in der WebRTC-Spezifikation – das heißt, er ist immer noch die Baseline, die jede konforme WebRTC-Implementierung unterstützen muss.
Diese Geschichte ist der Grund, warum VP8 2026 in produktiven Deployments lebendig und aktiv ist. Nicht weil niemand es besser wüsste, sondern weil es zuverlässig überall funktioniert. Tsahi Levent-Levi, eine der führenden Autoritäten zu WebRTC-Architektur, formuliert es direkt: „VP8 funktioniert einfach." In seinen WebRTC-Vorhersagen vom Januar 2026 empfiehlt er explizit Anbietern, die mit AV1-Implementierungen kämpfen, auf VP8 zurückzugehen, zu stabilisieren und von dort experimentell nach oben zu arbeiten.
Im Vergleich zu H.264 geht es bei VP8 weniger um Qualität als darum, wo jeder Codec in deiner Infrastruktur passt. VP8s praktische Vorteile im Konferenz-Kontext:
Wann du bei VP8 bleibst:
Codecs zu wechseln kostet echte Engineering-Zeit, also stell sicher, dass der Gewinn den Aufwand rechtfertigt, bevor du startest.
H.264 (auch bekannt als AVC, Advanced Video Coding) ist der meistverbreitete Video-Codec der Geschichte. Standardisiert von ITU-T und ISO/IEC, war er der Codec, der HD-Video über das Internet praktikabel machte – und er geht so schnell nicht weg.
Speziell für Videokonferenz hat H.264 ein Attribut, das ihn für die meisten Plattform-Teams unverhandelbar macht: er ist Safaris bevorzugter WebRTC-Video-Codec, und Hardware-Encoding-Support für H.264 existiert auf praktisch jedem Gerät, das in den letzten zehn Jahren hergestellt wurde. Wenn deine Nutzer Apple-Geräte einschließen – und das tun sie fast sicher – brauchst du H.264-Support.
VP9 ist Googles Nachfolger von VP8, veröffentlicht 2013, lizenzfrei, und von YouTube für den Großteil der Desktop-Wiedergabe auf Chrome und Firefox verwendet. Auf dem Papier ist VP9 eine starke Wahl für Videokonferenz: bessere Kompression als VP8 bei gleicher visueller Qualität, was 1080p auf rund 2.400 bis 3.200 kbps drückt – gegenüber VP8s 4.500 bis 6.000 kbps.
Diese Bandbreiten-Ersparnis ist real und bedeutsam, besonders für Plattformen mit Nutzern auf variablen Mobil-Verbindungen oder in Märkten mit hohen Datenkosten.
Die Herausforderung mit VP9 ist die Encoding-Geschwindigkeit – wenn auch in einer etwas weniger extremen Form als bei AV1. Software-VP9-Encoding ist deutlich langsamer als H.264 bei vergleichbaren Qualitätsstufen. Bei mittleren Qualitätspresets in libvpx ist diese Lücke groß genug, um Echtzeit-Software-VP9-Encoding auf den meisten Geräten ohne GPU-Beschleunigung unpraktisch zu machen.
Das trifft am härtesten, wenn man mobile Geräte einrechnet. Hardware-VP9-Dekodierung ist verbreitet (Android hat seit 4.4 KitKat Software-VP9-Decode, Hardware-Decode folgte auf SoCs ab etwa 2016), aber Hardware-VP9-Encoding ist auf Mobil-Hardware deutlich seltener verfügbar. Das heißt: clientseitiges VP9-Encoding in WebRTC fällt oft auf langsames Software-Encoding zurück, was die CPU hochjagt und den Akku leert.
AV1 ist der Codec, der von der Alliance for Open Media (AOMedia) entwickelt wurde – eine Koalition aus Google, Netflix, Amazon, Microsoft, Intel, Mozilla und Cisco, der Apple im Januar 2018 kurz vor Finalisierung der Spec beigetreten ist. Die Bitstream-Spezifikation wurde im März 2018 veröffentlicht. Die Kompressions-Effizienz ist genuin beeindruckend: rund 30 bis 50 Prozent besser als VP9 und 50 bis 60 Prozent besser als H.264 bei äquivalenter visueller Qualität – das bringt 1080p auf etwa 1.800 bis 2.200 kbps.
AV1 wurde designt, um unter der Patentlizenz von AOMedia lizenzfrei zu sein. In der Praxis bindet diese Lizenzfreiheit aber nur AOMedia-Mitglieder. Patenthalter, die AOMedia nicht beitraten, können jedes Patent geltend machen, das sie für relevant für AV1 halten. Stand März 2026 ist das ein aktives Thema: Dolby reichte Patentverletzungs-Klagen gegen Snap Inc. in den USA und Brasilien wegen dessen AV1-Einsatz ein, und InterDigital, Nokia und Sisvel (das einen Pool von über 1.500 relevanten Patenten beansprucht) haben alle IP-Rechte zu AV1-Implementierungen geltend gemacht. WebRTC.ventures hat das im April 2026 ausdrücklich als bedeutsames Beschaffungs-Risiko markiert. Praktische Position für ein Plattform-Team heute: AV1s lizenzfreier Status spiegelt AOMedias interne Verpflichtung wider – aber Nicht-Mitglieder klagen aktiv. Kläre das mit einem Anwalt, bevor du AV1 kommerziell ausrollst.
Fürs Streaming und VOD hat AV1 unabhängig von diesen Komplikationen bereits gewonnen. YouTube, Netflix und die meisten großen Streaming-Plattformen verwenden AV1 für einen erheblichen Teil ihres Traffics. Die Frage für diesen Artikel ist, ob diese Vorteile sich auf Echtzeit-Videokonferenz übertragen – und die ehrliche Antwort 2026 lautet: nicht für die meisten Plattformen.
Browser-Support für AV1:
Tsahi Levent-Levis Einschätzung, aus seiner Session vom Dezember 2025 mit WebRTC.ventures, ist die klarste öffentliche Aussage zum Stand von AV1 für Konferenz: „AV1 wird 2026 nicht der dominante Codec sein und braucht möglicherweise bis etwa 2028, um diesen Status zu erreichen, während VP8 und H.264 stark bleiben." Sein Blogbeitrag vom Januar 2026 ergänzt, dass viele Anbieter Codec-Implementierungen als belastend für Geräte-Ressourcen empfinden könnten.
Wann AV1 heute Sinn ergibt: für Aufzeichnungs- und VOD-Transcoding-Pipelines, in denen die Encoding-Kosten einmalig anfallen; für kontrollierte Enterprise-Umgebungen, in denen du verifizieren kannst, dass alle Endpoints AV1-Hardware-Encoder haben; für Bildschirmfreigabe auf unterstützten Geräten, wo AV1s content-adaptive Tools glänzen; und für bandbreiten-eingeschränkte Szenarien, in denen das Gerät bestätigten AV1-Hardware-Support hat und die Bandbreiten-Ersparnis die Implementierungs-Komplexität rechtfertigt.
Der Vergleich AV1 vs. H.264 sieht sehr anders aus, wenn du auf Echtzeit-Einschränkungen statt Streaming-Benchmarks fokussierst.
| VP8 | H.264 | VP9 | AV1 | |
|---|---|---|---|---|
| Erscheinungsjahr | 2010 | 2003 | 2013 | 2018 |
| Lizenz | Lizenzfrei | Patent-lizenziert (Via Licensing Alliance) | Lizenzfrei | Lizenzfrei (nur AOMedia-Mitglieder; durch Nicht-Mitglieder beklagt) |
| RT-Encoding-Speed | Sehr schnell | Schnell | Langsam (SW) | Sehr langsam (SW) |
| HW-Encoder-Verfügbarkeit | Selten | Universell | Auf Mobil begrenzt | Nur Desktop/M5+ |
| Kompressions-Effizienz | Am niedrigsten | Mittel | Gut | Am besten |
| Ungefähre 1080p-Bitrate (gute Qualität) | 4.500–6.000 kbps | 4.000–5.000 kbps | 2.400–3.200 kbps | 1.800–2.200 kbps |
| Chrome-Support | Voll | Voll | Voll | HW-abhängig |
| Firefox-Support | Voll | Voll | Voll | Begrenzter RT-Encode |
| Safari/iOS-Support | Voll (WebRTC) | Voll (bevorzugt) | Nur Decode | Experimentell (neue HW) |
| SFU-Komplexität | Niedrig | Niedrig | Mittel | Hoch |
| Am besten für Konferenz | Maximale Kompatibilität | Apple-Nutzer / Fallback | Bandbreiten-Ersparnis | Aufzeichnung / Zukunft |
| Produktions-WebRTC-Status | Weit verbreitet | Weit verbreitet | Teilweise adoptiert | Experimentell / aufkommend |
Bevor wir uns ansehen, wie diese Codecs in einer echten SFU interagieren, lohnt es, die Codecs zu behandeln, die in Vergleichsartikeln regelmäßig auftauchen, aber heute nicht praktikabel als dein primärer Konferenz-Codec dienen können.
H.265 (HEVC, High Efficiency Video Coding): hervorragende Kompression, vergleichbar mit VP9 und besser als H.264, mit ausgereiftem Hardware-Encoder-Support. Die Patent-Lizenzierungs-Situation ist fragmentiert: drei separate Patent-Pools (MPEG LA via Via Licensing Alliance, HEVC Advance und Velos Media) beanspruchen jeweils Lizenzgebühren, was ein erhebliches kommerzielles Risiko ist und H.265 historisch aus Chrome und Firefox heraushielt. Chrome 136 (Mitte 2025) fügte H.265-WebRTC-Support standardmäßig auf Windows, macOS und Android hinzu, abhängig von Hardware-Verfügbarkeit, sodass H.265 für WebRTC nicht mehr nur eine Safari-Geschichte ist. Firefox unterstützt H.265 in WebRTC allerdings weiterhin nicht. Die Schlussfolgerung für die meisten Teams bleibt: der fragmentierte Patent-Pool bleibt eine reale Hürde, und das Fehlen von Firefox-Support macht H.265 für allgemeine Cross-Plattform-Konferenz unpraktisch. Apples Vision Pro verwendet H.265 für Spatial Video, was seine Relevanz in Apple-spezifischen Enterprise-Kontexten erweitern könnte.
H.266 (VVC, Versatile Video Coding): bietet in manchen Benchmarks noch bessere Kompression als AV1 und hat eine noch kompliziertere Patent-Situation als HEVC. Null Browser-Support für WebRTC. Nicht relevant für Videokonferenz-Plattformen 2026 oder in absehbarer Zukunft. (Das ist auch der Codec, den Qualcomm laut eigener Aussage für künftiges Mobil-Hardware-Encoding anvisieren will – statt AV1.)
AV2: der von der Alliance for Open Media geplante Nachfolger von AV1, designt, um AV1s Kompression bei Beibehaltung lizenzfreier Lizenzierung zu verbessern. 2026 noch in früher Spec-Entwicklung. Keine Produktions-Zeitlinie. Frühestens 2028 bis 2029 zu erwarten.
LCEVC (Low Complexity Enhancement Video Coding): ein MPEG-Standard, der als Enhancement-Layer auf einem bestehenden Basis-Codec arbeitet – sei es VP8, H.264, VP9 oder AV1. Er beansprucht rund 40 Prozent Kompressions-Verbesserung für jeden Basis-Codec bei geringer zusätzlicher Encoding-Komplexität. Das ist ein interessanter architektonischer Ansatz, weil er das „auf welchen Codec wechseln"-Problem umgeht und Effizienz auf bestehenden Codecs verbessert, ohne sie zu ersetzen. Für WebRTC-Adoption noch in einem frühen Stadium, aber als Pfad zu besserer Kompression ohne Aufgabe der H.264- oder VP8-Infrastruktur einen Blick wert.
Einzelne Codec-Eigenschaften erzählen nur einen Teil der Geschichte. Wie sie in einer Multi-Teilnehmer-SFU-basierten Konferenz-Architektur interagieren, ist der Ort, an dem die echte Engineering-Komplexität lebt.
Manche Plattformen absorbieren diese Komplexität, um Per-Codec-Effizienz-Gewinne zu jagen. Andere, einschließlich Digital Samba, nehmen die gegenteilige Sicht ein: wähle den einen Codec, der in jedem Browser ohne serverseitiges Transcoding oder Mid-Session-Renegotiation zuverlässig funktioniert, und investiere Engineering-Aufwand in Call-Qualität, KI-Features und Verlässlichkeit. Beides sind legitime Produktions-Entscheidungen. Die richtige Antwort hängt davon ab, ob dein Engpass Bandbreite oder Engineering-Kapazität ist.
Der beste Codec für Videokonferenz ist der, der akzeptable Qualität über alle Browser und Geräte liefert, die deine Nutzer tatsächlich haben – nicht der, der Benchmarks auf Referenz-Hardware gewinnt.
Digital Samba fährt einen bewussten VP8-only-Echtzeit-Stack. Safari unterstützt VP8 für WebRTC seit Safari 12.1 (2019), Chrome, Firefox und Edge unterstützen ihn nativ – und dieser einzelne Codec deckt jede Browser-Kombination ab, der Digital-Samba-Sessions tatsächlich begegnen. Die Begründung:
Schritt 1: Prüfe deine Nutzerbasis – aber nimm nicht an, dass Apple-Nutzer dich auf H.264 zwingen. Safari unterstützt VP8 für WebRTC seit 2019, also funktioniert ein VP8-only-Stack über Chrome, Firefox, Edge und Safari ohne serverseitiges Transcoding. H.264 ergänzend hinzuzufügen lohnt, wenn du dich mit Safaris bevorzugtem Codec für marginale Qualitätsgewinne ausrichten willst, oder wenn du speziell Hardware-H.264-Encoder auf Apple Silicon arbeiten lassen willst. Es ist ein Trade-off gegen Engineering-Komplexität, keine harte Anforderung.
Schritt 2: Bewerte deinen aktuellen Codec. Fährst du VP8 und die Qualität ist für deine Nutzer akzeptabel? Wechsel nicht, nur weil ein Blog dir gesagt hat, AV1 sei besser. Wechsel kostet echten Engineering-Aufwand: Migration, Testen über Gerät- und Browser-Kombinationen, potenzielles Regressions-Handling. Investiere diesen Aufwand dort, wo er für Nutzer sichtbaren Wert schafft.
Schritt 3: Bewerte Bandbreiten-Einschränkungen. Zahlst du signifikante CDN- oder Bandbreiten-Kosten? Erwäge VP9 für Aufzeichnungs-/VOD-Pipelines, in denen die Encode-once-Kosten durch Kompressions-Ersparnis bei Skala gerechtfertigt sind. Erwäge AV1 für Archiv-Transcoding, in dem du Langzeit-Speicherkosten optimierst.
Schritt 4: Prüfe die Ziel-Geräte-Hardware. Kannst du verifizieren, dass ein relevanter Anteil deiner Endpoints AV1-Hardware-Encoder hat? Falls ja, und du hast die Engineering-Ressourcen, ist ein AV1-Pilot in einem kontrollierten Rollout heute den Aufwand wert. Falls deine Nutzer auf allgemeiner Consumer- oder Mobil-Hardware sind, warte. Software-AV1-Encoding wird mehr schaden als helfen.
Schritt 5: Beobachte die Hardware-Zeitlinie. AV1-Hardware-Encoding wird auf PC- und Apple-Hardware vermutlich um 2027 bis 2028 zum Standard. Da kippt die Mathematik für Echtzeit-Videokonferenz auf diesen Plattformen. Für Android-lastige Nutzerbasen ist das Bild weniger sicher angesichts Qualcomms erklärter Absicht, AV1-Encoding zu überspringen. Setz dir einen Checkpoint, um die AV1-Entscheidung zu diesem Zeitpunkt neu zu betrachten, und faktorisiere deinen Geräte-Mix ein, wenn du das tust.
Ein Hinweis zu LCEVC: wenn du deutlich bessere Kompression ohne Wechsel deines Basis-Codecs willst, behalte LCEVC als alternativen Pfad im Auge. Es ist 2026 nicht produktionsreif für WebRTC, könnte aber ein praktischer Upgrade-Weg für Plattformen sein, die noch nicht bereit sind, zu VP9 oder AV1 zu migrieren.
Ja, breit. VP8 ist der verpflichtende Baseline-Codec in der WebRTC-Spezifikation – das heißt, jede konforme WebRTC-Implementierung unterstützt ihn. Janus, mediasoup, Kurento und viele weit verbreitete SFUs handhaben VP8 standardmäßig. Tsahi Levent-Levi, dessen BlogGeek.me eine der meistzitierten Autoritäten zu WebRTC-Architektur ist, empfiehlt in seinen 2026er Vorhersagen, dass Anbieter, die mit neueren Codecs kämpfen, auf VP8 stabilisieren sollten, bevor sie mit VP9 oder AV1 experimentieren. VP8 ist kein Failure-Mode – es ist eine zuverlässige Produktions-Baseline, von der viele Plattformen keinen starken Grund zum Wechsel hatten.
Die glaubwürdigste aktuelle Schätzung ist etwa 2028, nicht 2026. Tsahi Levent-Levi machte diese spezifische Aussage in seiner Dezember-2025-Session mit WebRTC.ventures: „Wenn AV1 dominant wird, dann vermutlich um 2028, nicht 2026." Die Einschränkung ist die Hardware-Encoder-Verfügbarkeit auf der Client-Seite, besonders mobil. Bis AV1-Hardware-Encoder auf Mid-Range-Smartphones Standard sind, heißt AV1-Encoding in Echtzeit-Konferenz-Sessions Software-Encoding – zu CPU-intensiv, um in Skala tragbar zu sein. Die Hardware-Trajektorie deutet auf Lösung dieser Einschränkung im Zeitrahmen 2027 bis 2028 für Apple- und PC-Plattformen, obwohl Qualcomms Entscheidung, AV1-Encoding auf Snapdragon zu überspringen, die Android-Mid-Range-Zeitlinie unsicherer macht.
AV1 ist der klare Sieger für Kompressions-Effizienz – mit ungefähr 1.800 bis 2.200 kbps für 1080p-äquivalente Qualität, gegenüber 4.000 bis 5.000 kbps für H.264 und 4.500 bis 6.000 kbps für VP8. VP9 ist eine starke Mittel-Option bei 2.400 bis 3.200 kbps. „Am besten bei niedriger Bandbreite" in einem Echtzeit-Konferenz-Kontext hängt aber auch davon ab, ob das sendende Gerät den Codec überhaupt kodieren kann. Wenn der Endpoint AV1 nicht hardware-encodieren kann, erzeugt der CPU-Overhead des Software-AV1-Encodings schlechtere Call-Qualität als VP8 bei höherer Bitrate – weil Frame-Drops und Encoding-Lag die Erfahrung mehr verschlechtern als Bitrate.
Nicht zwingend. Ein Multi-Codec-Stack lässt dich pro Browser optimieren, heißt aber auch Codec-Fallback-Pfade pflegen, Mid-Session-Renegotiation handhaben, wenn ein Teilnehmer auf einem anderen Browser beitritt, und jeden Codec über die volle Geräte-Matrix testen. Manche Plattformen akzeptieren diesen Overhead im Tausch gegen Per-Codec-Effizienz-Gewinne. Andere bleiben absichtlich Single-Codec. Digital Samba etwa fährt nur VP8, weil VP8 auf jedem WebRTC-Browser (Safari seit 2019 inklusive) funktioniert und die gesparte Engineering-Kapazität für Codec-Fallback-Funktionalität in Call-Verlässlichkeit und KI-Features fließt. Wenn du spezifische Bandbreiten- oder Qualitätsgründe für VP9 oder H.264 hast, ergänze sie. Wenn nicht, ist Single-Codec-VP8 2026 eine verteidigbare Produktions-Entscheidung, kein Kompromiss.
LCEVC (Low Complexity Enhancement Video Coding) ist ein MPEG-Standard, der als Enhancement-Layer auf bestehenden Basis-Codecs arbeitet. Statt VP8, H.264 oder VP9 zu ersetzen, fügt er einen zusätzlichen Encoding-Pass hinzu, der rund 40 Prozent Kompressions-Verbesserung auf jedem unterstützten Basis-Codec bei relativ niedriger zusätzlicher Encoding-Komplexität beansprucht. Der architektonische Reiz ist groß: du bekommst sinnvolle Kompressions-Verbesserungen ohne Änderung deiner Basis-Codec-Infrastruktur – das umgeht die Kompatibilitäts- und Aushandlungs-Komplexität der Einführung eines neuen Codecs. LCEVC ist 2026 noch in einem frühen Stadium für WebRTC-Deployment, nimmt aber einen genuin anderen Winkel auf das Codec-Verbesserungs-Problem. Wenn die Toolchain reift und Browser-Support kommt, könnte er ein praktischer Pfad zu besserer Kompression sein für Plattformen, die noch nicht bereit sind, zu VP9 oder AV1 zu migrieren.
Codec-Wahl ist primär technisch, hat aber zwei DACH-relevante Querbezüge: erstens die laufende Patent-Litigation um AV1 (Dolby, Nokia, InterDigital, Sisvel) – ein Anwalts-Check ist vor kommerziellem AV1-Rollout in der EU dringend empfohlen. Zweitens, wenn deine Videokonferenz-Plattform unter DORA (Finanzinstitute, seit Januar 2025) oder NIS2 (in Deutschland: NIS2UmsuCG seit Dezember 2025) fällt, ist Codec-Stabilität Teil der IKT-Risikomanagement-Anforderung: ein Codec, der mid-call abstürzt oder Renegotiation auslöst, ist ein dokumentierbares Verfügbarkeits-Risiko.
Der Codec, den du 2026 einsetzen solltest, hängt fast vollständig von den Geräten und Browsern ab, die deine Nutzer haben – nicht davon, welcher Codec den neuesten Kompressions-Benchmark gewinnt.
Fährst du VP8 und deine Nutzer sind mit der Qualität zufrieden? Das ist eine legitime Produktions-Entscheidung, die Millionen Sessions täglich validieren. Hast du signifikante Bandbreiten-Kosten oder eine Chrome-zentrierte Nutzerbasis? VP9 für Aufzeichnung und High-Quality-Connections ist der praktische nächste Schritt. Hast du Apple-Nutzer, gibt es zwei legitime Pfade: H.264 ergänzen, um Safaris bevorzugten Codec für marginale Qualitätsgewinne zu treffen – oder auf VP8 bleiben (das Safari seit 2019 unterstützt) und den Engineering-Aufwand sparen, den Codec-Fallback-Funktionalität sonst verbrauchen würde. Und wenn du für 2027 bis 2028 planst – den Zeitpunkt, zu dem Tsahi Levent-Levi und die breitere WebRTC-Community AV1-Hardware-Encoding auf PC- und Apple-Plattformen als Mainstream erwarten –, ist jetzt die Zeit, AV1 in kontrollierten Umgebungen zu evaluieren. Behalte dabei die Patent-Litigation im Auge: AV1s lizenzfreier Status wird derzeit vor Gericht geprüft, und das ist vor Festlegung ein Gespräch mit einem Anwalt wert.
Der beste Codec für Videokonferenz ist nicht ein Codec. Er ist ein ausgehandelter Stack, und die Trade-offs jeder Option zu verstehen, ist der Weg, eine Plattform zu bauen, die für jeden Nutzer funktioniert, den du tatsächlich hast.
Wie Digital Samba Cross-Plattform-Video-Qualität handhabt: digitalsamba.com/de/features
Erkunde die DS-Architektur im Detail: docs.digitalsamba.com/reference