Media over QUIC — MoQ — er den mest diskuterte fremvoksende strømmeprotokollen i 2025-2026. Blogginnlegg formerer seg, konferanseforedrag hoper seg opp, og CDN-leverandører kappløper om å annonsere støtte. Hvis du jobber med direktestrømming, har du sannsynligvis blitt spurt: bør vi bytte til MoQ?
Det korte svaret, for de fleste produkter som leveres i dag, er nei — ikke ennå. Men MoQ er verdt å forstå, fordi problemene det løser er reelle, og tidslinjen for at det blir produksjonsklart måles nå i kvartaler, ikke år.
Denne artikkelen forklarer hva MoQ faktisk er, hvor det står per mars 2026, hva det endrer sammenlignet med HLS, WebRTC og SRT — og om det ville gi mening for to virkelige produkter vi har levert: WeSpeakSports (live lydkommentar fra fans over WebRTC) og DJing Stream (kringkastingskvalitet DJ-lyd over SRT og HLS Lossless).
Hva MoQ faktisk er
MoQ står for Media over QUIC. Det er et IETF-arbeidsgruppe-initiativ startet i 2022, for å definere en ny medieleveringsprotokoll bygget på toppen av QUIC (transportlaget bak HTTP/3).
Kjernetransportspesifikasjonen, draft-ietf-moq-transport, nådde versjon 17 i mars 2026. En strømmeformatspesifikasjon (draft-ietf-moq-msf) er også under utarbeidelse, sammen med tilhørende utkast for CMAF-pakking og header-komprimering. Ingen av disse er ferdigstilte RFC-er ennå.
I sin kjerne er MoQ en publish/subscribe-protokoll. En utgiver sender navngitte medieobjekter (lydbilder, videobilder, metadata) til releer, og abonnenter mottar dem ved å abonnere på navngitte spor. Dette er fundamentalt forskjellig fra både HLS (HTTP forespørsel/svar for segmenter) og WebRTC (peer-to-peer-sesjonsforhandling med SDP/ICE).
MoQ kjører over QUIC-strømmer og datagrammer, enten direkte eller via WebTransport (nettleser-API-et for QUIC). Dette gir tilgang til QUICs multipleksing, prioritering og delvis pålitelighetsfunksjoner — noe som betyr at protokollen, etter design, kan forkaste et forsinket videobilde i stedet for å stoppe hele strømmen mens den venter på overføring på nytt.
Hva MoQ prøver å erstatte
Som Cullen Jennings fra Cisco (en deltaker i MoQ-arbeidsgruppen) uttrykker det, har strømmeverdenen for tiden to siloer. På den ene siden leverer tjenester som Netflix og YouTube medier i stor skala gjennom HTTP-baserte CDN-er, men med sekunders forsinkelse. På den andre siden leverer konferanseverktøy som Zoom og WebRTC-baserte plattformer medier i nær-sanntid, men kan ikke skalere kostnadseffektivt til store publikum.
MoQ har som mål å bygge bro mellom disse to verdenene med en enkelt protokoll som kan betjene både sanntids- og nær-sanntids-bruksscenarier, fra innsamling (inntak) gjennom distribusjon (levering til seere), med CDN-kompatibel reléinfrastruktur i mellom.
Hvor MoQ står i dag (mars 2026)
La oss være presise om nåværende status:
Spesifikasjonen er nær, men ikke ferdig. Transportutkastet er på versjon 17 og itererer raskt. Strømmeformatutkastet ble publisert i januar 2026. Det pågår aktivt tilleggsarbeid med CMAF-pakking og header-komprimering. Men det finnes ingen ratifisert RFC ennå.
Safari/WebTransport-gapet lukkes. MoQ i nettleseren avhenger av WebTransport, som krever HTTP/3 og QUIC. Chrome og Firefox støtter allerede WebTransport. Safari var etternøleren — men Apple la til WebTransport-støtte i Safari 26.4 beta (februar 2026), og det er en offisiell Interop 2026-forpliktelse fra WebKit. Per mars 2026 har dette ennå ikke blitt levert i en stabil Safari-utgivelse, men det er ikke lenger et spørsmål om om — bare når i neste OS-syklus. For produkter som retter seg mot iPhone- og iPad-brukere gjennom en nettleser, er gapet nesten lukket.
Tidlige produksjonsimplementeringer finnes, men er begrenset. Nanocosmos demonstrerte ende-til-ende MoQ-levering (OBS-inntak til globalt publikum) ved MonteVIDEO Summer Project. Cloudflare lanserte en MoQ-beta. Red5 annonserte MoQ-støtte innen utgangen av 2026. Men dette er tidlig-adoptør-implementeringer, ikke mainstream-infrastruktur.
Fellesskapet er ærlig om modenhet. Selv Luke Curley, som bygget en av de tidligste MoQ-implementasjonene hos Twitch (nå Discord) og forfattet moq-lite-forenklingsutkastet, sier eksplisitt at den fullstendige MoQ-transportspesifikasjonen «har blitt for komplisert» med «for mange meldinger, valgfrie moduser og halvferdige funksjoner.» Hans moq-lite-utkast er et svar på denne kompleksiteten.
Bransjeveteraner er målt i sine uttalelser. Tsahi Levent-Levi fra BlogGeek.me spådde at utviklere i 2026 ville klage mer over WebRTC enn MoQ — ikke fordi MoQ er bedre, men fordi MoQ-brukere fortsatt er tidlige adoptører som forventer ru kanter. WebRTC er den som er i produksjon overalt og bærer vekten av virkelige forventninger.
Hva MoQ endrer sammenlignet med HLS
HLS (HTTP Live Streaming) fungerer ved å dele medier i segmenter, skrive dem til en HTTP-server og la spillere hente nye segmenter via spillelister. Det er modent, CDN-vennlig, bredt utrullet og godt dokumentert i RFC 8216 og Apples HLS Authoring Specification. Low-Latency HLS (LL-HLS) presser forsinkelsen ned til omtrent 2-4 sekunder.
MoQ endrer leveringsmodellen på flere måter:
Fra henting til push. HLS-spillere ber om segmenter. MoQ-abonnenter mottar objekter etter hvert som de publiseres. Dette eliminerer henteforsinkelse.
Fra segmenter til objekter. HLS opererer med flersekunderssegmenter (eller delvise segmenter i LL-HLS). MoQ kan operere på bildenivå. Et enkelt videobilde eller lydbilde kan være et individuelt adresserbart, individuelt leverbart objekt.
Fra TCP til QUIC. HLS kjører over HTTP/TCP. Når en TCP-pakke går tapt, stopper alt bak den (head-of-line-blokkering). MoQ kjører over QUIC, der strømmer er uavhengige — en tapt pakke på én strøm blokkerer ikke andre.
Eksplisitt prioritering. MoQs transportutkast definerer prioritet og leveringsrekkefølge på protokollnivå. Under overbelastning kan et relé forkaste lavere prioriterte objekter (f.eks. B-frames) i stedet for å forsinke alt likt.
Enhetlig inntak og distribusjon. I dag bruker de fleste direktearbeidsflyter én protokoll for innsamling (RTMP, SRT, WHIP) og en annen for distribusjon (HLS, DASH). MoQ kan potensielt betjene begge veier med en enkelt protokoll, og eliminerer ompakkingssteget på opprinnelsesserveren.
Når HLS fortsatt vinner
Ingenting av dette betyr at HLS er utdatert. HLS forblir det sterkere valget når:
- Noen sekunders forsinkelse er helt akseptabelt
- Bred enhetskompatibilitet er essensielt (hver telefon, TV og set-top-boks spiller HLS)
- Den eksisterende CDN- og verktøyinvesteringen fungerer godt
- Operasjonell enkelhet og kamptestet pålitelighet betyr mer enn å presse forsinkelsen lavere
For standard OTT direkte og VOD-levering — som utgjør det overveldende flertallet av strømmetrafikk — er HLS ikke ødelagt, og MoQ fikser ikke et problem som eksisterer.
Hva MoQ endrer sammenlignet med WebRTC
WebRTC ble designet for sanntids peer-to-peer-kommunikasjon: videosamtaler, skjermdeling, én-til-én eller smågruppsamtaler. Bransjen har strukket det langt utover det opprinnelige omfanget, ved å bruke SFU-arkitekturer (Selective Forwarding Unit) for å skalere WebRTC til større publikum.
MoQ skiller seg fra WebRTC på flere viktige måter:
Arkitektur. WebRTC er fundamentalt en sesjonsorientert peer-to-peer-protokoll, selv når den formidles gjennom SFU-er. MoQ er en klient-server publish/subscribe-protokoll designet rundt releer og CDN-stil distribusjon fra starten.
Skaleringsmodell. Skalering av WebRTC krever SFU-infrastruktur som er spesialbygget og kostbar. MoQ-releer er designet for å integreres med eksisterende CDN-infrastruktur — HTTP/3-servere kan utvides til å håndtere MoQ-trafikk, noe som er grunnen til at CDN-leverandører som Akamai og YouTube er aktivt involvert.
Kompleksitet. WebRTC bærer med seg betydelig kompleksitet: SDP tilbud/svar-forhandling, ICE-kandidatinnsamling, STUN/TURN-servere for NAT-gjennomgang, SRTP for kryptering, SCTP for datakanaler. MoQs tilkoblingsoppsett er enklere — et QUIC-håndtrykk etterfulgt av subscribe/publish-meldinger.
Kodek-fleksibilitet. WebRTCs kodek-forhandling er tett koblet til protokollen. MoQ er kodek-agnostisk på transportnivå — medieformat håndteres av applikasjonslaget (MSF, LOC eller tilpassede containere).
Nettleseravhengighet. Begge protokoller avhenger av nettleser-API-er for nettbasert levering. WebRTC har universell nettleserstøtte. MoQ avhenger av WebTransport, som Safari nettopp har lagt til i beta (26.4, februar 2026) og ennå ikke har levert stabilt. Dette gapet lukkes, men er fortsatt en praktisk vurdering for MoQ i dag.
Når WebRTC fortsatt vinner
WebRTC forblir det bedre valget når:
- Ekte toveis sanntidskommunikasjon er nødvendig (videosamtaler, konferanser)
- Nettleserkompatibilitet på tvers av alle plattformer inkludert Safari/iOS er påkrevd
- Bruksscenariet er peer-to-peer eller smågrupper uten behov for CDN-skala distribusjon
- Bevist, produksjonsklar verktøy- og SDK-modenhet betyr noe
Hva MoQ endrer sammenlignet med SRT
SRT (Secure Reliable Transport) utmerker seg i å flytte høykvalitetsmedier fra punkt A til punkt B over uforutsigbare nettverk. Det gir AES-kryptering, pakketapsgjenoppretting via ARQ (Automatic Repeat Request) og adaptiv bitratestøtte. SRT er bredt adoptert for inntaksarbeidsflyter (kameraer til studioer, fjernproduksjon til skybaserte kodere), men fungerer også som en punkt-til-punkt-distribusjonsprotokoll — som DJing Stream demonstrerer.
MoQ og SRT tjener overlappende, men forskjellige formål:
SRT er punkt-til-punkt; MoQ er publish/subscribe. SRT kobler én avsender til én mottaker. MoQ støtter naturlig én-til-mange-distribusjon gjennom releer.
SRT garanterer levering; MoQ kan velge å ikke gjøre det. SRTs ARQ-mekanisme sender alle tapte pakker på nytt, noe som sikrer tapsfri levering, men legger til forsinkelse ved pakketap. MoQ kan konfigureres for delvis pålitelighet — forkaste forsinkede objekter i stedet for å sende dem på nytt — noe som er bedre for direktelevering med lav forsinkelse, men uakseptabelt når hvert sample teller.
SRT er modent og utrullet; MoQ er fremvoksende. SRT har bred maskinvare- og programvarestøtte (OBS, vMix, FFmpeg, Haivision, alle store kodere). MoQ har tidligfaseimplementasjoner.
Når SRT fortsatt vinner
SRT er det sterkere valget når:
- Bruksscenariet er punkt-til-punkt (kilde til koder, koder til opprinnelse, eller direkte-til-sted-distribusjon)
- Tapsfri levering betyr mer enn absolutt minimum forsinkelse
- Arbeidsflyten involverer profesjonelt kringkastingsutstyr som allerede snakker SRT
- Lydtroskap på bitnivå er ikke-forhandlingsbart
Casestudie: WeSpeakSports — live fankommentar over WebRTC
WeSpeakSports er en plattform for live lydkommentar fra fans. Fans oppretter eller lytter til sanntids lydkommentar under sportskamper — fotball, basketball, rugby, F1 og mer. Appen er tilgjengelig på iPhone, iPad, Mac (Apple Silicon) og Vision Pro.
Den nåværende arkitekturen bruker WebRTC for lydstrømming. En fankommentator kringkaster lyd fra sin enhet, og lyttere mottar den i nær-sanntid. Lyden er talekvalitet, ikke musikkvalitet — forståelighet og lav forsinkelse betyr langt mer enn audiofil trofasthet.
Ville MoQ gi mening for WeSpeakSports?
I teorien, ja — det er en utmerket match for dette bruksscenariet. WeSpeakSports er en 1-til-mange direkte lydkringkasting med sanntidsforventninger. Dette er nettopp gapet MoQ er designet for å fylle: for mange lyttere for effektiv WebRTC-skalering, men for forsinkelsessensitivt for HLS.
MoQs publish/subscribe-modell passer naturlig til WeSpeakSports-arkitekturen: en kommentator publiserer et lydspor, lyttere abonnerer på det, og CDN-releer håndterer distribusjon. Dette ville være enklere og billigere å skalere enn WebRTC SFU-infrastruktur.
I praksis, ikke ennå — av to harde grunner:
- Safari/iOS er nesten der, men ikke ennå. WeSpeakSports krever iOS 18.0. Appens primære publikum er på iPhone. MoQ i nettleseren avhenger av WebTransport, som Apple la til i Safari 26.4 beta, men ennå ikke har levert i en stabil utgivelse. Selv for native iOS-apper finnes det ingen produksjonsklar MoQ SDK for Apple-plattformer i dag. WebRTC-stakken på iOS (via Apples innebygde WebKit-støtte og modne tredjepartsbiblioteker) er bevist og fungerer.
- Modenhet. WeSpeakSports er et levert produkt med ekte brukere. Å bytte transportlaget fra en bevist protokoll til en pre-1.0-spesifikasjon ville være forhastet. WebRTC håndterer den nåværende skalaen. Kompleksitetskostnaden ved å migrere er ikke rettferdiggjort av den nåværende brukerbasen.
Når bør man revurdere
MoQ blir verdt å evaluere for WeSpeakSports når:
- WebTransport leveres i stabil Safari — noe som nå er nært forestående gitt Safari 26.4 beta — og en moden native MoQ SDK for iOS/macOS dukker opp
- Brukerbasen vokser til en skala der WebRTC SFU-kostnader blir en vesentlig begrensning
- MoQ-reléinfrastruktur er tilgjengelig fra minst to CDN-leverandører med SLA-forpliktelser
- MoQ-transportspesifikasjonen når RFC-status
På det tidspunktet kan MoQ meningsfullt forenkle distribusjonsarkitekturen og redusere kostnad per lytter. Kommentator-til-relé-til-lyttere-modellen er et lærebokeksempel på MoQ-bruksscenario. Det er et spørsmål om timing, ikke tilpasning.
Casestudie: DJing Stream — kringkastingskvalitet DJ-lyd over SRT
DJing Stream er en macOS-app designet for et veldig spesifikt bruksscenario: strømming av kringkastingskvalitet lyd fra en DJs oppsett til et spillesteds lydsystem, over internett, i sanntid. Arkitekturen prioriterer lydkvalitet over alt annet.
Den nåværende stakken bruker SRT for sanntidsdistribusjon — levering av 24-bit PCM stereolyd ved 48 kHz (omtrent 2,3 Mbps) fra DJens Mac til spillestedets lydsystem. For bredere distribusjon til fjernlyttere kan lyden også serveres over HLS med tapsfri lyd. Hele designfilosofien er at en DJs lyd fortjener samme trofasthet som en fysisk kabeltilkobling.
Ville MoQ gi mening for DJing Stream?
Nei — og dette er ikke et timingspørsmål. MoQ er fundamentalt feilrettet i forhold til DJing Streams krav.
Her er grunnen:
- Tapsfri levering er ikke-forhandlingsbart. DJing Stream sender ukomprimert PCM-lyd. Hvert sample teller. SRTs ARQ-overføring garanterer at hver pakke ankommer — den vil legge til forsinkelse ved tap i stedet for å forkaste lyd. MoQs modell for delvis pålitelighet, som er en av dens hovedfordeler for direktevideo, er nøyaktig feil avveining for kringkastingskvalitet lyd. Et forkastet lydbilde er en hørbar feil på et klubb-lydsystem. Det er ikke akseptabelt.
- Punkt-til-punkt er det primære bruksscenariet. Kjerne-scenariet for DJing Stream er én DJ som strømmer til ett spillested. Dette er en punkt-til-punkt-forbindelse, ikke et distribusjonsproblem. MoQs publish/subscribe-relémodell legger til kompleksitet uten fordel for denne topologien.
- Ingen nettleserkrav. DJing Stream er en native macOS-app som kobler til spillestedets maskinvare. Det er ingen nettleser involvert. WebTransport/Safari-gapet er irrelevant, men det er også MoQs hovedfordel med nettleser-native levering.
- SRT er allerede riktig verktøy. SRT ble designet for nøyaktig dette: pålitelig, kryptert transport med lav forsinkelse av høykvalitetsmedier over uforutsigbare nettverk. Det er kamptestet i kringkastingsproduksjon. Hver koder og medieserver snakker det. Å erstatte SRT med MoQ for DJ-til-spillested-distribusjonsforbindelsen ville bety å gi opp garantert levering uten noen meningsfull gevinst.
- HLS Lossless håndterer distribusjonssiden. For det sekundære bruksscenariet med distribusjon til et bredere publikum (nettlyttere) er HLS med tapsfrie lydkodeker bevist og kompatibelt med enhver enhet. Forsinkelsestoleransen for fjernlyttere er høyere enn for selve spillestedet, så HLS' segmentbaserte modell er helt tilstrekkelig.
Når bør man revurdere
Ærlig talt? Sannsynligvis aldri for kjerne DJ-til-spillested-forbindelsen. SRT gjør nøyaktig det DJing Stream trenger, og MoQs designmål (skalerbar distribusjon med akseptabelt kvalitetstap under overbelastning) er i motsetning til DJing Streams designmål (nulltaps-levering av hvert lydsample).
Det eneste scenariet der MoQ kan bli relevant for DJing Stream er hvis produktet utvides mot storskaladistribusjon til fans med lavere trofasthetsforventninger — for eksempel strømming av en komprimert versjon av et DJ-sett til tusenvis av lyttere samtidig. Selv da ville HLS eller LL-HLS sannsynligvis forbli enklere og mer bredt kompatibelt.
Beslutningsrammeverket
Etter å ha forsket grundig på MoQ — IETF-utkastene, bransjens kommentarer fra Broadpeak, Red5, BlogGeek.me, webrtcHacks, Meetecho og Nanocosmos — er her den enkleste beslutningsregelen jeg kan tilby:
Behold din nåværende stakk når
- Produktet ditt leveres i dag og din nåværende protokoll fungerer
- Du trenger Safari/iOS nettleserstøtte i dag (WebTransport er i Safari beta, men ennå ikke stabilt)
- Noen sekunders forsinkelse er akseptabelt (→ HLS/LL-HLS)
- Du trenger garantert tapsfri levering (→ SRT)
- Du trenger ekte toveis sanntidskommunikasjon (→ WebRTC)
Begynn å evaluere MoQ når
- Ultra-lav forsinkelse til store publikum er kjernen i produktets verdi (live betting, auksjoner, synkroniserte andreskjermopplevelser)
- Du kontrollerer hele stakken fra inntak til avspilling og kan absorbere en ny protokoll
- WebRTC-skaleringskostnader blir et reelt forretningsproblem
- Du bygger et nytt produkt som ikke leveres før sent i 2026 eller 2027
- Du kan akseptere at spesifikasjonen fortsatt kan endres før den når RFC
Følg MoQ nøye hvis
- Du driver CDN- eller reléinfrastruktur (MoQ er designet for å fungere med HTTP/3 CDN-er)
- Du bygger direktesendte sportsprodukter med synkroniseringskrav
- Du ønsker å samle inntak og distribusjon på en enkelt protokoll
- Du er frustrert over ompakkingsoverheaden av RTMP/SRT-inntak → HLS-distribusjon
Konklusjonen
MoQ er reelt, det er godt designet, og det adresserer genuine begrensninger i dagens strømmeprotokolllandskap. Ambisjonen — én protokoll for både sanntid og nær-sanntid, fra inntak til distribusjon, med CDN-skala relestøtte — er overbevisende.
Men ambisjon er ikke det samme som beredskap. Spesifikasjonen er ikke ferdigstilt. Safari har WebTransport i beta, men ennå ikke i en stabil utgivelse. Produksjonsimplementeringer er begrenset til tidlige adoptører. Økosystemet av SDK-er, verktøy og operasjonell kunnskap som gjør HLS, WebRTC og SRT pålitelige i produksjon, eksisterer rett og slett ikke ennå for MoQ.
For de fleste strømmeprodukter som leveres i 2026 er MoQ noe å følge med på — ikke noe å adoptere. Når det modnes, og det vil det, har det potensial til å forenkle arkitekturer som for tiden syr sammen flere protokoller med ompakkingslag i mellom.
Inntil da: hvis HLS fungerer for din levering, behold det. Hvis WebRTC fungerer for dine sanntidsbehov, behold det. Hvis SRT fungerer for dine punkt-til-punkt-forbindelser, behold det. Den beste protokollen er den som leveres og fungerer, ikke den som er mest spennende på et konferanselysbilde.
Kilder
- IETF MoQ Transport-utkast (v17, mars 2026): datatracker.ietf.org/doc/draft-ietf-moq-transport
- IETF MoQ Charter: datatracker.ietf.org/group/moq/about
- moq-lite-utkast: ietf.org/archive/id/draft-lcurley-moq-lite-02.html
- IETF-blogg — 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-oversikt: developer.apple.com/streaming
- WebKit — Announcing Interop 2026 (WebTransport-forpliktelse): 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