Media over QUIC — MoQ — ist das meistdiskutierte aufkommende Streaming-Protokoll der Jahre 2025-2026. Blogartikel vervielfachen sich, Konferenzvorträge häufen sich, und CDN-Anbieter wetteifern darum, Unterstützung anzukündigen. Wenn Sie im Bereich Live-Streaming arbeiten, wurde Ihnen wahrscheinlich bereits die Frage gestellt: Sollten wir auf MoQ umsteigen?
Die kurze Antwort lautet für die meisten Produkte, die heute ausgeliefert werden: Nein — noch nicht. Aber es lohnt sich, MoQ zu verstehen, denn die Probleme, die es löst, sind real, und der Zeitrahmen bis zur Produktionsreife wird mittlerweile in Quartalen gemessen, nicht mehr in Jahren.
Dieser Artikel erklärt, was MoQ tatsächlich ist, wo es im März 2026 steht, was es im Vergleich zu HLS, WebRTC und SRT verändert — und ob es für zwei reale Produkte, die wir im Einsatz haben, sinnvoll wäre: WeSpeakSports (Live-Fan-Audiokommentar über WebRTC) und DJing Stream (sendefähiges DJ-Audio über SRT und HLS Lossless).
Was MoQ tatsächlich ist
MoQ steht für Media over QUIC. Es handelt sich um eine 2022 gestartete IETF-Arbeitsgruppe mit dem Ziel, ein neues Medienübertragungsprotokoll auf Basis von QUIC (der Transportschicht hinter HTTP/3) zu definieren.
Die zentrale Transportspezifikation, draft-ietf-moq-transport, erreichte im März 2026 Version 17. Eine Streaming-Format-Spezifikation (draft-ietf-moq-msf) ist ebenfalls in Arbeit, zusammen mit ergänzenden Entwürfen für CMAF-Paketierung und Header-Kompression. Keiner dieser Entwürfe ist bisher ein finalisierter RFC.
Im Kern ist MoQ ein publish/subscribe-Protokoll. Ein Publisher sendet benannte Medienobjekte (Audioframes, Videoframes, Metadaten) an Relays, und Subscriber empfangen diese, indem sie benannte Tracks abonnieren. Dies unterscheidet sich grundlegend sowohl von HLS (HTTP-Request/Response für Segmente) als auch von WebRTC (Peer-to-Peer-Sitzungsaushandlung mit SDP/ICE).
MoQ läuft über QUIC-Streams und -Datagramme, entweder nativ oder über WebTransport (die Browser-API für QUIC). Dadurch erhält es Zugang zu QUICs Multiplexing-, Priorisierungs- und partiellen Zuverlässigkeitsfunktionen — das bedeutet, das Protokoll kann konstruktionsbedingt einen verspäteten Videoframe verwerfen, anstatt den gesamten Stream zum Stillstand zu bringen, während auf die erneute Übertragung gewartet wird.
Was MoQ ersetzen soll
Wie Cullen Jennings von Cisco (Teilnehmer der MoQ-Arbeitsgruppe) es formuliert, hat die Streaming-Welt derzeit zwei Silos. Auf der einen Seite liefern Dienste wie Netflix und YouTube Medien über HTTP-basierte CDNs im großen Maßstab, aber mit Latenzen im Sekundenbereich. Auf der anderen Seite liefern Konferenztools wie Zoom und WebRTC-basierte Plattformen Medien nahezu in Echtzeit, können aber nicht kosteneffizient auf große Zuschauerzahlen skaliert werden.
MoQ zielt darauf ab, diese beiden Welten mit einem einzigen Protokoll zu verbinden, das sowohl Echtzeit- als auch Nahezu-Echtzeit-Anwendungsfälle bedienen kann — von der Zulieferung (Ingest) über die Verteilung (Auslieferung an Zuschauer) bis hin zur CDN-kompatiblen Relay-Infrastruktur dazwischen.
Wo MoQ heute steht (März 2026)
Lassen Sie uns den aktuellen Stand präzise betrachten:
Die Spezifikation ist nahe am Abschluss, aber noch nicht fertig. Der Transport-Entwurf liegt in Version 17 vor und wird zügig weiterentwickelt. Der Streaming-Format-Entwurf wurde im Januar 2026 veröffentlicht. Es gibt aktive Begleitarbeit an CMAF-Paketierung und Header-Kompression. Aber es gibt noch keinen ratifizierten RFC.
Die Safari/WebTransport-Lücke schließt sich. MoQ im Browser hängt von WebTransport ab, das HTTP/3 und QUIC voraussetzt. Chrome und Firefox unterstützen WebTransport bereits. Safari war der Nachzügler — aber Apple hat WebTransport-Unterstützung in Safari 26.4 Beta (Februar 2026) hinzugefügt, und es ist eine offizielle Interop 2026-Verpflichtung von WebKit. Stand März 2026 ist dies noch nicht in einer stabilen Safari-Version erschienen, aber es ist keine Frage mehr des Ob — nur noch des Wann im nächsten Betriebssystemzyklus. Für Produkte, die iPhone- und iPad-Nutzer über den Browser ansprechen, ist die Lücke nahezu geschlossen.
Frühe Produktionseinsätze existieren, sind aber begrenzt. Nanocosmos demonstrierte eine durchgängige MoQ-Auslieferung (OBS-Ingest bis zum globalen Publikum) beim MonteVIDEO Summer Project. Cloudflare startete eine MoQ-Beta. Red5 kündigte MoQ-Unterstützung bis Ende 2026 an. Aber dies sind Einsätze von Early Adoptern, keine Mainstream-Infrastruktur.
Die Community ist ehrlich bezüglich der Reife. Selbst Luke Curley, der eine der frühesten MoQ-Implementierungen bei Twitch (jetzt Discord) gebaut und den Vereinfachungsentwurf moq-lite verfasst hat, erklärt ausdrücklich, dass die vollständige MoQ-Transportspezifikation „zu kompliziert geworden ist" mit „zu vielen Nachrichten, optionalen Modi und halbfertigen Funktionen". Sein moq-lite-Entwurf ist eine Antwort auf diese Komplexität.
Branchenveteranen sind zurückhaltend. Tsahi Levent-Levi von BlogGeek.me prognostizierte, dass Entwickler 2026 mehr über WebRTC als über MoQ klagen würden — nicht weil MoQ besser ist, sondern weil MoQ-Nutzer noch Early Adopter sind, die mit Ecken und Kanten rechnen. WebRTC ist dasjenige, das überall im Produktionseinsatz steht und die Last realer Erwartungen trägt.
Was MoQ im Vergleich zu HLS verändert
HLS (HTTP Live Streaming) funktioniert, indem Medien in Segmente aufgeteilt, auf einen HTTP-Server geschrieben und von Playern über Playlists nach neuen Segmenten abgefragt werden. Es ist ausgereift, CDN-freundlich, breit eingesetzt und gut dokumentiert in RFC 8216 und Apples HLS Authoring Specification. Low-Latency HLS (LL-HLS) drückt die Latenz auf ungefähr 2-4 Sekunden.
MoQ verändert das Auslieferungsmodell in mehrfacher Hinsicht:
Von Polling zu Push. HLS-Player fordern Segmente an. MoQ-Subscriber erhalten Objekte, sobald sie veröffentlicht werden. Dies eliminiert die Polling-Latenz.
Von Segmenten zu Objekten. HLS arbeitet mit mehrere Sekunden langen Segmenten (oder Teilsegmenten bei LL-HLS). MoQ kann auf Frame-Ebene arbeiten. Ein einzelner Video- oder Audioframe kann ein individuell adressierbares, individuell auslieferbares Objekt sein.
Von TCP zu QUIC. HLS läuft über HTTP/TCP. Wenn ein TCP-Paket verloren geht, wird alles dahinter blockiert (Head-of-Line-Blocking). MoQ läuft über QUIC, wo Streams unabhängig sind — ein verlorenes Paket auf einem Stream blockiert keine anderen.
Explizite Priorisierung. Der Transport-Entwurf von MoQ definiert Priorität und Auslieferungsreihenfolge auf Protokollebene. Bei Überlastung kann ein Relay Objekte mit niedrigerer Priorität verwerfen (z.B. B-frames), anstatt alles gleichermaßen zu verzögern.
Vereinheitlichter Ingest und Distribution. Heute verwenden die meisten Live-Workflows ein Protokoll für die Zulieferung (RTMP, SRT, WHIP) und ein anderes für die Verteilung (HLS, DASH). MoQ kann potenziell beide Wege mit einem einzigen Protokoll bedienen und den Umpaketierungsschritt am Origin-Server eliminieren.
Wann HLS weiterhin die bessere Wahl ist
Nichts davon bedeutet, dass HLS obsolet ist. HLS bleibt die stärkere Wahl, wenn:
- Einige Sekunden Latenz völlig akzeptabel sind
- Breite Gerätekompatibilität essenziell ist (jedes Telefon, jeder Fernseher und jede Set-Top-Box spielt HLS ab)
- Die bestehende CDN- und Tooling-Investition gut funktioniert
- Betriebliche Einfachheit und kampferprobte Zuverlässigkeit wichtiger sind als die Latenz weiter zu senken
Für die Standard-OTT-Live- und VOD-Auslieferung — die den überwältigenden Großteil des Streaming-Traffics ausmacht — ist HLS nicht kaputt, und MoQ löst kein Problem, das existiert.
Was MoQ im Vergleich zu WebRTC verändert
WebRTC wurde für Echtzeit-Peer-to-Peer-Kommunikation entwickelt: Videoanrufe, Bildschirmfreigabe, Einzel- oder Kleingruppengespräche. Die Branche hat es weit über diesen ursprünglichen Anwendungsbereich hinaus ausgedehnt und nutzt SFU-Architekturen (Selective Forwarding Unit), um WebRTC auf größere Zuschauerzahlen zu skalieren.
MoQ unterscheidet sich von WebRTC in mehreren wichtigen Punkten:
Architektur. WebRTC ist grundlegend ein sitzungsorientiertes Peer-to-Peer-Protokoll, selbst wenn es über SFUs vermittelt wird. MoQ ist ein Client-Server-publish/subscribe-Protokoll, das von Anfang an um Relays und CDN-artige Distribution herum konzipiert wurde.
Skalierungsmodell. Die Skalierung von WebRTC erfordert eine zweckgebundene und teure SFU-Infrastruktur. MoQ-Relays sind darauf ausgelegt, sich in bestehende CDN-Infrastruktur zu integrieren — HTTP/3-Server können erweitert werden, um MoQ-Traffic zu verarbeiten, weshalb CDN-Anbieter wie Akamai und YouTube aktiv beteiligt sind.
Komplexität. WebRTC bringt erhebliche Komplexität mit sich: SDP-Offer/Answer-Aushandlung, ICE-Candidate-Gathering, STUN/TURN-Server für NAT-Traversal, SRTP für Verschlüsselung, SCTP für Datenkanäle. Der Verbindungsaufbau von MoQ ist einfacher — ein QUIC-Handshake, gefolgt von Subscribe/Publish-Nachrichten.
Codec-Flexibilität. Die Codec-Aushandlung von WebRTC ist eng mit dem Protokoll gekoppelt. MoQ ist auf Transportebene codec-agnostisch — das Medienformat wird von der Anwendungsschicht behandelt (MSF, LOC oder benutzerdefinierte Container).
Browser-Abhängigkeit. Beide Protokolle sind für die webbasierte Auslieferung auf Browser-APIs angewiesen. WebRTC hat universelle Browser-Unterstützung. MoQ hängt von WebTransport ab, das Safari erst in der Beta (26.4, Februar 2026) hinzugefügt hat und noch nicht stabil ausgeliefert wurde. Diese Lücke schließt sich, ist aber heute noch eine praktische Einschränkung für MoQ.
Wann WebRTC weiterhin die bessere Wahl ist
WebRTC bleibt die bessere Wahl, wenn:
- Echte bidirektionale Echtzeitkommunikation benötigt wird (Videoanrufe, Konferenzen)
- Browser-Kompatibilität auf allen Plattformen einschließlich Safari/iOS erforderlich ist
- Der Anwendungsfall Peer-to-Peer oder Kleingruppen umfasst, ohne Bedarf an CDN-skalierter Distribution
- Bewährtes, produktionsreifes Tooling und SDK-Reife von Bedeutung sind
Was MoQ im Vergleich zu SRT verändert
SRT (Secure Reliable Transport) glänzt beim Transport hochwertiger Medien von Punkt A nach Punkt B über unzuverlässige Netzwerke. Es bietet AES-Verschlüsselung, Paketverlustwiederherstellung über ARQ (Automatic Repeat Request) und adaptive Bitratenunterstützung. SRT ist weitverbreitet für Ingest-Workflows (Kameras zu Studios, Remote-Produktion zu Cloud-Encodern), dient aber auch als Punkt-zu-Punkt-Distributionsprotokoll — wie DJing Stream demonstriert.
MoQ und SRT dienen überlappenden, aber unterschiedlichen Zwecken:
SRT ist Punkt-zu-Punkt; MoQ ist publish/subscribe. SRT verbindet einen Sender mit einem Empfänger. MoQ unterstützt nativ die Eins-zu-Viele-Distribution über Relays.
SRT garantiert die Zustellung; MoQ kann darauf verzichten. Der ARQ-Mechanismus von SRT überträgt jedes verlorene Paket erneut, was eine verlustfreie Zustellung sicherstellt, aber bei Paketverlusten Latenz hinzufügt. MoQ kann für partielle Zuverlässigkeit konfiguriert werden — es verwirft verspätete Objekte, anstatt sie erneut zu übertragen — was für latenzempfindliche Live-Auslieferung besser ist, aber inakzeptabel, wenn jedes Sample zählt.
SRT ist ausgereift und im Einsatz; MoQ ist im Entstehen. SRT hat breite Hardware- und Software-Unterstützung (OBS, vMix, FFmpeg, Haivision, jeder große Encoder). MoQ hat Implementierungen im Frühstadium.
Wann SRT weiterhin die bessere Wahl ist
SRT ist die stärkere Wahl, wenn:
- Der Anwendungsfall Punkt-zu-Punkt ist (Quelle zu Encoder, Encoder zu Origin oder direkte Distribution zum Veranstaltungsort)
- Verlustfreie Zustellung wichtiger ist als die absolut minimale Latenz
- Der Workflow professionelle Broadcast-Ausrüstung einbezieht, die bereits SRT beherrscht
- Audiotreue auf Bit-Ebene nicht verhandelbar ist
Fallstudie: WeSpeakSports — Live-Fan-Kommentar über WebRTC
WeSpeakSports ist eine Plattform für Live-Fan-Audiokommentare. Fans erstellen oder hören Echtzeit-Audiokommentare während Sportveranstaltungen — Fußball, Basketball, Rugby, Formel 1 und mehr. Die App ist verfügbar für iPhone, iPad, Mac (Apple Silicon) und Vision Pro.
Die aktuelle Architektur verwendet WebRTC für Audio-Streaming. Ein Fan-Kommentator überträgt Audio von seinem Gerät, und Zuhörer empfangen es nahezu in Echtzeit. Das Audio hat Sprachqualität, nicht Musikqualität — Verständlichkeit und niedrige Latenz sind weitaus wichtiger als audiophile Klangtreue.
Wäre MoQ für WeSpeakSports sinnvoll?
Theoretisch ja — es ist ein hervorragend passender Anwendungsfall. WeSpeakSports ist eine 1-zu-Viele-Live-Audioübertragung mit Echtzeitanforderungen. Dies ist genau die Lücke, die MoQ füllen soll: zu viele Zuhörer für eine effiziente WebRTC-Skalierung, aber zu latenzempfindlich für HLS.
Das publish/subscribe-Modell von MoQ bildet die WeSpeakSports-Architektur natürlich ab: Ein Kommentator veröffentlicht einen Audio-Track, Zuhörer abonnieren ihn, und CDN-Relays übernehmen die Distribution. Dies wäre einfacher und kostengünstiger zu skalieren als eine WebRTC-SFU-Infrastruktur.
In der Praxis noch nicht — aus zwei handfesten Gründen:
- Safari/iOS ist fast so weit, aber noch nicht ganz. WeSpeakSports erfordert iOS 18.0. Die Hauptzielgruppe der App ist auf dem iPhone. MoQ im Browser hängt von WebTransport ab, das Apple in Safari 26.4 Beta hinzugefügt, aber noch nicht in einer stabilen Version ausgeliefert hat. Selbst für native iOS-Apps gibt es heute kein produktionsreifes MoQ-SDK für Apple-Plattformen. Der WebRTC-Stack auf iOS (über Apples integrierte WebKit-Unterstützung und ausgereifte Drittanbieter-SDKs) ist bewährt und funktioniert.
- Reife. WeSpeakSports ist ein ausgeliefertes Produkt mit realen Nutzern. Die Transportschicht von einem bewährten Protokoll auf eine Pre-1.0-Spezifikation umzustellen, wäre verfrüht. WebRTC bewältigt die aktuelle Skalierung. Der Komplexitätsaufwand einer Migration ist durch die aktuelle Nutzerbasis nicht gerechtfertigt.
Wann eine Neubewertung sinnvoll ist
MoQ wird für WeSpeakSports evaluierungswürdig, wenn:
- WebTransport in einer stabilen Safari-Version erscheint — was angesichts der Safari 26.4 Beta nun unmittelbar bevorsteht — und ein ausgereiftes natives MoQ-SDK für iOS/macOS verfügbar wird
- Die Nutzerbasis auf eine Größe wächst, bei der WebRTC-SFU-Kosten zu einer spürbaren Einschränkung werden
- MoQ-Relay-Infrastruktur bei mindestens zwei CDN-Anbietern mit SLA-Zusagen verfügbar ist
- Die MoQ-Transportspezifikation RFC-Status erreicht
Zu diesem Zeitpunkt könnte MoQ die Distributionsarchitektur spürbar vereinfachen und die Kosten pro Zuhörer senken. Das Modell Kommentator-zu-Relay-zu-Zuhörer ist ein Lehrbuchbeispiel für einen MoQ-Anwendungsfall. Es ist eine Frage des Timings, nicht der Eignung.
Fallstudie: DJing Stream — sendefähiges DJ-Audio über SRT
DJing Stream ist eine macOS-App, die für einen sehr spezifischen Anwendungsfall entwickelt wurde: das Streaming von sendefähigem Audio vom DJ-Setup zum Soundsystem eines Veranstaltungsortes, über das Internet, in Echtzeit. Die Architektur priorisiert Audioqualität über alles andere.
Der aktuelle Stack verwendet SRT für die Echtzeit-Distribution — die Übertragung von 24-Bit-PCM-Stereo-Audio bei 48 kHz (ungefähr 2,3 Mbit/s) vom Mac des DJs zum Soundsystem des Veranstaltungsortes. Für eine breitere Distribution an entfernte Zuhörer kann das Audio auch über HLS mit verlustfreiem Audio bereitgestellt werden. Die gesamte Designphilosophie besagt, dass das Audio eines DJs die gleiche Klangtreue wie eine physische Kabelverbindung verdient.
Wäre MoQ für DJing Stream sinnvoll?
Nein — und dies ist keine Frage des Timings. MoQ ist grundsätzlich nicht mit den Anforderungen von DJing Stream vereinbar.
Hier ist der Grund:
- Verlustfreie Zustellung ist nicht verhandelbar. DJing Stream sendet unkomprimiertes PCM-Audio. Jedes Sample zählt. Der ARQ-Mechanismus von SRT garantiert, dass jedes Paket ankommt — er fügt bei Verlusten lieber Latenz hinzu, als Audio zu verwerfen. Das Modell der partiellen Zuverlässigkeit von MoQ, das einer seiner Hauptvorteile für Live-Video ist, ist genau der falsche Kompromiss für sendefähiges Audio. Ein verworfener Audioframe ist ein hörbarer Störimpuls auf einem Club-Soundsystem. Das ist nicht akzeptabel.
- Punkt-zu-Punkt ist der primäre Anwendungsfall. Das Kernszenario von DJing Stream ist ein DJ, der an einen Veranstaltungsort streamt. Dies ist eine Punkt-zu-Punkt-Verbindung, kein Distributionsproblem. Das publish/subscribe-Relay-Modell von MoQ fügt für diese Topologie Komplexität ohne Nutzen hinzu.
- Keine Browser-Anforderung. DJing Stream ist eine native macOS-App, die sich mit Venue-Hardware verbindet. Es gibt keinen Webbrowser im Spiel. Die WebTransport/Safari-Lücke ist irrelevant — aber ebenso der Hauptvorteil von MoQ, die browser-native Auslieferung.
- SRT ist bereits das richtige Werkzeug. SRT wurde genau dafür entwickelt: zuverlässiger, verschlüsselter, latenzarmer Transport hochwertiger Medien über unzuverlässige Netzwerke. Es ist kampferprobt in der Broadcast-Produktion. Jeder Encoder und Medienserver beherrscht es. SRT durch MoQ für die DJ-zu-Venue-Distributionsverbindung zu ersetzen, würde bedeuten, garantierte Zustellung aufzugeben, ohne einen nennenswerten Gewinn.
- HLS Lossless deckt die Distributionsseite ab. Für den sekundären Anwendungsfall der Distribution an ein breiteres Publikum (Web-Zuhörer) ist HLS mit verlustfreien Audio-Codecs bewährt und mit jedem Gerät kompatibel. Die Latenztoleranz für entfernte Zuhörer ist höher als für den Veranstaltungsort selbst, sodass das segmentbasierte Modell von HLS vollkommen ausreichend ist.
Wann eine Neubewertung sinnvoll ist
Ehrlich gesagt? Wahrscheinlich nie für die Kern-DJ-zu-Venue-Verbindung. SRT macht genau das, was DJing Stream braucht, und die Designziele von MoQ (skalierbare Distribution mit akzeptablem Qualitätsverlust bei Überlastung) stehen im Widerspruch zu den Designzielen von DJing Stream (verlustfreie Zustellung jedes Audio-Samples).
Das einzige Szenario, in dem MoQ für DJing Stream relevant werden könnte, ist eine Produkterweiterung in Richtung großangelegter Fan-Distribution mit geringeren Klangtreue-Erwartungen — zum Beispiel das Streaming einer komprimierten Version eines DJ-Sets an Tausende von Zuhörern gleichzeitig. Aber selbst dann würden HLS oder LL-HLS wahrscheinlich einfacher und breiter kompatibel bleiben.
Das Entscheidungsframework
Nach umfangreicher Recherche zu MoQ — den IETF-Entwürfen, Branchenkommentaren von Broadpeak, Red5, BlogGeek.me, webrtcHacks, Meetecho und Nanocosmos — ist hier die einfachste Entscheidungsregel, die ich anbieten kann:
Behalten Sie Ihren aktuellen Stack, wenn
- Ihr Produkt heute ausgeliefert wird und Ihr aktuelles Protokoll funktioniert
- Sie heute Safari/iOS-Browser-Unterstützung benötigen (WebTransport ist in der Safari-Beta, aber noch nicht stabil)
- Einige Sekunden Latenz akzeptabel sind (→ HLS/LL-HLS)
- Sie garantierte verlustfreie Zustellung benötigen (→ SRT)
- Sie echte bidirektionale Echtzeitkommunikation benötigen (→ WebRTC)
Beginnen Sie mit der Evaluierung von MoQ, wenn
- Ultra-niedrige Latenz für große Zuschauerzahlen zum Kernwert Ihres Produkts gehört (Live-Wetten, Auktionen, synchronisierte Second-Screen-Erlebnisse)
- Sie den gesamten Stack vom Ingest bis zur Wiedergabe kontrollieren und ein neues Protokoll absorbieren können
- WebRTC-Skalierungskosten zu einem echten Geschäftsproblem werden
- Sie ein neues Produkt entwickeln, das erst Ende 2026 oder 2027 ausgeliefert wird
- Sie akzeptieren können, dass sich die Spezifikation vor Erreichen des RFC-Status noch ändern kann
Beobachten Sie MoQ aufmerksam, wenn
- Sie CDN- oder Relay-Infrastruktur betreiben (MoQ ist für die Zusammenarbeit mit HTTP/3-CDNs konzipiert)
- Sie Live-Sportprodukte mit Synchronisierungsanforderungen entwickeln
- Sie Ingest und Distribution auf ein einziges Protokoll zusammenführen möchten
- Sie vom Umpaketierungsaufwand bei RTMP/SRT-Ingest → HLS-Distribution frustriert sind
Das Fazit
MoQ ist real, es ist gut durchdacht und adressiert echte Limitierungen in der heutigen Streaming-Protokolllandschaft. Die Ambition — ein Protokoll für sowohl Echtzeit als auch Nahezu-Echtzeit, vom Ingest bis zur Distribution, mit CDN-skalierter Relay-Unterstützung — ist überzeugend.
Aber Ambition ist nicht dasselbe wie Einsatzbereitschaft. Die Spezifikation ist nicht finalisiert. Safari hat WebTransport in der Beta, aber noch nicht in einer stabilen Version. Produktionseinsätze beschränken sich auf Early Adopter. Das Ökosystem an SDKs, Tools und operativem Wissen, das HLS, WebRTC und SRT im Produktionseinsatz zuverlässig macht, existiert für MoQ schlicht noch nicht.
Für die meisten Streaming-Produkte, die 2026 ausgeliefert werden, ist MoQ etwas zum Beobachten — nicht zum Einführen. Wenn es reift, und das wird es, hat es das Potenzial, Architekturen zu vereinfachen, die derzeit mehrere Protokolle mit Umpaketierungsschichten dazwischen zusammenstückeln.
Bis dahin gilt: Wenn HLS für Ihre Auslieferung funktioniert, behalten Sie es. Wenn WebRTC für Ihre Echtzeitanforderungen funktioniert, behalten Sie es. Wenn SRT für Ihre Punkt-zu-Punkt-Verbindungen funktioniert, behalten Sie es. Das beste Protokoll ist dasjenige, das ausgeliefert wird und funktioniert, nicht dasjenige, das auf einer Konferenzfolie am aufregendsten ist.
Quellen
- IETF MoQ Transport-Entwurf (v17, März 2026): datatracker.ietf.org/doc/draft-ietf-moq-transport
- IETF MoQ-Charta: datatracker.ietf.org/group/moq/about
- moq-lite-Entwurf: ietf.org/archive/id/draft-lcurley-moq-lite-02.html
- IETF Blog — What's the deal with MoQ: ietf.org/blog/moq-overview
- BlogGeek.me — MOQ: How it will redefine realtime media: bloggeek.me/moq-redefine-realtime
- webrtcHacks — WebRTC vs. MoQ by Use Case: webrtchacks.com/webrtc-vs-moq-by-use-case
- RFC 8216 (HLS): rfc-editor.org/rfc/rfc8216.html
- Apple HLS-Übersicht: developer.apple.com/streaming
- WebKit — Announcing Interop 2026 (WebTransport-Verpflichtung): webkit.org/blog/17818/announcing-interop-2026
- MoQ CDN — Open-source MoQ CDN relay infrastructure: moqcdn.net
- Erik Herz on LinkedIn: linkedin.com/in/erikherz