Fra OBS/vMix til publikum: RTMP, LL-HLS og forsinkelse forklart for produsenter

Kjeden i ett bilde

En direktesending består av fire ledd. Først produksjonen: kamera, lyd og eventuell bildemiks i vMix, OBS, ATEM eller en hardware-encoder. Deretter ingest: encoderen sender én komprimert strøm til plattformens mottak, som regel over RTMP, SRT eller WHIP. Så transkoding og pakking: plattformen lager flere kvalitetsnivåer av strømmen og deler dem i små segmenter som distribueres via et CDN. Til slutt avspilling: spilleren i nettleseren laster segmentene, velger kvalitet ut fra seerens båndbredde og viser bildet.

Hvert ledd legger til forsinkelse og hvert ledd kan feile. Kunsten er å vite hvor mye hvert ledd bidrar med, og hvor du som produsent faktisk har kontroll. Grovt sett styrer du encoderen og nettforbindelsen ut fra lokalet fullt ut, ingest-protokollen delvis, og resten er plattformens ansvar.

Encoder-innstillinger som faktisk betyr noe

Videokodek: H.264 (AVC) er fortsatt standarden for ingest, fordi alle plattformer tar imot det og all maskinvare kan kode det i sanntid. H.265 og AV1 gir bedre komprimering men støttes ikke universelt for live-ingest, så hold deg til H.264 med mindre plattformen eksplisitt ber om noe annet.

Profil og nivå: Bruk High-profil, nivå 4.1 eller 4.2 for 1080p. Baseline-profil er unødvendig for moderne mottak og gir dårligere kvalitet per bit.

Oppløsning og bildefrekvens: 1920x1080 ved 25 eller 50 bilder per sekund i Norge, avhengig av om kameraene kjører 25p eller 50p. Ikke send 30 eller 60 hvis produksjonen er 25/50; konvertering underveis gir rykk. Send det høyeste plattformen skal distribuere; den lager de lavere nivåene selv.

Bitrate: For 1080p25 er 5 til 6 Mbps et godt utgangspunkt for konferanseinnhold med lite bevegelse; 1080p50 med mye bevegelse kan trenge 8 til 10 Mbps. Bruk CBR (konstant bitrate) eller CBR med liten toleranse for ingest, ikke VBR. Variabel bitrate gir bedre fil, men uforutsigbar nettbelastning som skaper problemer på ustabile linjer.

Keyframe-intervall: Dette er den innstillingen flest tar feil på. Sett keyframe-intervallet til 2 sekunder, eller 1 sekund hvis plattformen skal levere lav forsinkelse med LL-HLS. Segmentene på leveringssiden må starte på en keyframe, så et keyframe-intervall på 10 sekunder tvinger plattformen til lange segmenter og høy forsinkelse. Deaktiver scenecut eller adaptive keyframes; de gir uregelmessige intervaller.

Lyd: AAC-LC, 48 kHz, stereo, 128 til 192 kbps. Sjekk at lydnivået ligger rundt minus 18 til minus 20 dBFS i snitt med topper under minus 3. For lav lyd er det vanligste publikumsklagen på direktesendinger.

RTMP, SRT og WHIP: valg av ingest-protokoll

RTMP er arbeidshesten. Protokollen er fra 2002, går over TCP, støttes av absolutt alt utstyr og programvare, og er enkel å sette opp med en URL og en stream key. Svakheten er at TCP retransmitterer tapte pakker i rekkefølge; på en linje med pakketap og høy latens vil encoderens buffer fylle seg, bildet fryser og til slutt kobler den fra. Over kablet fiber fra et konferansesenter er RTMP helt greit. Over bonded mobil eller ukjent hotell-wifi er det risikabelt.

