Jede Engineer:in, die schon einmal ein Live-Streaming-System gebaut hat, landet irgendwann beim gleichen unangenehmen Gespräch mit dem Produktteam: „Wir können Sub-Sekunden-Latenz haben, oder Millionen gleichzeitiger Zuschauer:innen. Such dir was aus."

Das ist das Streaming-Trilemma – der Drei-Wege-Kompromiss zwischen Latenz, Skalierung und architektonischer Einfachheit, der die Live-Medienauslieferung den größten Teil der letzten zwei Jahrzehnte eingeschränkt hat. WebRTC gab uns die Geschwindigkeit eines Videocalls, brach aber unter Broadcast-Fan-out zusammen. HLS und DASH gaben uns globale Distribution, bestraften Zuschauer:innen aber mit 5–30 Sekunden Verzögerung. Jedes neue Protokoll, das auftauchte – SRT, RTMP, LL-HLS – flickte eine Seite des Dreiecks und machte die anderen leise schlechter.

Media over QUIC (MoQ) ist der Versuch der IETF, dieses Dreieck komplett einzuebnen. Es ist ein Pub/Sub-Transportprotokoll auf Basis von QUIC (dem gleichen Fundament wie HTTP/3), von Grund auf darauf ausgelegt, Sub-Sekunden-Latenz bei CDN-Skalierung zu liefern – ohne die architektonische Komplexität, die WebRTC beim Broadcast-Einsatz so mühsam macht. Ob es gelingt, ist eine offene Frage; aber die Organisationen, die darauf setzen – Cloudflare, Google, Meta, Cisco, Akamai – legen nahe, dass das kein weiteres Nischen-Experiment ist.

Das hier ist eine tiefgehende Analyse: Was MoQ ist, wie es im Vergleich zu den Protokollen abschneidet, die es eines Tages ablösen könnte, wer es baut – und wie das Bild zur Produktionsreife im Mai 2026 aussieht.

Inhaltsverzeichnis

1. Das Streaming-Trilemma
2. Was ist Media over QUIC?
3. MoQ vs. WebRTC: Koexistenz, kein Ersatz
4. Wer baut MoQ?
5. Stand der Produktionsreife
6. Was MoQ für Videoplattformen bedeutet
7. FAQ

Das Streaming-Trilemma

Um zu verstehen, warum MoQ relevant ist, hilft es, das Problem zu verstehen, das es lösen will – und warum jede bisherige Lösung einen unangenehmen Kompromiss verlangt hat.

WebRTC: Echtzeit, aber nicht wirklich skalierbar

WebRTC wurde für Videokonferenzen entworfen. Es liefert Sub-100-ms-Latenz über direkte Peer-to-Peer-Verbindungen mit UDP-basierten RTP-Streams. Für einen Zweier-Call oder ein kleines Gruppenmeeting ist das genau die richtige Architektur.

Das Problem: WebRTCs Peer-to-Peer-Modell skaliert nicht für Broadcast. Wenn 100.000 Menschen ein Live-Event einschalten, kannst du nicht 100.000 einzelne Peer-Verbindungen vom Broadcaster aus aufbauen. Selective Forwarding Units (SFUs) helfen, indem sie Streams serverseitig weiterleiten – aber auch SFU-basierte Architekturen brauchen erheblichen Per-Connection-State, der großflächigen Fan-out teuer, operativ komplex und anfällig für Kaskadenfehler bei unerwarteten Lastspitzen macht.

WebRTC trägt außerdem erheblichen Verbindungs-Overhead: ICE-Negotiation, STUN/TURN-Traversal, DTLS-Handshake und eine Signalling-Schicht, die laufen muss, bevor ein einziger Frame Medien die Zuschauer:in erreicht. Diese Maschinerie passt zur Konferenz, wo bidirektionale Kommunikation die Komplexität rechtfertigt. Für One-to-Many-Live-Streaming ist sie signifikanter Overhead für einen Use Case, der ihn nicht braucht.

HLS und DASH: skalierbar, aber langsam

Apples HTTP Live Streaming und MPEG-DASH lösten das Skalierungsproblem elegant. Indem sie Video in kurze Segmente kodieren und über HTTP ausliefern, nutzen diese Protokolle die globale CDN-Infrastruktur, die für Webinhalte ohnehin existiert. Ein HLS-Live-Stream kann Millionen gleichzeitige Zuschauer:innen bedienen, ohne spezielle Infrastruktur jenseits eines Standard-CDNs.

