Video-Codecs für Echtzeit-Konferenz 2026

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

1. Warum die Codec-Wahl bei Videokonferenz wichtiger ist als beim Streaming
2. VP8: der Codec, der sich nicht in den Ruhestand schicken lässt
3. H.264: der universelle Standard (mit Bedingungen)
4. VP9: bessere Kompression, immer noch unter-adoptiert
5. AV1: die Zukunft, die für Echtzeit noch nicht ganz bereit ist
6. Die Vergleichstabelle
7. Was ist mit H.265, H.266 und AV2?
8. Wie das in einer echten Videokonferenz-SFU aussieht
9. Was Digital Samba einsetzt und warum
10. Ein praktisches Entscheidungs-Framework für deine Plattform
11. FAQ

Warum die Codec-Wahl bei Videokonferenz wichtiger ist als beim Streaming

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:

• Safari und iOS: bevorzugen H.264. AV1-Support ist noch experimentell und hardware-abhängig. Jeder iOS-Browser (Chrome auf iOS, Firefox auf iOS, Edge auf iOS) ist gezwungen, WebKit zu verwenden, das die Codec-Beschränkungen von Safari erbt.
• Chrome und Edge: unterstützen VP8, VP9, H.264 und AV1. VP8 bleibt häufige Standard-Wahl in WebRTC-Implementierungen; AV1-Verfügbarkeit hängt von der Geräte-Hardware ab.
• Firefox: unterstützt VP8, VP9 und H.264. AV1-Dekodierung ist vorhanden, aber hardware-gebunden.
• Android: VP8 Software-Dekodierung seit Android 2.3; VP9 Software-Dekodierung seit Android 4.4 KitKat. AV1-Hardware-Dekodierung auf Android 10 und später, aber nur auf Geräten mit passendem Hardware-Decoder.

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: der Codec, der sich nicht in den Ruhestand schicken lässt

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:

• Encoding-Geschwindigkeit: VP8 ist schnell. Software-Encoding von 720p-Video in Echtzeit ist auf bescheidener Hardware ohne dedizierte Encoding-Beschleunigung machbar. Das zählt enorm für Mobile-Clients und Budget-Geräte.
• CPU-Vorhersagbarkeit: VP8s Encoding-Komplexität ist niedrig und vorhersagbar. Du wirst keine CPU-Spitzen sehen, die mitten im Call zu Frame-Drops führen.
• Universeller Support: VP8 wird in Chrome, Firefox, Edge und Safari (seit Safari 12.1 für WebRTC) unterstützt. Es ist der einzige Codec, den du verlässlich über praktisch jede Browser-Kombination einsetzen kannst, ohne serverseitiges Transcoding.
• Kompressions-Effizienz: Das ist VP8s Schwäche. Gute 1080p-Qualität braucht ungefähr 4.500 bis 6.000 kbps. Das ist deutlich höhere Bandbreite als VP9 oder AV1 für äquivalente Qualität brauchen. Auf eingeschränkten Verbindungen oder mobilen Datentarifen werden VP8s Bitrate-Anforderungen zum echten Problem.

Wann du bei VP8 bleibst:

• wenn deine Nutzerbasis ältere Mobilgeräte enthält,
• wenn das CPU-Budget auf Client-Geräten knapp ist,
• wenn du maximale Cross-Plattform-Kompatibilität ohne serverseitiges Transcoding brauchst,
• wenn deine Plattform VP8 bereits zuverlässig fährt und die Qualität für deinen Use Case akzeptabel ist.

Codecs zu wechseln kostet echte Engineering-Zeit, also stell sicher, dass der Gewinn den Aufwand rechtfertigt, bevor du startest.

H.264: der universelle Standard (mit Bedingungen)

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.