SRT (Secure Reliable Transport) er laget for nettopp ustabile linjer. Den går over UDP med selektiv retransmisjon og en konfigurerbar buffer (latency), typisk 200 til 2 000 millisekunder. Du bytter litt forsinkelse mot mye robusthet. Har encoderen SRT-utgang og plattformen SRT-mottak, er det det riktige valget for alt som ikke er kablet fiber. Sett SRT-latency til minst fire ganger målt RTT (rundtur-tid), og bruk kryptering hvis innholdet er sensitivt.

WHIP (WebRTC-HTTP Ingestion Protocol) er nyere og lar en nettleser sende direkte til plattformen uten encoder-programvare. Det brukes for enkle sendinger fra webkamera og skjermdeling, gjesteinnslag fra hjemmekontor og studioløsninger der flere deltakere mikses i nettleseren. Forsinkelsen inn er svært lav, under et halvt sekund, men du har mindre kontroll over bitrate og kodek enn med en dedikert encoder. NW-Stage tar imot både RTMP og WHIP, og bruker WHIP i sin nettleserbaserte studiomodus for flere presentatører.

Praktisk regel: kablet linje med lav pakketap, bruk RTMP eller SRT etter hva utstyret støtter. Mobil eller ukjent nett, bruk SRT. Nettleser uten encoder, bruk WHIP.

Hva skjer i plattformen: transkoding og pakking

Når strømmen er tatt imot, lager plattformen en ladder av kvalitetsnivåer, for eksempel 1080p, 720p, 480p, 360p og 240p, hver med sin egen bitrate. Dette kalles adaptive bitrate (ABR) og er grunnen til at du bare trenger å sende ett nivå inn. Seere med god linje får 1080p, seere på mobil i tog får 360p, og spilleren bytter sømløst mellom dem.

Hvert nivå deles så opp i segmenter og beskrives i et manifest, en tekstfil som lister hvilke segmenter som finnes og i hvilken rekkefølge. Med HLS (HTTP Live Streaming) er dette en m3u8-fil. Segmentene og manifestet lastes opp til et CDN, et globalt nettverk av servere som betjener seerne fra nærmeste punkt. Det er CDN-et som gjør at du kan ha tusenvis av samtidige seere uten at ingest-serveren merker det.

Transkodingen tar tid, typisk ett til to sekunder, og segmentlengden avgjør hvor mye forsinkelse pakkingen legger til. Med klassisk HLS og seks sekunders segmenter må spilleren buffre tre segmenter før den starter, og forsinkelsen ender på 20 til 40 sekunder. Det er derfor tradisjonell streaming har vært «et halvt minutt bak».

LL-HLS og forsinkelse: hva er realistisk

LL-HLS (Low-Latency HLS) er Apples utvidelse av HLS fra 2020, nå støttet i alle moderne nettlesere via native avspilling i Safari og JavaScript-spillere som hls.js og video.js ellers. Prinsippet er at segmentene deles videre opp i deler (parts) på 200 til 500 millisekunder, at manifestet oppdateres for hver del, og at spilleren kan be om deler som ikke er ferdige ennå og få dem levert idet de blir klare. Resultatet er en typisk ende-til-ende-forsinkelse på 2 til 5 sekunder fra kamera til skjerm.

Hvor ender du i praksis? Encoder med kort keyframe-intervall og få B-frames: 0,5 til 1 sekund. Nettverk ut fra lokalet: 0,05 til 0,5 sekund. Transkoding: 1 til 2 sekunder. LL-HLS-pakking og CDN: 0,5 til 1 sekund. Spillerbuffer: 1 til 2 sekunder. Sum: rundt 3 til 6 sekunder. Det er fullt tilstrekkelig for at en avstemning eller en spørsmålsrunde i salen føles samtidig for de digitale deltakerne.

Trenger du under ett sekund, for eksempel til auksjoner eller toveis samtale, må du over på WebRTC hele veien til seeren. Det skalerer dårligere og koster mer, og er sjelden nødvendig for konferanser og årsmøter. Vær ærlig med kunden om dette: 3 til 5 sekunder med LL-HLS er det som gir god kvalitet, DVR og skalering samtidig.