Der Preis ist Latenz. Klassisches HLS arbeitet mit einer Latenz von 20–45 Sekunden. Low-Latency HLS (LL-HLS) und Low-Latency DASH haben das deutlich verbessert (auf etwa 2–4 Sekunden unter idealen Bedingungen), aber das in der Praxis zu erreichen verlangt sorgfältiges Tuning von Segmentdauer, CDN-Konfiguration und Player-Buffering. Das inhärente Polling-Modell von HTTP zwingt Player, wiederholt neue Segmente anzufordern – ein Round-Trip-Overhead, der Sub-Sekunden-Auslieferung praktisch unmöglich macht.

MoQ vs. HLS: warum dieser Vergleich zählt

Beim Framing MoQ vs. HLS werden die Einsätze am deutlichsten. Die Skalierung von HLS ist real und bewiesen. Die Frage, die MoQ beantworten soll: Kannst du diese Skalierung haben, ohne die Latenzstrafe? Erste Hinweise deuten auf Ja – aber mit dem deutlichen Vorbehalt, dass die Ökosystem-Reife von HLS (ein zehn Jahre alter Standard mit universellem Toolchain-Support) nicht über Nacht zu replizieren ist.

Was ist Media over QUIC?

Media over QUIC ist ein Publish-Subscribe-Transportprotokoll, das von der MoQ Working Group der IETF entwickelt wird. Die aktuell veröffentlichte Version der Kern-Transportspezifikation, draft-ietf-moq-transport-17, wurde am 2. März 2026 veröffentlicht, mit Co-Editor:innen von Cisco, Google und Meta.

Das QUIC-Fundament

QUIC ist ein gemultiplextes, verschlüsseltes Transportprotokoll, ursprünglich von Google entwickelt und mittlerweile als RFC 9000 standardisiert. Es läuft über UDP, umgeht TCPs Head-of-Line-Blocking und liefert dabei die Zuverlässigkeit, Ordnung und Staukontrolle, die Anwendungen brauchen. HTTP/3 läuft über QUIC, was bedeutet, dass das Protokoll bereits einen substantiellen Anteil des globalen Webverkehrs trägt.

Die Eigenschaften von QUIC, die es für Medien attraktiv machen:

• Gemultiplexte Streams mit unabhängiger Auslieferung: ein verlorenes Paket in einem Stream blockiert die Auslieferung in anderen nicht – anders als bei TCP.
• Partielle Zuverlässigkeit: QUIC kann so konfiguriert werden, dass es Daten verwirft statt sie zu retransmittieren – der richtige Trade-off für Live-Medien, wo ein veralteter Videoframe schlimmer ist als ein fehlender.
• Eingebaute Verschlüsselung: TLS 1.3 ist direkt im QUIC-Transportlayer eingebacken, nicht obendrauf gelegt.
• Connection Migration: QUIC-Verbindungen überleben IP-Adresswechsel, was bei mobilen Clients zählt.

Das Pub/Sub-Modell und die Relay-Architektur

Der MOQT-Transportlayer sitzt über QUIC (oder WebTransport, im Browser) und definiert ein Publish-Subscribe-Modell für die Medienauslieferung. Statt des Request-Response-Modells von HTTP oder des Peer-to-Peer-Modells von WebRTC nutzt MOQT eine Architektur aus Publishern, Subscribern und Relays.

Ein Publisher (der Live-Encoder oder Broadcaster) verbindet sich mit einem Relay und veröffentlicht Tracks. Subscriber (Zuschauer:innen) verbinden sich mit Relays und abonnieren Tracks. Das Relay-Netzwerk übernimmt den Fan-out: Ein einzelner veröffentlichter Stream lässt sich an beliebig viele Subscriber verteilen, ohne dass der Publisher individuelle Verbindungen zu jeder einzelnen Empfänger:in halten muss.

Dieses Relay-Netzwerk-Modell ist architektonisch analog dazu, wie CDNs HTTP-Inhalte verteilen (Edge-Knoten abonnieren Inhalte bei Bedarf von Origin-Knoten) – arbeitet aber auf der Transportebene statt auf der HTTP-Ebene, mit den entsprechenden Latenzvorteilen.

