Media over QUIC — MoQ — er den mest diskuterede nye streamingprotokol i 2025-2026. Blogindlæg formerer sig, konferencepræsentationer hober sig op, og CDN-leverandører kappes om at annoncere understøttelse. Hvis du arbejder med live streaming, er du sandsynligvis blevet spurgt: bør vi skifte til MoQ?
Det korte svar, for de fleste produkter i drift i dag, er nej — ikke endnu. Men MoQ er værd at forstå, fordi de problemer den løser er reelle, og tidslinjen for at den bliver produktionsklar nu måles i kvartaler, ikke år.
Denne artikel forklarer hvad MoQ faktisk er, hvor den står i marts 2026, hvad den ændrer sammenlignet med HLS, WebRTC og SRT — og om den ville give mening for to virkelige produkter vi har implementeret: WeSpeakSports (live fankommentar via WebRTC) og DJing Stream (broadcast-kvalitet DJ-lyd via SRT og HLS Lossless).
Hvad MoQ faktisk er
MoQ står for Media over QUIC. Det er en IETF-arbejdsgruppeindsats startet i 2022 for at definere en ny medieleveringsprotokol bygget oven på QUIC (transportlaget bag HTTP/3).
Den centrale transportspecifikation, draft-ietf-moq-transport, nåede version 17 i marts 2026. En streamingformatspecifikation (draft-ietf-moq-msf) er også undervejs, sammen med ledsagende udkast til CMAF-pakning og header-komprimering. Ingen af disse er endnu ratificerede RFC'er.
I sin kerne er MoQ en publish/subscribe-protokol. En publisher sender navngivne medieobjekter (lydframes, videoframes, metadata) til relays, og subscribers modtager dem ved at abonnere på navngivne tracks. Dette er fundamentalt anderledes end både HLS (HTTP-forespørgsel/svar for segmenter) og WebRTC (peer-to-peer sessionsforhandling med SDP/ICE).
MoQ kører over QUIC-streams og datagrammer, enten nativt eller via WebTransport (browser-API'en til QUIC). Dette giver adgang til QUIC's multiplexing, prioritering og delvise pålidelighed — hvilket betyder at protokollen, efter design, kan kassere en forsinket videoframe i stedet for at blokere hele streamen mens den venter på genoverførsel.
Hvad MoQ forsøger at erstatte
Som Cullen Jennings fra Cisco (deltager i MoQ-arbejdsgruppen) udtrykker det, har streamingverdenen i øjeblikket to siloer. På den ene side leverer tjenester som Netflix og YouTube medier i stor skala gennem HTTP-baserede CDN'er, men med sekunders forsinkelse. På den anden side leverer konferenceværktøjer som Zoom og WebRTC-baserede platforme medier i næsten-realtid, men kan ikke skalere omkostningseffektivt til store publikummer.
MoQ sigter mod at bygge bro mellem disse to verdener med en enkelt protokol der kan betjene både realtids- og næsten-realtidsbrugscases, fra bidrag (ingest) gennem distribution (levering til seere), med CDN-kompatibel relay-infrastruktur imellem.
Hvor MoQ står i dag (marts 2026)
Lad os være præcise om den aktuelle tilstand:
Specifikationen er tæt på men ikke færdig. Transportudkastet er på version 17 og itererer hurtigt. Streamingformatudkastet blev offentliggjort i januar 2026. Der er aktivt ledsagende arbejde med CMAF-pakning og header-komprimering. Men der er endnu ingen ratificeret RFC.
Safari/WebTransport-gabet lukkes. MoQ i browseren afhænger af WebTransport, som kræver HTTP/3 og QUIC. Chrome og Firefox understøtter allerede WebTransport. Safari var den manglende — men Apple tilføjede WebTransport-understøttelse i Safari 26.4 beta (februar 2026), og det er en officiel Interop 2026-forpligtelse fra WebKit. I marts 2026 er dette endnu ikke udgivet i en stabil Safari-version, men det er ikke længere et spørgsmål om om — kun hvornår i den næste OS-cyklus. For produkter der retter sig mod iPhone- og iPad-brugere via en browser, er gabet næsten lukket.
Tidlige produktionsimplementeringer eksisterer men er begrænsede. Nanocosmos demonstrerede end-to-end MoQ-levering (OBS-ingest til globalt publikum) ved MonteVIDEO Summer Project. Cloudflare lancerede en MoQ-beta. Red5 annoncerede MoQ-understøttelse inden udgangen af 2026. Men disse er early adopter-implementeringer, ikke mainstream-infrastruktur.
Fællesskabet er ærligt om modenhed. Selv Luke Curley, som byggede en af de tidligste MoQ-implementeringer hos Twitch (nu Discord) og forfattede moq-lite-forenklingsudkastet, fastslår eksplicit at den fulde MoQ-transportspecifikation "er blevet for kompliceret" med "for mange beskeder, valgfrie tilstande og halvbagte funktioner." Hans moq-lite-udkast er et svar på denne kompleksitet.
Brancheveteraner er afdæmpede. Tsahi Levent-Levi fra BlogGeek.me forudsagde at udviklere i 2026 ville klage mere over WebRTC end MoQ — ikke fordi MoQ er bedre, men fordi MoQ-brugere stadig er early adopters der forventer ru kanter. WebRTC er den der er i produktion overalt og bærer vægten af virkelighedens forventninger.
Hvad MoQ ændrer sammenlignet med HLS
HLS (HTTP Live Streaming) fungerer ved at opdele medier i segmenter, skrive dem til en HTTP-server og lade afspillere forespørge nye segmenter via playlister. Den er moden, CDN-venlig, bredt implementeret og veldokumenteret i RFC 8216 og Apples HLS Authoring Specification. Low-Latency HLS (LL-HLS) presser forsinkelsen ned til ca. 2-4 sekunder.
MoQ ændrer leveringsmodellen på flere måder:
Fra polling til push. HLS-afspillere forespørger segmenter. MoQ-subscribers modtager objekter efterhånden som de publiceres. Dette eliminerer polling-forsinkelse.
Fra segmenter til objekter. HLS opererer på flersekunderssegmenter (eller delvise segmenter i LL-HLS). MoQ kan operere på frame-niveau. En enkelt videoframe eller lydframe kan være et individuelt adresserbart, individuelt leverbart objekt.
Fra TCP til QUIC. HLS kører over HTTP/TCP. Når en TCP-pakke tabes, går alt bag den i stå (head-of-line blocking). MoQ kører over QUIC, hvor streams er uafhængige — en tabt pakke på én stream blokerer ikke andre.
Eksplicit prioritering. MoQ's transportudkast definerer prioritet og leveringsrækkefølge på protokolniveau. Under overbelastning kan en relay kassere lavere-prioritetsobjekter (f.eks. B-frames) i stedet for at forsinke alt lige meget.
Samlet ingest og distribution. I dag bruger de fleste live-workflows én protokol til bidrag (RTMP, SRT, WHIP) og en anden til distribution (HLS, DASH). MoQ kan potentielt betjene begge veje med en enkelt protokol, hvilket eliminerer ompakningstrinnet på origin-serveren.
Hvornår HLS stadig vinder
Intet af dette betyder at HLS er forældet. HLS forbliver det stærkere valg når:
- Et par sekunders forsinkelse er helt acceptabelt
- Bred enhedskompatibilitet er afgørende (alle telefoner, TV'er og set-top-bokse afspiller HLS)
- Den eksisterende CDN- og værktøjsinvestering fungerer godt
- Operationel enkelhed og kamptestet pålidelighed betyder mere end at presse forsinkelsen lavere
For standard OTT live- og VOD-levering — som udgør det overvældende flertal af streamingtrafik — er HLS ikke i stykker, og MoQ løser ikke et problem der eksisterer.
Hvad MoQ ændrer sammenlignet med WebRTC
WebRTC blev designet til realtids peer-to-peer kommunikation: videoopkald, skærmdeling, en-til-en eller smågruppe-samtaler. Branchen har strakt den langt ud over det originale omfang ved at bruge SFU-arkitekturer (Selective Forwarding Unit) til at skalere WebRTC til større publikummer.
MoQ adskiller sig fra WebRTC på flere vigtige måder:
Arkitektur. WebRTC er fundamentalt en sessionsorienteret peer-to-peer-protokol, selv når den medieres gennem SFU'er. MoQ er en klient-server publish/subscribe-protokol designet fra starten omkring relays og CDN-lignende distribution.
Skaleringsmodel. Skalering af WebRTC kræver SFU-infrastruktur der er specialbygget og dyr. MoQ-relays er designet til at integrere med eksisterende CDN-infrastruktur — HTTP/3-servere kan udvides til at håndtere MoQ-trafik, hvilket er grunden til at CDN-leverandører som Akamai og YouTube er aktivt involverede.
Kompleksitet. WebRTC medfører betydelig kompleksitet: SDP offer/answer-forhandling, ICE-kandidatindsamling, STUN/TURN-servere til NAT-traversering, SRTP til kryptering, SCTP til datakanaler. MoQ's forbindelsesopsætning er enklere — et QUIC-handshake efterfulgt af subscribe/publish-beskeder.
Codec-fleksibilitet. WebRTC's codec-forhandling er tæt koblet til protokollen. MoQ er codec-agnostisk på transportniveau — medieformatet håndteres af applikationslaget (MSF, LOC eller tilpassede containere).
Browser-afhængighed. Begge protokoller afhænger af browser-API'er til webbaseret levering. WebRTC har universel browserunderstøttelse. MoQ afhænger af WebTransport, som Safari først har tilføjet i beta (26.4, februar 2026) og endnu ikke har udgivet stabilt. Dette gab lukkes men er stadig en praktisk overvejelse for MoQ i dag.
Hvornår WebRTC stadig vinder
WebRTC forbliver det bedre valg når:
- Ægte tovejsrealtidskommunikation er nødvendig (videoopkald, konferencer)
- Browserkompatibilitet på tværs af alle platforme inklusive Safari/iOS er påkrævet
- Brugscasen er peer-to-peer eller smågruppe uden behov for CDN-skala distribution
- Afprøvet, produktionsklar værktøjs- og SDK-modenhed har betydning
Hvad MoQ ændrer sammenlignet med SRT
SRT (Secure Reliable Transport) udmærker sig i at flytte medier af høj kvalitet fra punkt A til punkt B over uforudsigelige netværk. Den tilbyder AES-kryptering, pakketabsgendannelse via ARQ (Automatic Repeat Request) og understøttelse af adaptiv bitrate. SRT er bredt adopteret til ingest-workflows (kameraer til studier, fjernproduktion til cloud-encodere) men fungerer også som punkt-til-punkt distributionsprotokol — som DJing Stream demonstrerer.
MoQ og SRT tjener overlappende men forskellige formål:
SRT er punkt-til-punkt; MoQ er publish/subscribe. SRT forbinder én afsender med én modtager. MoQ understøtter nativt en-til-mange distribution gennem relays.
SRT garanterer levering; MoQ kan vælge ikke at gøre det. SRT's ARQ-mekanisme genoversfører hver tabt pakke, hvilket sikrer tabsfri levering men tilføjer forsinkelse ved pakketab. MoQ kan konfigureres til delvis pålidelighed — kassering af forsinkede objekter i stedet for at genoverføre dem — hvilket er bedre til latens-følsom live-levering men uacceptabelt når hver sample tæller.
SRT er moden og implementeret; MoQ er i sin vorden. SRT har bred hardware- og softwareunderstøttelse (OBS, vMix, FFmpeg, Haivision, alle større encodere). MoQ har tidlige implementeringer.
Hvornår SRT stadig vinder
SRT er det stærkere valg når:
- Brugscasen er punkt-til-punkt (kilde til encoder, encoder til origin, eller direkte-til-venue distribution)
- Tabsfri levering betyder mere end absolut minimum forsinkelse
- Workflowet involverer professionelt broadcastudstyr der allerede taler SRT
- Lydtrohed på bitniveau er ufravigelig
Casestudie: WeSpeakSports — live fankommentar via WebRTC
WeSpeakSports er en platform for live lydkommentarer fra fans. Fans opretter eller lytter til realtids-lydkommentarer under sportsbegivenheder — fodbold, basketball, rugby, F1 og mere. Appen er tilgængelig på iPhone, iPad, Mac (Apple Silicon) og Vision Pro.
Den nuværende arkitektur bruger WebRTC til lydstreaming. En fankommentator udsender lyd fra sin enhed, og lytterne modtager den i næsten-realtid. Lyden er af talekvalitet, ikke musikkvalitet — forståelighed og lav forsinkelse betyder langt mere end audiofilkvalitet.
Ville MoQ give mening for WeSpeakSports?
I teorien, ja — det er et fremragende match til denne brugssituation. WeSpeakSports er en 1-til-mange live lydudsendelse med realtidsforventninger. Dette er præcis det gab MoQ er designet til at udfylde: for mange lyttere til effektiv WebRTC-skalering, men for latens-følsomt til HLS.
MoQ's publish/subscribe-model passer naturligt til WeSpeakSports-arkitekturen: en kommentator publicerer en lydtrack, lyttere abonnerer på den, og CDN-relays håndterer distributionen. Dette ville være enklere og billigere at skalere end WebRTC SFU-infrastruktur.
I praksis, ikke endnu — af to hårde grunde:
- Safari/iOS er næsten klar, men ikke helt endnu. WeSpeakSports kræver iOS 18.0. Appens primære publikum er på iPhone. MoQ i browseren afhænger af WebTransport, som Apple tilføjede i Safari 26.4 beta men endnu ikke har udgivet i en stabil version. Selv for native iOS-apps eksisterer der i dag ingen produktionsklar MoQ SDK til Apple-platforme. WebRTC-stakken på iOS (via Apples indbyggede WebKit-understøttelse og modne tredjeparts-SDK'er) er gennemprøvet og virker.
- Modenhed. WeSpeakSports er et udgivet produkt med rigtige brugere. At udskifte transportlaget fra en gennemprøvet protokol til en pre-1.0 specifikation ville være forhastet. WebRTC håndterer den nuværende skala. Kompleksitetsomkostningen ved migrering er ikke begrundet af den nuværende brugerbase.
Hvornår man bør genoverveje
MoQ bliver værd at evaluere for WeSpeakSports når:
- WebTransport udgives i en stabil Safari-version — hvilket nu er nært forestående givet Safari 26.4 beta — og en moden nativ MoQ SDK til iOS/macOS dukker op
- Brugerbasens vokser til en skala hvor WebRTC SFU-omkostninger bliver en meningsfuld begrænsning
- MoQ relay-infrastruktur er tilgængelig fra mindst to CDN-leverandører med SLA-forpligtelser
- MoQ-transportspecifikationen opnår RFC-status
På det tidspunkt kunne MoQ meningsfuldt forenkle distributionsarkitekturen og reducere omkostningen per lytter. Kommentator-til-relay-til-lyttere-modellen er en lærebogs MoQ-brugssituation. Det er et spørgsmål om timing, ikke egnethed.
Casestudie: DJing Stream — broadcast-kvalitet DJ-lyd via SRT
DJing Stream er en macOS-app designet til en meget specifik brugssituation: streaming af broadcast-kvalitet lyd fra en DJ's setup til et venues lydsystem, over internettet, i realtid. Arkitekturen prioriterer lydkvalitet over alt andet.
Den nuværende stak bruger SRT til realtidsdistribution — levering af 24-bit PCM stereolyd ved 48 kHz (ca. 2,3 Mbps) fra DJ'ens Mac til venues lydsystem. Til bredere distribution til fjernlyttere kan lyden også serveres over HLS med tabsfri lyd. Hele designfilosofien er at en DJ's lyd fortjener samme trohed som en fysisk kabelforbindelse.
Ville MoQ give mening for DJing Stream?
Nej — og dette er ikke et spørgsmål om timing. MoQ er fundamentalt ude af trit med DJing Streams krav.
Her er hvorfor:
- Tabsfri levering er ufravigelig. DJing Stream sender ukomprimeret PCM-lyd. Hver sample tæller. SRT's ARQ-genoverførselsmekanisme garanterer at hver pakke ankommer — den vil tilføje forsinkelse under tab i stedet for at kassere lyd. MoQ's delvise pålidelighedsmodel, som er en af dens centrale fordele for live video, er præcis den forkerte afvejning for broadcast-kvalitet lyd. En kasseret lydframe er en hørbar fejl i et klublydsystem. Det er ikke acceptabelt.
- Punkt-til-punkt er den primære brugssituation. Kernescenariet for DJing Stream er én DJ der streamer til ét venue. Dette er en punkt-til-punkt forbindelse, ikke et distributionsproblem. MoQ's publish/subscribe relay-model tilføjer kompleksitet uden fordel for denne topologi.
- Intet browser-krav. DJing Stream er en nativ macOS-app der forbinder til venue-hardware. Der er ingen webbrowser involveret. WebTransport/Safari-gabet er irrelevant, men det er MoQ's hovedfordel med browser-nativ levering også.
- SRT er allerede det rigtige værktøj. SRT blev designet til netop dette: pålidelig, krypteret, lavforsinkelsestransport af medier af høj kvalitet over uforudsigelige netværk. Den er kamptestet i broadcastproduktion. Alle encodere og medieservere taler den. At erstatte SRT med MoQ til DJ-til-venue distributionsforbindelsen ville betyde at opgive garanteret levering uden nogen meningsfuld gevinst.
- HLS Lossless håndterer distributionssiden. Til den sekundære brugssituation med distribution til et bredere publikum (web-lyttere) er HLS med tabsfrie lydcodecs gennemprøvet og kompatibel med alle enheder. Latenstolerancen for fjernlyttere er højere end for selve venuen, så HLS's segmentbaserede model er helt tilstrækkelig.
Hvornår man bør genoverveje
Ærligt? Sandsynligvis aldrig for den centrale DJ-til-venue forbindelse. SRT gør præcis hvad DJing Stream har brug for, og MoQ's designmål (skalerbar distribution med acceptabelt kvalitetstab under overbelastning) er modsatte af DJing Streams designmål (tabsfri levering af hver lydprøve).
Det eneste scenarie hvor MoQ kunne blive relevant for DJing Stream er hvis produktet udvides mod storskaladistribution til fans med lavere troskabsforventninger — for eksempel streaming af en komprimeret version af et DJ-set til tusinder af lyttere samtidigt. Selv da ville HLS eller LL-HLS sandsynligvis forblive enklere og mere bredt kompatibelt.
Beslutningsrammen
Efter at have undersøgt MoQ grundigt — IETF-udkastene, branchekommentarer fra Broadpeak, Red5, BlogGeek.me, webrtcHacks, Meetecho og Nanocosmos — er her den simpleste beslutningsregel jeg kan tilbyde:
Behold din nuværende stak når
- Dit produkt er i drift i dag og din nuværende protokol virker
- Du har brug for Safari/iOS browserunderstøttelse i dag (WebTransport er i Safari beta men endnu ikke stabil)
- Nogle sekunders forsinkelse er acceptabel (→ HLS/LL-HLS)
- Du har brug for garanteret tabsfri levering (→ SRT)
- Du har brug for ægte tovejsrealtidskommunikation (→ WebRTC)
Begynd at evaluere MoQ når
- Ultralav forsinkelse til store publikummer er kernen i dit produkts værdi (live-væddemål, auktioner, synkroniserede andensskærmsoplevelser)
- Du kontrollerer hele stakken fra ingest til afspilning og kan absorbere en ny protokol
- WebRTC-skaleringsomkostninger er ved at blive et reelt forretningsproblem
- Du bygger et nyt produkt der ikke lanceres før sent 2026 eller 2027
- Du kan acceptere at specifikationen stadig kan ændre sig før den opnår RFC-status
Hold øje med MoQ hvis
- Du driver CDN- eller relay-infrastruktur (MoQ er designet til at arbejde med HTTP/3 CDN'er)
- Du bygger live sportsprodukter med synkroniseringskrav
- Du ønsker at samle ingest og distribution i en enkelt protokol
- Du er frustreret over ompakning-overheadet fra RTMP/SRT ingest → HLS distribution
Bundlinjen
MoQ er virkelig, den er veldesignet, og den adresserer ægte begrænsninger i dagens streamingprotokol-landskab. Ambitionen — én protokol for både realtid og næsten-realtid, fra ingest til distribution, med CDN-skala relay-understøttelse — er overbevisende.
Men ambition er ikke det samme som modenhed. Specifikationen er ikke finaliseret. Safari har WebTransport i beta men endnu ikke i en stabil udgivelse. Produktionsimplementeringer er begrænset til early adopters. Økosystemet af SDK'er, værktøjer og driftsviden der gør HLS, WebRTC og SRT pålidelige i produktion eksisterer simpelthen endnu ikke for MoQ.
For de fleste streamingprodukter i drift i 2026 er MoQ noget man bør følge — ikke noget man bør adoptere. Når den modnes, og det vil den, har den potentiale til at forenkle arkitekturer der i øjeblikket syer flere protokoller sammen med ompakningslag imellem.
Indtil da: hvis HLS virker til din levering, behold det. Hvis WebRTC virker til dine realtidsbehov, behold det. Hvis SRT virker til dine punkt-til-punkt forbindelser, behold det. Den bedste protokol er den der er i drift og virker, ikke den der er mest spændende på et konferenceslide.
Kilder
- IETF MoQ Transport draft (v17, marts 2026): datatracker.ietf.org/doc/draft-ietf-moq-transport
- IETF MoQ Charter: datatracker.ietf.org/group/moq/about
- moq-lite draft: 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 overview: 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