• Encoding-Geschwindigkeit: schnell, gut optimiert, mit hervorragender Hardware-Beschleunigung auf praktisch jedem Gerät. Intel, AMD, NVIDIA, Qualcomm, Apple Silicon und Exynos haben alle ausgereifte H.264-Hardware-Encoder. Das heißt: Echtzeit-Encoding bei 1080p ist auf Mobilgeräten ohne signifikanten Akku-Drain machbar.
• Kompressions-Effizienz: H.264 liefert gute Qualität bei rund 4.000 bis 5.000 kbps für 1080p. Das ist deutlich besser als VP8 im selben Szenario, aber signifikant hinter VP9 und AV1. Für Videokonferenz bei typischen 720p-Auflösungen ist H.264 in der Regel ausreichend.
• Lizenzierung: H.264 ist nicht Open Source. Er ist durch Patente abgedeckt, jetzt verwaltet durch die Via Licensing Alliance (vormals MPEG LA), und der Einsatz in kommerziellen Produkten erfordert technisch eine Lizenz. Für Browser-basierte WebRTC-Plattformen wird das weitgehend von den Browser-Anbietern übernommen, die ihre eigenen H.264-Lizenzen haben. Wenn du eigenes serverseitiges H.264-Encoding machst – etwa in einer Aufzeichnungs- oder Transcoding-Pipeline – bist du außerhalb der Browser-Lizenz und solltest deine Verpflichtungen mit einem Anwalt prüfen.
• Der Interoperabilitäts-Fall: wenn du unsicher bist, welchen Codec zwei Endpoints teilen, ist H.264 der gemeinsame Nenner. Chrome, Firefox, Edge und Safari unterstützen ihn alle. Android und iOS unterstützen ihn alle mit Hardware-Beschleunigung. Für Plattform-Teams, die einen einzelnen Codec brauchen, der unter allen Umständen funktioniert, ist H.264 die pragmatische Antwort – und keine peinliche.

VP9: bessere Kompression, immer noch unter-adoptiert

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.

• Browser-Support: Chrome, Firefox und Edge nativ. Safari fügte VP9-Dekodierung in macOS Big Sur und iOS 14 (Safari 14 und später) hinzu, aber VP9 ist nicht Safaris bevorzugter WebRTC-Codec, und Encoding-Support auf Safari/iOS bleibt begrenzt und inkonsistent. Das erzeugt denselben Transcoding-Druck am Server, den VP8 vermeidet.
• Das Adoptions-Puzzle ist real: VP9 ist seit Jahren verfügbar, bietet klare Kompressions-Vorteile und ist lizenzfrei. Doch viele WebRTC-Plattformen haben es nicht vollständig adoptiert. Wie Tsahi Levent-Levi anmerkt, ist diese Zurückhaltung ein nützliches Signal für AV1. Wenn die Industrie nach über einem Jahrzehnt nicht vollständig auf VP9 umgezogen ist, ist die Erwartung, AV1 dominiere bis 2026, nicht realistisch.
• Wann VP9 Sinn ergibt: für kontrollierte Umgebungen, in denen du weißt, dass beide Endpoints auf Chrome oder Firefox mit Hardware-Beschleunigung laufen; für Aufzeichnungs-Pipelines (einmal encodieren, Kompressions-Ersparnisse bei der Wiedergabe nutzen); oder für Plattformen, die gezielt Desktop-Nutzer ansprechen, wo du mehr Vertrauen in CPU-Headroom hast.

AV1: die Zukunft, die für Echtzeit noch nicht ganz bereit ist

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.