Tracks, Groups und Objects

MOQT definiert ein dreistufiges Datenmodell:

Objects sind die Basiseinheit – beliebige Bytesequenzen mit Headern, die Metadaten enthalten. Ein Videoframe, ein Audiosegment, eine Untertitel-Cue oder jedes andere zeitlich ausgerichtete Datenstück ist ein Object.

Groups sind geordnete Sequenzen von Objects, typischerweise begrenzt durch Video-Keyframes (I-Frames). Eine Group lässt sich unabhängig dekodieren – wer also mitten in einen laufenden Broadcast einsteigt, startet an der nächsten Group-Grenze, nicht am Anfang der Übertragung.

Tracks sind Sammlungen von Groups aus einem einzelnen Publisher. Ein Video-Track, ein Audio-Track und ein Untertitel-Track lassen sich separat abonnieren, unterschiedlich priorisieren und unter Netzwerkdruck unabhängig droppen.

Medien-Agnostik

Eine wichtige Klarstellung im aktuellen Draft: Trotz des Namens ist MOQT explizit medien-agnostisch. Die Spezifikation sagt, es „kann für eine breite Bandbreite an Use Cases" jenseits von Video genutzt werden. Forscher:innen erkunden MOQT bereits als Transport für das Model Context Protocol (MCP) bei KI-Agent-Kommunikation – ein Beleg, dass die Pub/Sub-Architektur sich gut über Live-Streaming hinaus verallgemeinern lässt.

MoQ vs. WebRTC: Koexistenz, kein Ersatz

Das Gespräch MoQ vs. WebRTC ist eines der häufigsten und meistmissverstandenen Debatten im Streaming-Engineering gerade. Die kurze Antwort: Sie lösen unterschiedliche Probleme, und die richtige Architektur für die meisten Plattformen 2026 nutzt beides.

WebRTC bleibt die eindeutige Wahl für bidirektionale Echtzeit-Kommunikation: Konferenzen, Interview-Plattformen, kollaborative Tools, Voice-KI. Der Browser-Support ist universell, und der Medien-Stack (Codec-Aushandlung, Echo Cancellation, Bandbreitenschätzung) regelt die Komplexität interaktiver Kommunikation automatisch.

MoQs Vorteil zeigt sich, wenn der Use Case Distribution statt Konversation ist. Ein Sport-Broadcaster, der an 500.000 gleichzeitige Zuschauer:innen streamt, braucht den bidirektionalen Overhead von WebRTC nicht. Was er braucht, ist Sub-Sekunden-Latenz bei CDN-Skalierung – genau das Problem, das MoQs Relay-Architektur adressiert.

Die hybride Architektur, bei der die meisten Streaming-Plattformen landen werden: WebRTC für die interaktive Schicht (Panelist:innen, Kommentator:innen, Broadcast-Tools), MoQ für die Distributionsschicht (das Publikum, das zuschaut, aber nicht teilnimmt). Das ist kein Nullsummen-Ersatz, sondern ein komplementärer Stack, in dem jedes Protokoll in seinem Stärke-Bereich arbeitet.

Wer baut MoQ?

IETF MoQ 2026 ist kein Forschungsprojekt. Die Organisationen, die produktive MoQ-Infrastruktur bauen, repräsentieren einen erheblichen Anteil des globalen Internet-Traffics.

Cloudflare: das erste MoQ-CDN

Im August 2025 hat Cloudflare gestartet, was es als das erste produktive MoQ-Relay-Netzwerk beschreibt – verteilt über seine globale Infrastruktur in mehr als 330 Städten. Jeder Cloudflare-Server ist jetzt ein MoQ-Relay; das ist kein Test-Deployment, sondern Produktionsinfrastruktur auf gleichem Niveau wie Cloudflares bestehende Dienste.

Die Implementierung, moq-rs, ist Open Source und kompatibel mit mehreren Publishern, Playern und Tools im MoQ-Ökosystem. Cloudflare ist außerdem aktive:r IETF-Beitragende:r – mit Engineers, die Internet-Drafts zu Relay-DoS-Mitigations und CDN-Provisioning für MoQ co-autoriert haben.

