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
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 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.
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.
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.
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.
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:
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.
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.
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.
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 |
MoQ (MOQT) |
|
|
Primärer Use Case |
Bidirektionale Echtzeit-Konferenz |
Skalierbare Low-Latency-Mediendistribution |
|
Latenz |
< 100 ms (Sub-Sekunde) |
< 500 ms (Sub-Sekunde, Ziel < 200 ms) |
|
Fan-out-Skalierung |
Hunderte pro SFU (Föderation nötig) |
Millionen über Relay-Tree |
|
Verbindungsaufbau |
Hoher Overhead (ICE, DTLS, STUN/TURN, Signalling) |
Niedriger Overhead via QUIC/WebTransport |
|
Browser-Support |
Universal (alle großen Browser, alle Versionen) |
Braucht WebTransport (alle großen Browser seit März 2026) |
|
Protokoll-Status |
RFC 8829 (stabiler Standard) |
IETF draft-17 (RFC in Sichtweite) |
|
Richtung |
Bidirektional (dafür entworfen) |
Primär unidirektionales Pub/Sub |
|
Komplexität |
Hoch (SFU, ICE, STUN/TURN-Infrastruktur) |
Niedriger (Relay-Netzwerk, kein ICE/DTLS-Overhead) |
|
Ideal für |
Videokonferenz, Live-Zusammenarbeit |
Live-Sport, Konzerte, Nachrichten, interaktiver Broadcast |
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.
IETF MoQ 2026 ist kein Forschungsprojekt. Die Organisationen, die produktive MoQ-Infrastruktur bauen, repräsentieren einen erheblichen Anteil des globalen Internet-Traffics.
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.
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.
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.
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.
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.
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.
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 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.
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 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.
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.
Das wahrscheinlichste Deployment-Muster für Plattformen mit interaktiver und Broadcast-Komponente ist ein hybrider Stack:
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.
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.
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.
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.
Bitmovin. (2026). Media over QUIC (MoQ) with Bitmovin and Cloudflare. https://bitmovin.com/blog/media-over-quic-bitmovin-cloudflare/
Cloudflare. (2025, 29. August). MoQ: Refactoring the internet's real-time media stack. https://blog.cloudflare.com/moq/
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/
Internet Engineering Task Force (IETF). (o. J.). Media over QUIC (MoQ) working group. https://datatracker.ietf.org/group/moq/about/
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
Law, W. (2026, 19. Januar). MOQT Streaming Format (draft-ietf-moq-msf-00). IETF. https://datatracker.ietf.org/doc/draft-ietf-moq-msf/
Levent-Levi, T. (2026, Mai). The MoQ adoption problem. BlogGeek.me. https://bloggeek.me/moq-adoption-problem/
moq.dev. (2025). The first MoQ CDN: Cloudflare. https://moq.dev/blog/first-cdn/
moq.dev. (o. J.). Media over QUIC. https://moq.dev/
moq-dev. (o. J.). MoQ: Media over QUIC library in Rust + TypeScript [GitHub-Repository]. https://github.com/moq-dev/moq
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
OpenMOQ Software Consortium. (o. J.). OpenMOQ: Advancing MOQ protocol. https://openmoq.org/
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
Red5. (2026, April). What is MOQ (Media over QUIC) and why it matters. https://www.red5.net/blog/what-is-moq-media-over-quic/
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/
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/
Red5. (2025, Dezember). Media over QUIC (MoQ): Beta access. https://www.red5.net/media-over-quic-moq/
Red5. (2025, 24. Dezember). Red5 joined the OpenMOQ Software Consortium. https://www.red5.net/blog/red5-joined-openmoq/
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/
WINK Streaming. (2025). Media over QUIC (MoQ) implementation: Technical analysis & browser reality. https://www.wink.co/documentation/WINK-MoQ-Implementation-Analysis-2025.php