• Das Encoding-Geschwindigkeits-Problem: Software-AV1-Encoding ist 5 bis 10 Mal langsamer als VP9 und kann mehrere CPU-Kerne während aktiver Kodierung auf Desktop-Hardware sättigen. Für Live-Videocalls, bei denen Encoding pro Teilnehmer pro Frame in Echtzeit passiert, macht das Software-AV1-Encoding auf den meisten aktuellen Geräten ohne dedizierte AV1-Silizium-Beschleunigung unpraktisch.
• Hardware-AV1-Encoder-Verfügbarkeit 2026: die Situation verbessert sich, ist aber uneinheitlich. Desktop- und Laptop-Hardware mit AV1-Hardware-Encodern umfasst Intel Arc Discrete-GPUs (Hinweis: 12.-Gen-Alder-Lake-iGPUs unterstützen AV1-Dekodierung nur; Hardware-Encoding ist spezifisch für Arc-Discrete-GPUs und 14.-Gen-Core-Ultra-iGPUs), AMD RDNA 3 und später (RX-7000-Serie), NVIDIA RTX-40-Serie (Ada Lovelace) und Apple M5 Pro und M5 Max (veröffentlicht März 2026; frühere Apple-Silicon-Generationen einschließlich M1, M2, M3 und M4 haben nur AV1-Hardware-Dekodierung). Das deckt einen relevanten Anteil aktueller Enthusiasten-Hardware ab – aber nicht die allgemeine Consumer-Geräte-Population, und im Wesentlichen kein Mobil-Bereich.
• Mobile AV1-Hardware-Encoding ist die kritische Lücke. Der Samsung Exynos 2200 hat AV1-Hardware-Dekodierung hinzugefügt, aber Hardware-Encoding-Support auf Snapdragon und anderen mobilen SoCs bleibt begrenzt. Bemerkenswert: Qualcomm hat öffentlich erklärt, AV1-Hardware-Encoding gar nicht in Snapdragon zu planen, sondern direkt auf VVC (Versatile Video Coding) zu wechseln, sobald das bereit ist. Angesichts Snapdragons Anteil an Android-Flagschiffen und Mid-Range-Geräten macht das die oft zitierte 2027-bis-2028-Zeitlinie für ubiquitäres mobiles AV1-Encoding eine vernünftige Vorhersage für Apple- und PC-Hardware, aber deutlich unsicherer für Android. Die Realität für die meisten Smartphone-Nutzer 2026: AV1-Echtzeit-Encoding heißt Software-Encoding, was für anhaltende Videocalls nicht tragbar ist.

Browser-Support für AV1:

• Chrome (Desktop und Android mit Hardware): AV1-Decode seit Chrome 70; Hardware-Encode auf kompatiblen Chips
• Firefox: AV1-Decode; begrenzter Echtzeit-Encode-Support
• Edge: matches Chrome über Chromium
• Safari: AV1-Decode auf Apple-Silicon-M3-Macs und später, sowie iPhone 15 Pro und später. Ältere Apple-Geräte haben überhaupt keinen AV1-Support. AV1-WebRTC-Encoding in Safari ist immer noch als experimentell markiert.

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.

Die Vergleichstabelle

Der Vergleich AV1 vs. H.264 sieht sehr anders aus, wenn du auf Echtzeit-Einschränkungen statt Streaming-Benchmarks fokussierst.

Was ist mit H.265, H.266 und AV2?

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.

Wie das in einer echten Videokonferenz-SFU aussieht

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.

• Codec-Aushandlung in WebRTC: wenn ein Browser eine WebRTC-Verbindung aufbaut, schickt er einen SDP-Offer mit seinen unterstützten Codecs in Präferenz-Reihenfolge. Die SFU oder der Peer wählt den höchstpriorisierten Codec, den beide Seiten unterstützen. Du wählst nicht den Codec, den du willst – du bekommst den Codec, den die Aushandlung produziert. Das bedeutet: das Cross-Browser-Problem ist keine theoretische Sorge. Es ist, was deine SFU bei jedem Call handhabt.
• Das Chrome-und-Safari-Problem: ein User auf Chrome (das VP8 oder VP9 für WebRTC bevorzugt) und ein User auf Safari (das H.264 bevorzugt), die derselben Session beitreten, erzeugen einen Aushandlungs-Mismatch. Ohne serverseitiges Transcoding – was Latenz, Kosten und Komplexität ergänzt – muss die SFU entweder zum kleinsten gemeinsamen Nenner routen (H.264, den beide unterstützen) oder selektiv für spezifische Teilnehmer transcodieren. Die meisten produktiven SFUs handhaben das, indem sie H.264 als universellen Fallback unterstützen.
• Simulcast und Codec-Interaktion: Simulcast – ein Client schickt mehrere Auflösungs-Layer desselben Streams – ist codec-abhängig. VP8 und VP9 unterstützen temporale Skalierbarkeits-Layer. H.264 hat SVC-Erweiterungen, die in Browsern nicht breit implementiert sind. AV1 hat nativen SVC-Support über alle drei Dimensionen (spatial, temporal, qualitativ), was auf dem Papier gut aussieht – aber nur auf Geräten, die sich die AV1-Encoding-Kosten leisten können.
• Die Routing-Architektur: Digital Sambas SFU, basierend auf Janus, routet verschlüsselte Medien-Streams direkt zwischen Teilnehmern, ohne im Medien-Pfad zu dekodieren oder zu mischen. Das hält die Latenz niedrig und die Architektur sauber. Der Trade-off: jeder zusätzliche Codec, den deine SFU unterstützt, ergänzt operative Kosten – Codec-Fallback-Pfade, Renegotiation, wenn ein Teilnehmer mitten im Call auf einem anderen Browser beitritt, und Engineering-Zeit, jede Kombination über die Geräte-Matrix zu testen und zu pflegen.

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.