OpenMOQ Software Consortium

Gegründet von Red5, Akamai, CDN77, Cisco, Synamedia und YouTube, ist das OpenMOQ Software Consortium das Industriegremium, das die Open-Source-MoQ-Implementierungsarbeit koordiniert. Stand Mai 2026 hat das Consortium sein Governance-Setup abgeschlossen, eine technische Roadmap aufgestellt und befindet sich in der Phase der Kern-Infrastruktur-Entwicklung.

Elf Anbieter – darunter Ant Media, AWS, Bitmovin, Broadpeak, CacheFly, Cloudflare, Nomad Media, Oracle, Norsk, Synamedia und Red5 – haben ihre ersten MoQ-Implementierungen auf der NAB Show 2026 in Las Vegas demonstriert und damit die bisher größte koordinierte MoQ-Interoperabilitäts-Demo abgeliefert.

Oracle OCI: Enterprise-MoQ am Edge

Oracles Plattform Oracle Video @ Edge (OVE) fungiert als MOQT-Relay-Netzwerk für Enterprise-Medien-Workflows. Auf der NAB Show 2026 hat Oracle Multi-Partner-MoQ-Workflows gezeigt, die Ateme (Encoding), Broadpeak (Packaging) und Cloudflare (CDN-Auslieferung) über ein gemeinsames MOQT-Relay-Fabric verbinden. OVE wirkt als Koordinationsschicht und managt Session-Lifecycle, Routing und Telemetrie über eine Multi-Vendor-Streaming-Pipeline hinweg.

Google und Meta: IETF-Co-Autor:innen

Engineers von Google (Ian Swett) und Meta (Alan Frindell) sind als Editor:innen der MOQT-Kernspezifikation gelistet. Das ist keine passive Befürwortung – die Editor:innen verantworten die technische Richtung des Drafts und die Auflösung der Implementierungs-Issues, die in der Working Group aufkommen. Beide Unternehmen haben MoQ-Implementierungen, die an Interoperabilitäts-Tests teilnehmen.

moq.dev: Open Source in Rust und TypeScript

Das Projekt moq.dev pflegt Open-Source-MoQ-Bibliotheken in Rust und TypeScript mit gleichwertigen APIs. Das Projekt umfasst moq-lite (das vereinfachte Transport-Subset), hang (medienspezifische Encoding- und Streaming-Abstraktionen) sowie Relay-Infrastruktur. Die Demo unter hang.live betreibt einen öffentlichen MoQ-Live-Stream und zeigt Sub-Sekunden-Latenz im Browser – ohne Plugin.

Stand der Produktionsreife

Wo MoQ im Mai 2026 wirklich steht

Ehrliche Einschätzung: MoQ ist produktionsreif für kontrollierte Deployments, experimentelle Early-Mover-Workloads und Ingest-Pipelines. Es ist noch nicht reif für konsument:innenseitige Deployments, die universelle Browser-Kompatibilität und sauberes Fallback-Handling verlangen – aber diese Lücke schließt sich schneller, als die meisten erwartet haben.

WebTransport erreicht Baseline

Die kritische Infrastruktur-Abhängigkeit für MoQ im Browser ist WebTransport – die W3C-API, die QUICs Fähigkeiten für Browser-Anwendungen verfügbar macht. Im März 2026 hat Safari 26.4 WebTransport ausgeliefert und damit zu Chrome, Firefox und Edge aufgeschlossen. Damit ist die Schwelle zu „Baseline" überschritten – die Web-Plattform-Bezeichnung für Features, die produktionssicher quer über alle großen Browser nutzbar sind.

Das ist ein bedeutsamer Wendepunkt. Bis März 2026 bedeutete Safaris Abwesenheit bei WebTransport, dass jedes iOS-Gerät und jede Safari-Nutzer:in aus MoQ-basierten Web-Anwendungen ausgeschlossen war. Diese Einschränkung ist jetzt weg.

Die Draft-Inkompatibilitäts-Herausforderung