DVR: spole tilbake mens sendingen pågår

DVR (digital video recorder) i live-sammenheng betyr at seeren kan pause, spole tilbake og hoppe fram til direkte igjen mens sendingen fortsatt går. Teknisk gjøres det ved at manifestet beholder segmenter bakover i tid i stedet for å slette dem etter noen minutter, og at spilleren viser en tidslinje for det tilgjengelige vinduet.

For publikum er dette gull: den som kommer fem minutter for sent kan starte fra begynnelsen, den som ble avbrutt kan spole tilbake til lysbildet de gikk glipp av, og den som vil hoppe over pausen kan gjøre det. For produsenten koster det ingenting ekstra å skru på, men det påvirker hvordan du tenker om sendingen: alt du sender ut, inkludert testbilde før start og feil underveis, ligger tilgjengelig i DVR-vinduet. Start derfor sendingen med en ren plakat, ikke et testkort.

DVR gjør også overgangen til opptak sømløs. Når sendingen avsluttes, blir det samme materialet umiddelbart tilgjengelig som opptak i biblioteket, uten at noen må laste opp en fil. På NW-Stage ligger opptaket klart i det øyeblikket sendingen stoppes, med samme spiller og samme domene.

Redundans og backup-ingest

Den vanligste årsaken til at en sending faller ut, er ikke plattformen. Det er linjen ut av lokalet eller encoderen. Redundans handler om å ha en plan B klar før noen merker at plan A sviktet.

To linjer: Ha alltid en uavhengig nettforbindelse i tillegg til lokalets kablede nett, typisk en 4G/5G-router med eget SIM eller en bonding-enhet som kombinerer flere forbindelser. Test begge før sending. Mål ikke bare hastighet, mål pakketap og jitter; en linje med 50 Mbps og 3 prosent pakketap er dårligere for RTMP enn en med 15 Mbps og null tap.

To encodere: Kjør en primær og en sekundær encoder med samme program-utgang. Den sekundære kan være en enkel hardware-boks som tar programsignalet over SDI eller HDMI, uavhengig av PC-en som kjører vMix. Da overlever du at PC-en henger.

Backup-ingest: Noen plattformer tilbyr to ingest-adresser til samme sending, en primær og en backup, og bytter automatisk til backup hvis primæren stopper. Sjekk hva plattformen din tilbyr og hvordan byttet oppleves for seeren; ofte er det et kort hakk. Uten backup-ingest er alternativet å ha den sekundære encoderen klar med samme stream key og starte den manuelt når primæren faller.

Preflight: Kjør en faktisk testsending fra lokalet, med samme encoder, samme linje og samme innstillinger, minst en time før publikum kobler seg på. Se på plattformens statistikk for mottatte bilder, tapte pakker og rekonnekter. En test som viser 30 prosent pakketap på RTMP er en klar beskjed om å bytte til SRT eller til den andre linjen før det er for sent.

Kvalitetsvelger og spilleren hos publikum

Spilleren velger automatisk kvalitet ut fra målt båndbredde, og for de fleste seere fungerer det godt. Men produsenter bør likevel insistere på en manuell kvalitetsvelger. Seeren som sitter på en flakkende linje og heller vil ha stabil 480p enn hopping mellom 1080p og 360p, skal kunne velge det. Seeren som skal vise sendingen på storskjerm i et møterom, skal kunne låse 1080p.

I Chrome, Edge, Firefox og Android leveres velgeren av JavaScript-spilleren, og den viser nivåene fra manifestet: Auto, 1080p, 720p, 480p, 360p, 240p. På iPhone og iPad bruker Safari native HLS-avspilling, og der er det operativsystemet som styrer kvalitetsvalget uten manuell velger. Det er en begrensning i plattformen fra Apple, ikke i spilleren, og verdt å nevne for kunder som spør hvorfor knappen mangler på mobilen.

