Media over QUIC — MoQ — is het meest besproken opkomende streamingprotocol van 2025-2026. Blogposts vermenigvuldigen zich, conferentiepresentaties stapelen zich op, en CDN-leveranciers racen om ondersteuning aan te kondigen. Als je in livestreaming werkt, is je waarschijnlijk al gevraagd: moeten we overstappen op MoQ?
Het korte antwoord, voor de meeste producten die vandaag in productie zijn, is nee — nog niet. Maar MoQ is het waard om te begrijpen, omdat de problemen die het oplost reëel zijn, en de tijdlijn om productieklaar te worden nu in kwartalen wordt gemeten, niet in jaren.
Dit artikel legt uit wat MoQ werkelijk is, waar het staat per maart 2026, wat het verandert ten opzichte van HLS, WebRTC en SRT — en of het zinvol zou zijn voor twee praktijkproducten die wij hebben uitgerold: WeSpeakSports (live fan-audiocommentaar via WebRTC) en DJing Stream (broadcast-kwaliteit DJ-audio via SRT en HLS Lossless).
Wat MoQ werkelijk is
MoQ staat voor Media over QUIC. Het is een IETF-werkgroepproject dat in 2022 is gestart om een nieuw medialeveringsprotocol te definiëren, gebouwd bovenop QUIC (de transportlaag achter HTTP/3).
De kerntransportspecificatie, draft-ietf-moq-transport, bereikte versie 17 in maart 2026. Een streamingformaatspecificatie (draft-ietf-moq-msf) is ook in ontwikkeling, samen met aanvullende concepten voor CMAF-packaging en headercompressie. Geen van deze zijn al definitieve RFCs.
In de kern is MoQ een publish/subscribe-protocol. Een uitgever stuurt benoemde media-objecten (audioframes, videoframes, metadata) naar relays, en abonnees ontvangen deze door zich te abonneren op benoemde tracks. Dit is fundamenteel anders dan zowel HLS (HTTP-verzoek/antwoord voor segmenten) als WebRTC (peer-to-peer sessienegotiatie met SDP/ICE).
MoQ draait op QUIC-streams en -datagrammen, ofwel native ofwel via WebTransport (de browser-API voor QUIC). Dit geeft het toegang tot QUIC's multiplexing, prioritering en gedeeltelijke betrouwbaarheidsfuncties — wat betekent dat het protocol bij ontwerp een laat videoframe kan laten vallen in plaats van de hele stream te blokkeren in afwachting van hertransmissie.
Wat MoQ probeert te vervangen
Zoals Cullen Jennings van Cisco (een deelnemer aan de MoQ-werkgroep) het formuleert, heeft de streamingwereld momenteel twee silo's. Aan de ene kant leveren diensten zoals Netflix en YouTube media op schaal via HTTP-gebaseerde CDNs, maar met seconden vertraging. Aan de andere kant leveren conferentietools zoals Zoom en WebRTC-gebaseerde platformen media in bijna-realtime, maar kunnen niet kosteneffectief opschalen naar een groot publiek.
MoQ wil een brug slaan tussen deze twee werelden met één enkel protocol dat zowel realtime als bijna-realtime toepassingen kan bedienen, van contributie (ingest) via distributie (levering aan kijkers), met CDN-compatibele relay-infrastructuur ertussen.
Waar MoQ vandaag staat (maart 2026)
Laten we precies zijn over de huidige status:
De specificatie is bijna klaar maar nog niet af. Het transportconcept is bij versie 17, met snelle iteraties. Het streamingformaatconcept is gepubliceerd in januari 2026. Er wordt actief gewerkt aan aanvullende specificaties voor CMAF-packaging en headercompressie. Maar er is nog geen geratificeerde RFC.
De Safari/WebTransport-kloof wordt kleiner. MoQ in de browser is afhankelijk van WebTransport, dat HTTP/3 en QUIC vereist. Chrome en Firefox ondersteunen WebTransport al. Safari was de achterblijver — maar Apple heeft WebTransport-ondersteuning toegevoegd in Safari 26.4 beta (februari 2026), en het is een officieel Interop 2026-commitment van WebKit. Per maart 2026 is dit nog niet uitgebracht in een stabiele Safari-versie, maar het is niet langer een kwestie van of — alleen wanneer in de volgende OS-cyclus. Voor producten die iPhone- en iPad-gebruikers via een browser targeten, is de kloof bijna gedicht.
Vroege productie-implementaties bestaan maar zijn beperkt. Nanocosmos demonstreerde end-to-end MoQ-levering (OBS-ingest naar wereldwijd publiek) op het MonteVIDEO Summer Project. Cloudflare lanceerde een MoQ-bèta. Red5 kondigde aan dat MoQ-ondersteuning eind 2026 beschikbaar zou zijn. Maar dit zijn early-adopter-implementaties, geen reguliere infrastructuur.
De gemeenschap is eerlijk over de volwassenheid. Zelfs Luke Curley, die een van de eerste MoQ-implementaties bij Twitch (nu Discord) bouwde en het moq-lite-vereenvoudigingsconcept schreef, stelt expliciet dat de volledige MoQ-transportspecificatie "te ingewikkeld is geworden" met "te veel berichten, optionele modi en halfbakken functies." Zijn moq-lite-concept is een reactie op deze complexiteit.
Industrie-veteranen zijn terughoudend. Tsahi Levent-Levi van BlogGeek.me voorspelde dat ontwikkelaars in 2026 meer zouden klagen over WebRTC dan over MoQ — niet omdat MoQ beter is, maar omdat MoQ-gebruikers nog steeds early adopters zijn die ruwe kantjes verwachten. WebRTC is degene die overal in productie is en het gewicht draagt van de verwachtingen uit de echte wereld.
Wat MoQ verandert ten opzichte van HLS
HLS (HTTP Live Streaming) werkt door media op te splitsen in segmenten, deze naar een HTTP-server te schrijven, en spelers te laten pollen naar nieuwe segmenten via playlists. Het is volwassen, CDN-vriendelijk, breed ingezet en goed gedocumenteerd in RFC 8216 en Apple's HLS Authoring Specification. Low-Latency HLS (LL-HLS) drukt de vertraging terug naar ongeveer 2-4 seconden.
MoQ verandert het leveringsmodel op verschillende manieren:
Van pollen naar push. HLS-spelers vragen segmenten op. MoQ-abonnees ontvangen objecten zodra ze worden gepubliceerd. Dit elimineert pollingvertraging.
Van segmenten naar objecten. HLS werkt op basis van meersecondensegmenten (of deelsegmenten in LL-HLS). MoQ kan op frameniveau werken. Een enkel videoframe of audioframe kan een individueel adresseerbaar, individueel leverbaar object zijn.
Van TCP naar QUIC. HLS draait over HTTP/TCP. Wanneer een TCP-pakket verloren gaat, blokkeert alles erachter (head-of-line blocking). MoQ draait over QUIC, waar streams onafhankelijk zijn — een verloren pakket op één stream blokkeert de andere niet.
Expliciete prioritering. Het transportconcept van MoQ definieert prioriteit en bezorgvolgorde op protocolniveau. Bij congestie kan een relay objecten met lagere prioriteit laten vallen (bijv. B-frames) in plaats van alles gelijkmatig te vertragen.
Geünificeerde ingest en distributie. Tegenwoordig gebruiken de meeste live-workflows één protocol voor contributie (RTMP, SRT, WHIP) en een ander voor distributie (HLS, DASH). MoQ kan mogelijk beide paden bedienen met één enkel protocol, waardoor de herverpakkingsstap bij de origin-server wordt geëlimineerd.
Wanneer HLS nog steeds wint
Dit alles betekent niet dat HLS verouderd is. HLS blijft de sterkere keuze wanneer:
- Een paar seconden vertraging volkomen acceptabel zijn
- Brede apparaatcompatibiliteit essentieel is (elke telefoon, TV en set-top box speelt HLS af)
- De bestaande CDN- en toolinginvestering goed werkt
- Operationele eenvoud en beproefde betrouwbaarheid belangrijker zijn dan het verder verlagen van de vertraging
Voor standaard OTT live- en VOD-levering — wat het overgrote deel van het streamingverkeer uitmaakt — is HLS niet kapot, en lost MoQ geen probleem op dat bestaat.
Wat MoQ verandert ten opzichte van WebRTC
WebRTC is ontworpen voor realtime peer-to-peer communicatie: videobellen, schermdeling, één-op-één of kleine groepsgesprekken. De industrie heeft het ver voorbij dat oorspronkelijke doel opgerekt, met SFU-architecturen (Selective Forwarding Unit) om WebRTC op te schalen naar een groter publiek.
MoQ verschilt op verschillende belangrijke manieren van WebRTC:
Architectuur. WebRTC is fundamenteel een sessiegeoriënteerd peer-to-peer protocol, zelfs wanneer het via SFUs wordt bemiddeld. MoQ is een client-server publish/subscribe-protocol dat vanaf het begin is ontworpen rond relays en CDN-achtige distributie.
Schaalbaarheidsmodel. Het opschalen van WebRTC vereist SFU-infrastructuur die specifiek gebouwd en kostbaar is. MoQ-relays zijn ontworpen om te integreren met bestaande CDN-infrastructuur — HTTP/3-servers kunnen worden uitgebreid om MoQ-verkeer te verwerken, wat de reden is dat CDN-leveranciers zoals Akamai en YouTube actief betrokken zijn.
Complexiteit. WebRTC brengt aanzienlijke complexiteit met zich mee: SDP offer/answer-onderhandeling, ICE-kandidaatverzameling, STUN/TURN-servers voor NAT-traversal, SRTP voor encryptie, SCTP voor datakanalen. De verbindingsopbouw van MoQ is eenvoudiger — een QUIC-handshake gevolgd door subscribe/publish-berichten.
Codecflexibiliteit. De codeconderhandeling van WebRTC is nauw gekoppeld aan het protocol. MoQ is codec-agnostisch op transportniveau — het mediaformaat wordt afgehandeld door de applicatielaag (MSF, LOC of aangepaste containers).
Browserafhankelijkheid. Beide protocollen zijn afhankelijk van browser-API's voor webgebaseerde levering. WebRTC heeft universele browserondersteuning. MoQ is afhankelijk van WebTransport, dat Safari pas net in bèta heeft toegevoegd (26.4, februari 2026) en nog niet stabiel is uitgebracht. Deze kloof wordt kleiner, maar is vandaag nog een praktische overweging voor MoQ.
Wanneer WebRTC nog steeds wint
WebRTC blijft de betere keuze wanneer:
- Echte bidirectionele realtimecommunicatie nodig is (videobellen, vergaderen)
- Browsercompatibiliteit over alle platformen inclusief Safari/iOS vereist is
- De toepassing peer-to-peer of kleine groep is zonder behoefte aan CDN-schaal distributie
- Bewezen, productieklare tooling en SDK-volwassenheid belangrijk zijn
Wat MoQ verandert ten opzichte van SRT
SRT (Secure Reliable Transport) blinkt uit in het verplaatsen van hoogwaardige media van punt A naar punt B over onvoorspelbare netwerken. Het biedt AES-encryptie, pakketverlieshersstel via ARQ (Automatic Repeat Request) en ondersteuning voor adaptieve bitrate. SRT is breed geadopteerd voor ingestworkflows (camera's naar studio's, remote productie naar cloud-encoders) maar dient ook als punt-naar-punt distributieprotocol — zoals DJing Stream aantoont.
MoQ en SRT bedienen overlappende maar verschillende doelen:
SRT is punt-naar-punt; MoQ is publish/subscribe. SRT verbindt één zender met één ontvanger. MoQ ondersteunt van nature één-naar-velen distributie via relays.
SRT garandeert levering; MoQ kan ervoor kiezen dat niet te doen. Het ARQ-mechanisme van SRT hertransmitteert elk verloren pakket, wat verliesloze levering garandeert maar vertraging toevoegt bij pakketverlies. MoQ kan worden geconfigureerd voor gedeeltelijke betrouwbaarheid — late objecten laten vallen in plaats van ze opnieuw te verzenden — wat beter is voor latentiegevoelige live-levering maar onacceptabel wanneer elk sample ertoe doet.
SRT is volwassen en uitgerold; MoQ is opkomend. SRT heeft brede hardware- en softwareondersteuning (OBS, vMix, FFmpeg, Haivision, elke grote encoder). MoQ heeft implementaties in een vroeg stadium.
Wanneer SRT nog steeds wint
SRT is de sterkere keuze wanneer:
- De toepassing punt-naar-punt is (bron naar encoder, encoder naar origin, of directe levering aan de locatie)
- Verliesloze levering belangrijker is dan de absoluut minimale vertraging
- De workflow professionele broadcast-apparatuur omvat die al SRT spreekt
- Audiogetrouwheid op bitniveau niet-onderhandelbaar is
Casestudy: WeSpeakSports — live fancommentaar via WebRTC
WeSpeakSports is een platform voor live fan-audiocommentaar. Fans maken of beluisteren realtime audiocommentaar tijdens sportwedstrijden — voetbal, basketbal, rugby, F1 en meer. De app is beschikbaar op iPhone, iPad, Mac (Apple Silicon) en Vision Pro.
De huidige architectuur gebruikt WebRTC voor audiostreaming. Een fancommentator zendt audio uit vanaf zijn apparaat, en luisteraars ontvangen het in bijna-realtime. De audio is spraakkwaliteit, geen muziekkwaliteit — verstaanbaarheid en lage vertraging zijn veel belangrijker dan audiofieletrouw.
Zou MoQ zinvol zijn voor WeSpeakSports?
In theorie wel — het is een uitstekende match voor deze toepassing. WeSpeakSports is een 1-naar-velen live audio-uitzending met realtimeverwachtingen. Dit is precies de kloof die MoQ wil opvullen: te veel luisteraars voor efficiënte WebRTC-opschaling, maar te latentiegevoelig voor HLS.
Het publish/subscribe-model van MoQ sluit op een natuurlijke manier aan bij de WeSpeakSports-architectuur: een commentator publiceert een audiotrack, luisteraars abonneren zich erop, en CDN-relays verzorgen de distributie. Dit zou eenvoudiger en goedkoper op te schalen zijn dan WebRTC SFU-infrastructuur.
In de praktijk nog niet — om twee harde redenen:
- Safari/iOS is er bijna, maar nog niet. WeSpeakSports vereist iOS 18.0. Het primaire publiek van de app zit op iPhone. MoQ in de browser is afhankelijk van WebTransport, dat Apple heeft toegevoegd in Safari 26.4 beta maar nog niet in een stabiele versie heeft uitgebracht. Zelfs voor native iOS-apps is er vandaag geen productieklare MoQ SDK voor Apple-platformen. De WebRTC-stack op iOS (via Apple's ingebouwde WebKit-ondersteuning en volwassen SDK's van derden) is bewezen en werkt.
- Volwassenheid. WeSpeakSports is een uitgebracht product met echte gebruikers. De transportlaag vervangen van een bewezen protocol naar een pre-1.0-specificatie zou voorbarig zijn. WebRTC handelt de huidige schaal goed af. De complexiteitskosten van migratie worden niet gerechtvaardigd door het huidige gebruikersbestand.
Wanneer opnieuw evalueren
MoQ wordt het evalueren waard voor WeSpeakSports wanneer:
- WebTransport uitkomt in stabiel Safari — wat nu op handen is gezien de Safari 26.4 beta — en een volwassen native MoQ SDK voor iOS/macOS verschijnt
- Het gebruikersbestand groeit naar een schaal waarbij WebRTC SFU-kosten een betekenisvolle beperking worden
- MoQ relay-infrastructuur beschikbaar is bij ten minste twee CDN-providers met SLA-commitments
- De MoQ-transportspecificatie RFC-status bereikt
Op dat moment zou MoQ de distributiearchitectuur aanzienlijk kunnen vereenvoudigen en de kosten per luisteraar kunnen verlagen. Het commentator-naar-relay-naar-luisteraars-model is een schoolvoorbeeld van een MoQ-toepassing. Het is een kwestie van timing, niet van geschiktheid.
Casestudy: DJing Stream — broadcast-kwaliteit DJ-audio via SRT
DJing Stream is een macOS-app ontworpen voor een zeer specifieke toepassing: het streamen van broadcast-kwaliteit audio van een DJ-setup naar het geluidssysteem van een locatie, via het internet, in realtime. De architectuur geeft audiogetrouwheid de hoogste prioriteit.
De huidige stack gebruikt SRT voor realtime distributie — het leveren van 24-bit PCM stereo-audio op 48 kHz (ongeveer 2,3 Mbps) van de Mac van de DJ naar het geluidssysteem van de locatie. Voor bredere distributie aan luisteraars op afstand kan de audio ook worden geleverd via HLS met verliesloze audio. De volledige ontwerpfilosofie is dat de audio van een DJ dezelfde getrouwheid verdient als een fysieke kabelverbinding.
Zou MoQ zinvol zijn voor DJing Stream?
Nee — en dit is geen kwestie van timing. MoQ is fundamenteel niet afgestemd op de vereisten van DJing Stream.
Dit is waarom:
- Verliesloze levering is niet-onderhandelbaar. DJing Stream stuurt ongecomprimeerde PCM-audio. Elk sample telt. Het ARQ-hertransmissiemechanisme van SRT garandeert dat elk pakket aankomt — het voegt vertraging toe bij verlies in plaats van audio te laten vallen. Het gedeeltelijke betrouwbaarheidsmodel van MoQ, dat een van de belangrijkste voordelen is voor live video, is precies de verkeerde afweging voor broadcast-kwaliteit audio. Een weggevallen audioframe is een hoorbare glitch op een clubgeluidssysteem. Dat is niet acceptabel.
- Punt-naar-punt is de primaire toepassing. Het kernscenario van DJing Stream is één DJ die streamt naar één locatie. Dit is een punt-naar-punt verbinding, geen distributieprobleem. Het publish/subscribe relay-model van MoQ voegt complexiteit toe zonder voordeel voor deze topologie.
- Geen browservereiste. DJing Stream is een native macOS-app die verbinding maakt met locatiehardware. Er zit geen webbrowser in de keten. De WebTransport/Safari-kloof is irrelevant, maar dat geldt ook voor het belangrijkste voordeel van MoQ: browser-native levering.
- SRT is al het juiste gereedschap. SRT is ontworpen voor precies dit: betrouwbaar, versleuteld, laaglatent transport van hoogwaardige media over onvoorspelbare netwerken. Het is beproefd in broadcast-productie. Elke encoder en mediaserver spreekt het. SRT vervangen door MoQ voor de DJ-naar-locatie distributielink zou betekenen dat je gegarandeerde levering opgeeft zonder noemenswaardig voordeel.
- HLS Lossless dekt de distributiekant. Voor de secundaire toepassing van distributie aan een breder publiek (webluisteraars) is HLS met verliesloze audiocodecs bewezen en compatibel met elk apparaat. De vertragingstolerantie voor luisteraars op afstand is hoger dan voor de locatie zelf, dus het segmentgebaseerde model van HLS is volkomen toereikend.
Wanneer opnieuw evalueren
Eerlijk gezegd? Waarschijnlijk nooit voor de kern DJ-naar-locatie verbinding. SRT doet precies wat DJing Stream nodig heeft, en de ontwerpdoelen van MoQ (schaalbare distributie met acceptabel kwaliteitsverlies bij congestie) staan tegenover de ontwerpdoelen van DJing Stream (nulverlies levering van elk audiosample).
Het enige scenario waarin MoQ relevant zou kunnen worden voor DJing Stream is als het product uitbreidt richting grootschalige fandistributie met lagere getrouwheidsverwachtingen — bijvoorbeeld het streamen van een gecomprimeerde versie van een DJ-set naar duizenden luisteraars tegelijk. Zelfs dan zouden HLS of LL-HLS waarschijnlijk eenvoudiger en breder compatibel blijven.
Het beslissingskader
Na uitgebreid onderzoek naar MoQ — de IETF-concepten, branchecommentaar van Broadpeak, Red5, BlogGeek.me, webrtcHacks, Meetecho en Nanocosmos — is dit de eenvoudigste beslisregel die ik kan bieden:
Behoud je huidige stack wanneer
- Je product vandaag in productie is en je huidige protocol werkt
- Je vandaag Safari/iOS-browserondersteuning nodig hebt (WebTransport is in Safari-bèta maar nog niet stabiel)
- Een paar seconden vertraging acceptabel zijn (→ HLS/LL-HLS)
- Je gegarandeerde verliesloze levering nodig hebt (→ SRT)
- Je echte bidirectionele realtimecommunicatie nodig hebt (→ WebRTC)
Begin MoQ te evalueren wanneer
- Ultralage vertraging naar een groot publiek de kern is van je productwaarde (live wedden, veilingen, gesynchroniseerde second-screen ervaringen)
- Je de volledige stack beheerst van ingest tot afspelen en een nieuw protocol kunt absorberen
- WebRTC-opschalingskosten een echt zakelijk probleem worden
- Je een nieuw product bouwt dat pas eind 2026 of 2027 wordt uitgebracht
- Je kunt accepteren dat de specificatie mogelijk nog wijzigt voordat deze RFC-status bereikt
Houd MoQ goed in de gaten als
- Je CDN- of relay-infrastructuur beheert (MoQ is ontworpen om te werken met HTTP/3 CDNs)
- Je live sportproducten bouwt met synchronisatievereisten
- Je ingest en distributie op één enkel protocol wilt samenbrengen
- Je gefrustreerd bent door de herverpakkingsoverhead van RTMP/SRT-ingest → HLS-distributie
De conclusie
MoQ is echt, het is goed ontworpen, en het adresseert echte beperkingen in het huidige landschap van streamingprotocollen. De ambitie — één protocol voor zowel realtime als bijna-realtime, van ingest tot distributie, met CDN-schaal relay-ondersteuning — is overtuigend.
Maar ambitie is niet hetzelfde als gereedheid. De specificatie is niet afgerond. Safari heeft WebTransport in bèta maar nog niet in een stabiele release. Productie-implementaties zijn beperkt tot early adopters. Het ecosysteem van SDK's, tools en operationele kennis dat HLS, WebRTC en SRT betrouwbaar maakt in productie, bestaat simpelweg nog niet voor MoQ.
Voor de meeste streamingproducten die in 2026 in productie gaan, is MoQ iets om te volgen — niet iets om te adopteren. Wanneer het volwassen wordt, en dat zal het, heeft het de potentie om architecturen te vereenvoudigen die momenteel meerdere protocollen aan elkaar rijgen met herverpakkingslagen ertussen.
Tot die tijd: als HLS werkt voor je levering, behoud het. Als WebRTC werkt voor je realtimebehoeften, behoud het. Als SRT werkt voor je punt-naar-punt verbindingen, behoud het. Het beste protocol is dat wat in productie is en werkt, niet dat wat het meest opwindend is op een conferentiedia.
Bronnen
- IETF MoQ Transport-concept (v17, maart 2026): datatracker.ietf.org/doc/draft-ietf-moq-transport
- IETF MoQ Charter: datatracker.ietf.org/group/moq/about
- moq-lite-concept: 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-overzicht: developer.apple.com/streaming
- WebKit — Announcing Interop 2026 (WebTransport-commitment): 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