Die Transport-Spezifikation hat mehrere Revisionen durchlaufen, und Implementierungen, die gegen draft-14 oder draft-15 geschrieben wurden, interoperieren möglicherweise nicht sauber mit draft-17. Das ist die typische unordentliche Mitte einer IETF-Standardisierung. Organisationen, die heute auf MoQ bauen, akzeptieren ein gewisses Versions-Lock-Risiko im Tausch gegen Early-Mover-Vorteil. Die Spezifikation wird voraussichtlich 2027 oder 2028 RFC-Status erreichen – ab dann wird das Inkompatibilitäts-Problem historisch.

Die Adoptions-Frage

Es gibt auch eine Gegen-Erzählung, die ernst zu nehmen ist. In einer Analyse vom Mai 2026 argumentiert Tsahi Levent-Levi auf BlogGeek.me, dass MoQ die klassischen Anzeichen eines Vendor-pushed-Protokolls zeigt, nicht eines Customer-pulled-Protokolls: Trotz Cloudflares Relay-Netzwerk in über 330 Städten ist bislang kein flaggschiff-haftes Broadcast- oder Consumer-Unternehmen öffentlich als End-Customer benannt – und die typische Enterprise-Frage lautet noch immer, ob es zu früh ist, MoQ überhaupt anzusehen, nicht wann man migrieren sollte.

Der pessimistische Fall stützt sich auf drei konkrete Punkte. Erstens: MoQ ist kein transparenter Upgrade-Pfad, wie es HTTP/3 war. HTTP/3 wurde unsichtbar ausgerollt, weil die Anwendungsschicht sich nicht änderte; MoQ verlangt Player-Rewrites, Encoder-Umbauten und operative Anpassungen, die einen klaren kommerziellen Trigger brauchen. Zweitens: Die Protokoll-Oberfläche ist immer noch zersplittert – konkurrierende Medienformat-Vorschläge (WARP, LOC, CMSF, MSF) bedeuten, dass selbst Anbieter, die sich auf den Transport einigen, noch nicht einig sind, was darüber fließt. Eine RFC-Veröffentlichung der Kerntransport-Spezifikation wird realistisch auf Ende 2027 bis Mitte 2028 datiert. Drittens: MoQ tritt gegen Incumbents an, deren Infrastruktur abgeschrieben, deren Toolchains reif und deren Engineers leicht einstellbar sind. Anders als WebRTC, das einen Use Case ermöglichte (browser-natives Videocalling), der vorher nicht existierte, schlägt MoQ architektonische Verbesserungen bei Use Cases vor, für die schon funktionierende Lösungen existieren – ein schwierigerer kommerzieller Fall.

Nichts davon ist ein Argument dafür, dass MoQ scheitern wird. Das Protokoll ist solide, die Working Group ist ernsthaft, und die Relay-Infrastruktur ist real. Aber der Zeitraum von „produktives Relay-Netzwerk existiert" bis „ein nennenswerter Anteil des Live-Streaming-Traffics läuft tatsächlich darüber" wird sich eher in Jahren als in Quartalen messen lassen. Für Plattformen, die MoQ heute evaluieren, bestätigt das den praktischen Ratschlag, statt ihn umzustoßen: Vertrautheit jetzt aufbauen, gegen die verfügbaren Relay-Netzwerke prototypen – aber keine 2027er Produkt-Roadmap auf eine Massen-MoQ-Adoption setzen, die der Markt noch nicht validiert hat.

moq-lite: der pragmatische Deployment-Pfad

moq-lite ist ein vereinfachtes, vorwärtskompatibles Subset der vollen MOQT-Spezifikation, entwickelt von Luke Curley (zuvor Twitch und Discord) und genutzt im moq.dev-Projekt. Es lässt Features weg, die in der Working Group umstritten oder schwer zu stabilisieren waren, und legt eine saubere Pub/Sub-API frei, die mit jedem MoQ-CDN funktioniert.

Die moq.dev-Dokumentation formuliert es so: „Die Prinzipien hinter MoQ sind fantastisch, aber Standards sind langsam und beinhalten zu viel Streiten/Aufblähung." moq-lite ist die pragmatische Antwort: ein Subset, das vorwärtskompatibel zum vollen MOQT (draft-14 und höher) ist und heute deploybar, ohne darauf zu warten, dass jeder Eckfall der Spezifikation geklärt ist.

Die Rust-Implementierung von moq-lite ist auf crates.io verfügbar. Die TypeScript-Implementierung zielt auf Browser via WebTransport. Beide teilen sich gleichwertige APIs – Relay-Infrastruktur lässt sich also zwischen serverseitigen und browserseitigen Komponenten teilen.