Test spilleren i alle nettlesere kunden bruker, inkludert eldre bedrifts-PC-er med Edge og iPad i møterom. Sjekk at undertekster vises, at fullskjerm fungerer og at DVR-tidslinjen er synlig. Og sjekk lyden på faktiske høyttalere, ikke bare hodetelefoner.

Vanlige feil og hvordan du feilsøker

Bildet fryser og starter igjen med jevne mellomrom: Nesten alltid nettverk ut fra lokalet. Se på encoderens statistikk for droppede bilder og tapte pakker. Løsning: bytt til SRT, senk bitraten, eller bytt linje.

Forsinkelsen er 30 sekunder selv om plattformen lover lav latens: Sjekk keyframe-intervallet. Med 10 sekunder mellom keyframes kan plattformen ikke lage korte segmenter. Sett til 1 eller 2 sekunder og deaktiver scenecut.

Lyden er ute av synk med bildet: Vanligvis oppstår det i produksjonen, ikke i plattformen. Sjekk lydforsinkelse i mikseren mot kameraforsinkelsen, og sjekk at encoderen bruker samme tidsbase for lyd og bilde. Hvis synken glir over tid, er det ofte en frekvens-mismatch (44,1 mot 48 kHz).

Sendingen ser bra ut på PC men pikselert på mobil: Spilleren har valgt et lavt nivå på grunn av dårlig mobilnett, eller den laveste renditionen i ladderen er for lav. Sjekk hvilke nivåer plattformen lager og om seeren kan velge manuelt.

Encoderen kobler fra med jevne mellomrom: Sjekk at stream key er riktig og ikke brukt av en annen encoder samtidig; to encodere på samme nøkkel sparker hverandre av. Sjekk også at brannmuren i lokalet slipper gjennom port 1935 (RTMP) eller den UDP-porten SRT bruker.

Ingen lyd i det hele tatt: Sjekk at encoderen faktisk har en lydkilde valgt, at lydsporet er AAC, og at plattformen viser lydnivå i sin ingest-status. Overraskende ofte er det en mute-knapp i mikseren.

Ofte stilte spørsmål

Hvilken forsinkelse er realistisk med LL-HLS?

Typisk 3 til 6 sekunder fra kamera til skjerm når encoderen er riktig satt opp med kort keyframe-intervall. Klassisk HLS ligger på 20 til 40 sekunder. Under ett sekund krever WebRTC hele veien til seeren, som skalerer dårligere og sjelden er nødvendig for konferanser.

Skal jeg bruke RTMP eller SRT?

RTMP på kablet, stabil linje med lavt pakketap. SRT på alt annet: mobil, bonding, hotell-wifi. SRT tåler pakketap langt bedre. Har encoderen og plattformen begge SRT, er det trygt å bruke det overalt.

Hvorfor er keyframe-intervallet så viktig?

Segmentene plattformen lager må starte på en keyframe. Med lange intervaller mellom keyframes blir segmentene lange og forsinkelsen høy. Sett 1 til 2 sekunder og deaktiver scenecut for å få lav forsinkelse.

Må jeg sende flere kvaliteter fra encoderen?

Nei. Send én strøm i høyeste kvalitet du vil distribuere, typisk 1080p. Plattformen transkoder til en ladder av lavere nivåer, og spilleren velger automatisk eller lar seeren velge manuelt.

Hva er WHIP og når bruker jeg det?

WHIP lar en nettleser sende direkte til plattformen med WebRTC uten encoder-programvare. Bruk det til enkle sendinger fra webkamera, gjester fra hjemmekontor og nettleserbaserte studioløsninger. For fullverdig produksjon med kontroll over bitrate og kodek, bruk en dedikert encoder over RTMP eller SRT.

Hvorfor mangler kvalitetsvelgeren på iPhone?

Safari på iOS bruker Apples innebygde HLS-avspilling, som styrer kvalitetsvalget selv og ikke viser en manuell velger. Det er en begrensning fra Apple, ikke plattformen. På Android og alle PC-nettlesere er velgeren tilgjengelig.