Was Digital Samba einsetzt und warum

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:

• VP8 ist nicht Legacy – er ist Produktion: VP8 läuft über einen erheblichen Anteil von Digital-Samba-Sessions. Er liefert zuverlässige Qualität, konsistentes Encoding-Verhalten über Gerätetypen hinweg und funktioniert in jeder Browser-Kombination ohne serverseitiges Transcoding. Die Performance ist in Benchmark-Vergleichen nicht glamourös, aber vorhersagbar – und Vorhersagbarkeit zählt in Produktion.
• VP8 funktioniert auf jedem Browser, einschließlich Safari: Safari fügte VP8-Support für WebRTC 2019 hinzu, und jedes seither ausgelieferte Apple-Gerät handhabt VP8 in Echtzeit-Sessions ohne Fallback. Auf VP8 über die gesamte Nutzerbasis zu standardisieren, entfernt den Codec-Renegotiation-Schritt, der auf einer Multi-Codec-Plattform stattfindet, wenn ein Chrome- und ein Safari-User demselben Raum beitreten. Diese Komplexität zu überspringen ist der Grund, warum Mid-Call-Reconnects bei Digital Samba nicht codec-getrieben sind – und die gesparte Engineering-Zeit fließt in Call-Verlässlichkeit und KI-Features.
• Aufzeichnungen und KI-Pipelines sind codec-agnostisch: wenn Sessions aufgezeichnet werden, kann die Aufzeichnungs-Pipeline von Digital Samba zu effizienteren Codecs für Speicherung und Archivierung transcodieren. Die KI-Features – Live-Untertitel, Transkription und Meeting-Zusammenfassungen – arbeiten auf der dekodierten Medien-Ebene, nicht am komprimierten Bitstream. Das heißt: sie funktionieren unabhängig davon, welcher Codec für die Session ausgehandelt wurde. Du bekommst das volle KI-Feature-Set, egal ob der Call mit VP8, H.264 oder VP9 lief.
• AV1 ist auf der Watchlist, nicht auf der unmittelbaren Roadmap: Digital Samba beobachtet die AV1-Hardware-Encoder-Verfügbarkeit über Consumer-Geräte, aber ein Echtzeit-AV1-Rollout ist nicht im Kurzfrist-Plan. Der Entscheidungspunkt liegt einige Jahre voraus – wenn AV1-Hardware-Encoding auf Mid-Range-Consumer-Geräten Standard ist und die Kosten der Aushandlung eines zweiten Codecs durch sichtbare Bandbreiten-Ersparnis für Nutzer gerechtfertigt sind. Bis dahin bleibt VP8 der Produktions-Codec.

Ein praktisches Entscheidungs-Framework für deine Plattform

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.

FAQ

Wird VP8 wirklich 2026 noch in produktivem WebRTC eingesetzt?

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.

Wann wird AV1 der dominante Codec für Videokonferenz?

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.

Welcher Codec liefert die beste Videoqualität bei niedriger Bandbreite?

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.

Muss ich mehrere Codecs in meiner Videokonferenz-Plattform unterstützen?

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.

Was ist LCEVC und könnte es eine Alternative zum Codec-Wechsel sein?

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.

Ändert AV1 für DACH-Plattformen etwas an der DSGVO- oder Compliance-Position?

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.

Fazit

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