Was MoQ für Videoplattformen bedeutet

Für Plattformen, die zwischen Konferenz und Broadcast vermitteln – Videomeeting-Tools mit Live-Streaming, Event-Plattformen oder Hybrid-Konferenz-zu-Publikum-Lösungen – stellt MoQ eine ernstzunehmende architektonische Chance dar.

Die hybride Architektur

Das wahrscheinlichste Deployment-Muster für Plattformen mit interaktiver und Broadcast-Komponente ist ein hybrider Stack:

• WebRTC übernimmt die interaktive Session-Schicht: Teilnehmenden-Video, -Audio, Bildschirmfreigabe und bidirektionale Kommunikation zwischen Sprechenden und Moderator:innen.
• MoQ übernimmt die Distributionsschicht: nimmt den gemischten Output der Konferenz und verteilt ihn in Broadcast-Skalierung an Zuschauenden, die zuschauen, aber nicht teilnehmen.

Architektonisch sauber, weil WebRTC und MoQ unterschiedliche Punkte der Pipeline adressieren. Die SFU, die die WebRTC-Konferenz managt, kann einen Composite-Stream in ein MoQ-Relay-Netzwerk veröffentlichen, das ihn dann an Zuschauer:innen-Publika fan-outet – ohne dass die SFU Per-Viewer-Verbindungen managen müsste.

Restreaming und MoQ-Ingest

Für Plattformen, die Restreaming anbieten – die Fähigkeit, einen Live-Stream gleichzeitig an mehrere Ziele zu pushen (YouTube, Twitch, ein eigener RTMP-Endpoint) – ist MoQs Ingest-Modell relevant. MoQ-Ingest hat weniger Overhead als RTMP für den Publisher und ist einfacher zu implementieren als WebRTC-Ingest, ohne die Peer-Connection-Aushandlung. Wenn MoQ-Support in Broadcast-Tools wie OBS ankommt (GStreamer-Plugins sind in Entwicklung), wird der Ingest-zu-Relay-Pfad zur natürlichen Alternative für RTMP-basierte Restreaming-Workflows.

Die Timing-Frage

Für Streaming-Engineers und -Architekt:innen, die 2026 entscheiden, wo sie investieren: MoQ ist es wert, jetzt Vertrautheit aufzubauen und Prototyp-Investitionen zu tätigen. Die Spezifikation ist stabil genug zum Evaluieren, die Relay-Infrastruktur (Cloudflare, OCI) ist produktiv-reif, und das Ökosystem an Implementierungen ist breit genug, um dagegen zu entwickeln.

Universelles Consumer-Deployment – das Szenario, in dem du MoQ an End-Nutzer:innen ausspielst, ohne WebRTC- oder HLS-Fallback – ist frühestens eine Geschichte für 2027–2028, abhängig von RFC-Veröffentlichung und breiterer Toolchain-Unterstützung. Das Fenster für risikoarme Early Adoption wird enger.

Architektur-Diagramm

FAQ

Fazit

Zwei Jahrzehnte Streaming-Engineering haben eine zersplitterte Landschaft produziert: ein Protokoll für Echtzeit-Kommunikation, ein anderes für Broadcast-Distribution, ein drittes für Ingest – und einen immer weiter wachsenden Stapel aus CDN-Konfigurationen, SFU-Clustern und TURN-Servern, der das Ganze zusammenhält.

MoQ ist der Versuch, von einer saubereren Basis neu zu bauen: ein einzelnes Transportprotokoll, fundiert in QUIC, das das Latenz-Skalierungs-Spektrum überspannt, ohne separate Architekturen für jeden Punkt darauf zu verlangen. In einfachster Form erklärt: Pub/Sub-Medienauslieferung über QUIC, mit einem Relay-Modell, das wie ein CDN skaliert, und Latenz, die sich WebRTC annähert.

Das Ökosystem ist real, die Relay-Infrastruktur ist produktiv-reif, und der Browser-Support hat die Baseline-Schwelle überschritten. Was bleibt: RFC-Veröffentlichung, Toolchain-Reife und die Art breiter Deployment-Erfahrung, die aus einem vielversprechenden Protokoll einen Industriestandard macht.

Für Streaming-Engineers: Jetzt ist der richtige Zeitpunkt, Vertrautheit mit MoQ aufzubauen, Experimente gegen Cloudflares Relay-Netzwerk laufen zu lassen und deine hybriden Architekturen zu entwerfen. Das Produktionsfenster öffnet sich.

→ Entdecke die Streaming-Features von Digital Samba – inklusive unserer Restreaming-API, die an RTMP-Endpoints andockt und im Hinblick auf MoQ-Ingest-Support beobachtet wird, sobald das Ökosystem reift.

Quellen

1. Bitmovin. (2026). Media over QUIC (MoQ) with Bitmovin and Cloudflare. https://bitmovin.com/blog/media-over-quic-bitmovin-cloudflare/

2. Cloudflare. (2025, 29. August). MoQ: Refactoring the internet's real-time media stack. https://blog.cloudflare.com/moq/

3. English, M., Pardue, L., Sharma, A., & Swett, I. (2026, 2. März). Denial-of-service considerations for Media over QUIC relay deployments (draft-englishm-moq-relay-dos-00). IETF. https://datatracker.ietf.org/doc/draft-englishm-moq-relay-dos/

4. Internet Engineering Task Force (IETF). (o. J.). Media over QUIC (MoQ) working group. https://datatracker.ietf.org/group/moq/about/

5. Kurinnoi, P. (2026, April). Media over QUIC (MoQ): The protocol that could finally unify streaming. Medium – Video Tech. https://medium.com/video-tech/media-over-quic-moq-the-protocol-that-could-finally-unify-streaming-8b95972db9ce

6. Law, W. (2026, 19. Januar). MOQT Streaming Format (draft-ietf-moq-msf-00). IETF. https://datatracker.ietf.org/doc/draft-ietf-moq-msf/

7. Levent-Levi, T. (2026, Mai). The MoQ adoption problem. BlogGeek.me. https://bloggeek.me/moq-adoption-problem/

8. moq.dev. (2025). The first MoQ CDN: Cloudflare. https://moq.dev/blog/first-cdn/

9. moq.dev. (o. J.). Media over QUIC. https://moq.dev/

10. moq-dev. (o. J.). MoQ: Media over QUIC library in Rust + TypeScript [GitHub-Repository]. https://github.com/moq-dev/moq

11. Nandakumar, S., Vasiliev, V., Swett, I. (Hrsg.), & Frindell, A. (Hrsg.). (2026, 2. März). Media over QUIC Transport (draft-ietf-moq-transport-17). IETF. https://datatracker.ietf.org/doc/html/draft-ietf-moq-transport-17

12. OpenMOQ Software Consortium. (o. J.). OpenMOQ: Advancing MOQ protocol. https://openmoq.org/

13. Oracle. (2026, April). Oracle Video @ Edge: Showcasing Media over QUIC partner workflows at NAB. Oracle Cloud Infrastructure Blog. https://blogs.oracle.com/cloud-infrastructure/oracle-video-edge-media-over-quic-workflows-nab

14. Red5. (2026, April). What is MOQ (Media over QUIC) and why it matters. https://www.red5.net/blog/what-is-moq-media-over-quic/

15. Red5. (2026, 26. Januar). 6 MOQ players you need to know about: Pros and cons. https://www.red5.net/blog/6-moq-players-you-need-to-know-about/

16. Red5. (2026). MOQ vs WebRTC: Why both protocols can and should exist in live streaming space in 2026. https://www.red5.net/blog/moq-vs-webrtc/

17. Red5. (2025, Dezember). Media over QUIC (MoQ): Beta access. https://www.red5.net/media-over-quic-moq/

18. Red5. (2025, 24. Dezember). Red5 joined the OpenMOQ Software Consortium. https://www.red5.net/blog/red5-joined-openmoq/

19. WebRTC.ventures. (2026, April). WebTransport is now Baseline: Here's what that means for real-time media. https://webrtc.ventures/2026/04/webtransport-is-now-baseline-what-it-means-for-real-time-media/

20. WINK Streaming. (2025). Media over QUIC (MoQ) implementation: Technical analysis & browser reality. https://www.wink.co/documentation/WINK-MoQ-Implementation-Analysis-2025.php