Hva er multistreaming, og hvorfor er det viktig?​

Multistreaming betyr i praksis at én enkelt utgående RTMP-strøm fra encoder-en din (typisk OBS, vMix eller en hardware-encoder) blir mottatt av en relé-tjener, som så videreformidler den samme strømmen til flere mål-plattformer parallelt. Du laster opp én strøm, men ender opp live på Twitch, YouTube, Kick og Facebook Gaming på én gang.

Den åpenbare fordelen er rekkevidde. Twitch dominerer fortsatt gaming-streaming i Norden, men YouTube har overlegen oppdagbarhet via søk og anbefalinger, mens Kick har vokst kraftig blant streamere som vil ha bedre inntektsdeling. Hvis du tvinger publikum til å velge én plattform, mister du seerne som er låst til en annen. Multistreaming fjerner dette valget.

Den mindre åpenbare fordelen er båndbreddeøkonomi. En typisk 1080p60-strøm på 6000 kbps krever omtrent 6,5 Mbit/s stabil oppstrøms-båndbredde. Hvis du sender direkte fra OBS til tre plattformer parallelt, snakker vi 19,5 Mbit/s — godt over hva mange norske fiber-abonnementer leverer stabilt mot internasjonale endepunkter. En relé-tjener i et datasenter med 1 Gbit/s symmetrisk uplink løser dette: du sender én gang opp, og tjeneren håndterer fan-out til de tre plattformene.

Hvilke plattformer støtter dette?​

Alle de store streaming-plattformene aksepterer RTMP-input. Nedenfor er de viktigste destinasjonene og deres ingest-endepunkter:

• Twitch: rtmp://live.twitch.tv/app/{stream-key} — for nordiske streamere, bruk live-arn.twitch.tv eller live-cph.twitch.tv for nærmere ingest
• YouTube Live: rtmp://a.rtmp.youtube.com/live2/{stream-key}
• Kick: rtmps://{ingest}.kick.com/live/{stream-key} — Kick bruker RTMPS (kryptert)
• Facebook Live: rtmps://live-api-s.facebook.com:443/rtmp/{stream-key}

StreamAdmin støtter inntil 5 samtidige restream-destinasjoner per kilde-strøm, som dekker alle de praktisk relevante kombinasjonene.

Tekniske krav og båndbredde​

Før du i det hele tatt vurderer multistreaming, må du sjekke at hjemmelinjen din kan levere én stabil høykvalitets-strøm. En 1080p60-strøm på 6000 kbps trenger som tommelfingerregel 7-8 Mbit/s stabil oppstrøms for å gi headroom mot midlertidige nedganger. Hvis du har en typisk norsk 100/100-fiber, har du mer enn nok — men test alltid med en speedtest mot Stockholm eller Frankfurt, ikke mot lokale Telenor-servere, fordi du ofte ser kunstig høye tall mot norske endepunkter.

Twitch sin maks-bitrate​

Twitch oppgir 6000 kbps som maks anbefalt bitrate for både Affiliate og Partner-streamere. Dette er ikke et hardt tak, men du risikerer at strømmen blir avvist eller at transcoding-kvaliteten lider hvis du går over. For 1080p60 ligger sweet-spot mellom 4500-6000 kbps med x264-encoder satt til medium eller slow preset.

YouTube er mer fleksible og aksepterer opptil 9000 kbps for 1080p60 og høyere for 1440p/2160p. Hvis du multistreamer mot både Twitch og YouTube, må du tilpasse deg den laveste fellesnevneren — eller bruke en relé-tjener som transkoderer for å levere ulik bitrate til ulike destinasjoner.

CPU eller GPU-encoding?​

For multistreaming via relé spiller dette mindre rolle, fordi du sender bare én strøm fra OBS. Med x264 på medium-preset og 1080p60 trenger du en relativt kraftig CPU (Ryzen 5 5600X eller bedre). Med NVENC på et moderne RTX-kort får du tilsvarende kvalitet med minimal CPU-belastning, og dette er ofte førstevalg for streamere som spiller krevende spill samtidig.

Sette opp multistreaming i StreamAdmin​

StreamAdmin sin restream-arkitektur er bygget rundt MediaMTX som relé-server. Du sender én RTMP-strøm til StreamAdmin, og panelet håndterer fan-out til alle dine konfigurerte destinasjoner. Oppsettet i panelet er todelt: først definerer du dine destinasjoner (kilde-plattformer med stream-keys), deretter knytter du dem til en streaming-profil.

Steg 1: Legg til destinasjoner​

I StreamAdmin-panelet under "Restream Destinations" legger du til hver plattform du vil sende til. For hver destinasjon trenger du:

• En lesbar tittel (f.eks. "Twitch — Hovedkanal")
• RTMP- eller RTMPS-URL til ingest-tjeneren
• Stream-key fra plattformen

Stream-keys lagres kryptert i databasen og dekrypteres bare når de skal sendes til MediaMTX-konfigurasjonen ved sesjonsstart. Dette er viktig hvis du gir andre tilgang til admin-panelet ditt — de vil aldri se nøklene i klartekst.

Steg 2: Konfigurer streaming-profilen​

En streaming-profil i StreamAdmin samler innstillinger for kvalitet, opptak og restream. Profil-eksempel:

# Eksempel på StreamAdmin streaming-profil
profile_name: "Hovedstrøm 1080p60"
input_format: rtmp
input_bitrate_max: 6000
recording:
  enabled: true
  format: mp4
  segment_duration: 3600
restream_targets:
  - twitch_main
  - youtube_main
  - kick_main
qos_monitoring: true

Når du så starter strømmen din mot StreamAdmin sin RTMP-ingest, blir den automatisk videresendt til de tre destinasjonene parallelt.

Steg 3: OBS-konfigurasjon​

I OBS bytter du Settings → Stream til "Custom..." og fyller inn:

• Server: rtmp://din-streamadmin-server.no/live (eller hva du har konfigurert)
• Stream Key: Din StreamAdmin stream-key (32-tegn hex generert ved profil-opprettelse)

Under Output → Streaming velger du encoder (x264 eller NVENC), bitrate (4500-6000 kbps for 1080p60 mot Twitch som laveste fellesnevner), keyframe-interval på 2 sekunder, og rate control CBR. CBR (Constant Bitrate) er obligatorisk for de fleste streaming-plattformer — VBR kan føre til ujevn kvalitet og buffering hos seerne.

# Anbefalte OBS Output-innstillinger for multistream
output_mode = Advanced
encoder = NVENC H.264 (eller x264 på medium preset)
rate_control = CBR
bitrate = 6000
keyframe_interval = 2
preset = Quality (NVENC) eller medium (x264)
profile = high
b_frames = 2

Kvalitetsinnstillinger per plattform​

En av de mest undervurderte aspektene ved multistreaming er at hver plattform har sine egne anbefalte spesifikasjoner. Å lande på en konfigurasjon som fungerer godt på alle samtidig krever at du forstår hvor begrensningene ligger.

Twitch​

Som nevnt: 6000 kbps maks bitrate, 1080p60 maks oppløsning. Twitch transcoder ikke automatisk for ikke-Partner-streamere, så seere med dårlig båndbredde kan ikke senke kvaliteten — de mister strømmen helt. Dette taler for å holde bitrate i den lavere enden (4500-5000 kbps) med mindre du har et veldig stabilt publikum.

YouTube Live​

YouTube transcoder alltid og er mye mer tolerante. Du kan trygt sende 9000 kbps for 1080p60 hvis kanalen din støtter det, og 1440p eller 4K hvis du har båndbredde og maskinvare. Hvis du multistreamer er det imidlertid greit å sende samme strøm til alle — å ha to separate encoder-utganger fra OBS koster CPU/GPU og er sjelden verdt det.

Kick​

Kick aksepterer opptil 8000 kbps og 1080p60. De bruker RTMPS (port 443) i stedet for RTMP, så sjekk at relé-tjeneren din støtter dette. StreamAdmin via MediaMTX støtter både RTMP og RTMPS-output.

Facebook Live​

Facebook har strenge krav til keyframe-interval (maks 2 sekunder) og foretrekker H.264 high-profile. Bitrate-grensen ligger på 4000 kbps for 1080p, så hvis Facebook er en av destinasjonene dine bør du holde hovedstrømmen på 4000 kbps eller la relé-tjeneren transkode ned for Facebook spesifikt.

Vanlige feil og feilsøking​

"Stream droppet" eller frame drops​

Den hyppigste årsaken er ustabil oppstrøms-båndbredde mellom deg og StreamAdmin sin ingest-server. Sjekk OBS Stats-panelet (View → Stats) under en aktiv strøm. Hvis "Dropped frames (network)" øker, har du nettverksproblem. Test mot en server geografisk nær deg, og vurder å bruke SRT i stedet for RTMP — SRT på port 8890 i StreamAdmin håndterer pakketap mye bedre enn RTMP og er nesten alltid å foretrekke for ustabile linjer.

Én plattform feiler, andre fungerer​

Hvis Twitch fungerer men YouTube ikke kommer på lufta, er det nesten alltid feil stream-key eller utløpt key. YouTube genererer ny stream-key hver gang du oppretter en ny "Stream" i Studio — gamle keys blir invalidert. Sjekk at key-en i StreamAdmin er den nyeste. For Kick er det også vanlig at RTMPS-sertifikater må valideres — slå av peer-verifisering midlertidig i MediaMTX hvis du får TLS-feil under testing.

Lyd-problemer på en plattform men ikke en annen​

Sjekk at OBS sender lyd som AAC, 44.1 eller 48 kHz, og 160 kbps eller høyere. Noen plattformer (særlig YouTube) er pirkete på dette. Hvis du har nedmiks via OBS Audio Mixer, sjekk at master-bus ikke clipper.

Forskjellig latens mellom plattformer​

Helt normalt. Twitch har Low Latency Mode som gir 2-4 sekunders forsinkelse, mens YouTube ofte ligger på 10-20 sekunder default. Kick og Facebook varierer. Du kan ikke synkronisere disse — hvis du driver med interaktive segmenter (chat-respons, giveaways) må du velge én primær plattform å reagere mot.

QoE-monitorering: ikke streame i blinde​

StreamAdmin samler QoE-metrics (Quality of Experience) i sanntid: bitrate-stabilitet, frame drops, viewer-tracking per destinasjon, og latensestimater. Bruk dette aktivt — hvis du ser at YouTube viser "Good" mens Twitch viser "Poor" gjennom hele økten, er det enten Twitch sin ingest som har problemer den dagen, eller du har valgt en geografisk dårlig ingest-region. Bytt til en annen Twitch-region (f.eks. live-arn.twitch.tv for Stockholm) og se om problemet forsvinner.

Avslutning​

Multistreaming er ikke lenger et "nice to have" for streamere som vil bygge publikum profesjonelt — det er standard. Med StreamAdmin sin relé-baserte arkitektur slipper du å belaste hjemmelinjen din med flere parallelle utgående strømmer, og du får sentralisert kontroll over destinasjoner, kvalitet og overvåking. Den største feilen du kan gjøre er å multistreame uten å monitorere QoE — å sende dårlig strøm til tre plattformer samtidig er verre enn å sende god strøm til én.

Vil du teste oppsettet? Opprett en konto på streamadmin.no og følg den utvidede dokumentasjonen på doc.geektech.no/streamadmin. Du kan også kikke på en faktisk produksjonskanal som bruker oppsettet på twitch.tv/skynett81. Spørsmål eller behov for hjelp? Bli med i Discord-serveren vår — der finner du både utviklere og andre streamere som har vært gjennom de samme oppsettene.

Hva er NOALBS, og hvorfor er det relevant?​

NOALBS er et åpen kildekode-verktøy skrevet i Rust som overvåker streaming-helse i sanntid og automatisk reagerer på fall i bitrate eller pakketap. Verktøyet ble opprinnelig utviklet for IRL-streaming-miljøet, der streamere bruker mobilforbindelser som varierer enormt avhengig av bevegelse, været, og hvor mange andre som er på samme celletårn.

Kjerneideen er enkel: hvis bitraten din faller under en gitt terskel, betyr det at strømmen er i ferd med å bli ustabil. I stedet for å la seerne se en frosset eller forvrengt strøm, bytter NOALBS automatisk til en "low bitrate"-scene — typisk en statisk "Stand by, network issues"-overlay — og bytter tilbake automatisk når bitraten er stabilisert.

Verktøyet fungerer ved å lese metrikker fra streaming-tjeneren (StreamAdmin/MediaMTX i vårt tilfelle) og kommunisere med OBS via OBS WebSocket-protokollen. Det er gratis, åpen kildekode, og er bredt brukt av profesjonelle IRL-streamere på Twitch og YouTube.

Når trenger du NOALBS?​

• Mobil-streaming (4G/5G): Helt nødvendig. Bitraten kan svinge fra 8000 til 800 kbps på et kvartal i bevegelse.
• Hjemmenettverk delt med mange: Hvis det skjer noe rart med Wi-Fi-en eller noen i husholdningen plutselig laster ned 50 GB, vil NOALBS skjerme strømmen din.
• Backup-linje failover: Hvis du har dual-WAN setup (fiber + 4G failover), kan NOALBS varsle om degradering og bytte scene før seerne merker det.
• Studio-streaming på stabil fiber: Trolig overkill, men kan fortsatt være nyttig som beskyttelse mot uventede ISP-glitches.

Installasjon og grunnkonfigurasjon​

NOALBS distribueres som binærer for Linux, macOS og Windows fra GitHub-repository-et. Hvis du kjører streaming-PC-en på Windows (som de fleste streamere gjør), last ned siste Windows-binær og pakk den ut til en mappe der du har skrivetilgang.

# Eksempel: PowerShell på Windows
mkdir C:\noalbs
cd C:\noalbs
# Last ned noalbs.exe og config.json fra GitHub releases
# https://github.com/715209/nginx-obs-automatic-low-bitrate-switcher/releases

Konfigurasjonsfilen er en JSON-fil med fornuftige defaults, men du må fylle inn dine egne verdier for OBS WebSocket og streaming-server-endepunkt:

{
  "user": {
    "id": "din-streamer-id",
    "password_hash": ""
  },
  "switcher": {
    "bitrate_switcher_enabled": true,
    "only_switch_when_streaming": true,
    "instantly_switch_on_recover": false,
    "auto_switch_notification": true,
    "triggers": {
      "low": 1500,
      "rtt": 2500,
      "offline": 200
    },
    "switching_scenes": {
      "normal": "Live",
      "low": "LowBitrate",
      "offline": "Offline"
    }
  },
  "software": {
    "useObs": true,
    "obs": {
      "host": "localhost",
      "password": "din-obs-websocket-passord",
      "port": 4455
    }
  },
  "streamServers": [
    {
      "type": "Nginx",
      "name": "StreamAdmin",
      "stats_url": "https://din-streamadmin.no/api/stats",
      "application": "live",
      "key": "din-stream-key"
    }
  ]
}

OBS WebSocket må være aktivert​

Fra OBS 28 og oppover er WebSocket-pluginen innebygget. Aktiver den under Tools → WebSocket Server Settings, sett et passord, og noter port-nummeret (default 4455). NOALBS bruker dette for å sende scenebytte-kommandoer.

Integrasjon med StreamAdmin​

StreamAdmin eksponerer et NOALBS-kompatibelt stats-endepunkt som rapporterer sanntids-bitrate og pakketap for hver aktive strøm. Endepunktet ligger på /api/v1/streams/{stream-id}/noalbs-stats og krever en API-token for autentisering.

I admin-panelet under "Streaming → API Tokens" oppretter du en token spesifikt for NOALBS-bruk. Disse tokens har read-only tilgang til stats-endepunkter og kan revoceres uavhengig av andre integrasjoner.

# StreamAdmin-side konfigurasjon
noalbs_integration:
  enabled: true
  poll_interval_seconds: 2
  metrics:
    - bitrate_kbps
    - dropped_frames_per_minute
    - rtt_ms
    - packet_loss_percent
  triggers:
    notify_on_threshold_breach: true
    threshold_breach_webhook: https://hooks.slack.com/...

Når NOALBS poller dette endepunktet (default hvert 2. sekund), får den et JSON-svar med nåværende bitrate, RTT (round-trip-time) og pakketap. Den sammenligner mot terskelverdiene i config og handler deretter.

Bitrate-terskel­verdier: hva bør du sette?​

Default-verdiene som kommer med NOALBS er konservative og funker greit for de fleste, men terskelverdier bør tunes til din spesifikke setup. La oss gå gjennom hva hver verdi betyr:

low — den kritiske terskelen​

Dette er bitraten under hvilken NOALBS bytter til "low bitrate"-scene. Default er 800 kbps, men dette er for lavt for moderne 1080p-streaming.

For en 1080p60-strøm normalt på 6000 kbps:

• Konservativ: low: 3500 — bytter scene tidlig, før seerne merker noe
• Balansert: low: 2500 — gir litt buffer, bytter ved tydelige problemer
• Aggressiv: low: 1500 — bytter bare ved alvorlige problemer (godt for IRL hvor svingninger er vanlig)

For 720p-streaming kan du senke disse med ca 40-50% (siden 720p normalt streames på 3500-4500 kbps).

rtt — round-trip-time​

Dette er forsinkelsen på pakker mellom encoder og streaming-server. Høy RTT indikerer nettverkstrengsel selv om bitraten holder seg oppe. Default 2500 ms er en god start; for IRL-streamere bør du senke til 1500 ms for tidligere varsling.

offline — komplett tap​

Hvis bitraten faller under denne (default 200 kbps), regnes strømmen som offline og NOALBS bytter til en dedikert "Offline"-scene. Denne brukes når forbindelsen er helt borte, typisk i tunneller eller døde soner.

Hysterese: unngå "scene-flapping"​

Det viktigste å forstå er at NOALBS har innebygget hysterese — den bytter ikke tilbake til normal scene før bitraten har vært stabil over terskelen i en gitt periode (default 5-10 sekunder). Uten dette ville scenen flippe frem og tilbake hvert sekund ved marginale forbindelser.

"triggers": {
  "low": 2500,
  "rtt": 2000,
  "offline": 200,
  "switching_delay": 5,
  "recovery_delay": 10
}

Scene-bytting og hva "low bitrate"-scenen bør inneholde​

Den vanligste feilen førstegangsbrukere gjør er å lage en kjedelig "stand by"-scene som bare viser tekst på sort bakgrunn. Dette får seerne til å forlate strømmen umiddelbart. Den bedre tilnærmingen er å lage en scene som:

1. Beholder lyden fra mikrofonen din — du kan fortsatt snakke selv om kamera er borte
2. Viser en lavbitrate-egnet visuell — et statisk bilde, en saktegående animasjon, eller en pre-renderet loop
3. Kommuniserer hva som skjer — "Network catching up, hold tight!" er bedre enn ingenting
4. Beholder chat-overlay — så interaksjonen kan fortsette

For IRL-streamere er det vanlig å ha en mini-galleri-scene med tidligere bilder fra strømmen, eller en kart-overlay som viser hvor du er. Dette holder seerne engasjert mens forbindelsen kommer tilbake.

SRT i stedet for RTMP for ustabile linjer​

Et viktig poeng: NOALBS hjelper deg å håndtere konsekvensene av ustabil båndbredde, men det fikser ikke roten av problemet. Hvis du streamer fra en mobil-forbindelse, bør du bruke SRT i stedet for RTMP fra OBS til StreamAdmin.

SRT (Secure Reliable Transport) er designet spesifikt for upålitelige nettverk. Det legger til foroverkorreksjon (FEC) og pakke-retransmisjon, som betyr at midlertidige pakketap håndteres på protokoll-nivå i stedet for å manifestere seg som video-glitches. StreamAdmin støtter SRT på port 8890.

# OBS Custom Service for SRT mot StreamAdmin
service = Custom...
server = srt://din-streamadmin.no:8890?streamid=publish:din-stream-key&latency=2000000
streamkey = (la stå tom — streamid håndterer dette)

Latency-parameteren (2000000 mikrosekunder = 2 sekunder) er buffer-størrelsen som SRT bruker for å reordre pakker. Høyere verdier gir mer robusthet mot pakketap, men også høyere total latens. For IRL er 2-4 sekunder en god balanse.

Vanlige feil og feilsøking​

NOALBS bytter aldri scene​

Sjekk i denne rekkefølgen:

1. OBS WebSocket aktivert og passordet er riktig i config.json
2. Scene-navn i config matcher EKSAKT scene-navnene i OBS (case-sensitive)
3. bitrate_switcher_enabled: true er satt
4. NOALBS-loggen viser at den faktisk poller stats-endepunktet

Scene flipper frem og tilbake konstant​

Du har for høy low-terskel sammenlignet med din normale bitrate, eller for lav recovery_delay. Øk recovery_delay til 15-20 sekunder, eller senk low med 500-1000 kbps.

NOALBS får ikke kontakt med StreamAdmin stats-endepunkt​

API-token kan være feil eller utløpt, eller du står bak en streng firewall som blokkerer utgående HTTPS-kall. Test endepunktet manuelt med curl:

curl -H "Authorization: Bearer din-token" \
  https://din-streamadmin.no/api/v1/streams/din-stream-id/noalbs-stats

Hvis du får 200 OK med JSON-data, er konfigurasjonen riktig.

Bitrate-data ser ut til å være forsinket​

Default poll-interval på 2 sekunder er en god balanse, men for IRL hvor situasjonen endrer seg raskt kan du senke til 1 sekund. Ikke gå lavere — det belaster bare StreamAdmin sitt API uten å gi merverdi.

QoE-data som tilbakemelding​

StreamAdmin samler QoE-metrics over tid og viser dette som grafer i admin-panelet. Etter en streaming-økt bør du se på "Bitrate over Time"-grafen og sjekke når NOALBS faktisk byttet scener. Hvis du ser at den byttet 47 ganger på en time, er terskelverdiene dine for aggressive — eller du har et nettverksproblem som krever løsning på protokoll-nivå (SRT) i stedet for application-nivå (NOALBS).

Den ideelle strømmen har 0-2 scenebytter per time, og bare ved faktiske, merkbare forbindelsesproblemer. Hvis du oppnår dette, har du en konfig som beskytter seerne uten å være overdrevent reaktiv.

Avslutning​

NOALBS er et nesten obligatorisk verktøy for enhver streamer som ikke har 100% pålitelig fiber-forbindelse. Det er gratis, åpen kildekode, og integrerer rent med StreamAdmin via et dedikert stats-endepunkt. Den største fellen er å bruke default-terskelverdier uten å tune dem — bruk noen økter på å observere din typiske bitrate-profil, og still inn NOALBS deretter.

For full dokumentasjon av StreamAdmin sin NOALBS-integrasjon, se doc.geektech.no/streamadmin. Vil du komme i gang med StreamAdmin? Registrer deg på streamadmin.no. Har du tunet en NOALBS-konfig som funker spesielt godt for ditt setup, eller har spørsmål om SRT-latency-tuning? Bli med i Discord-serveren vår — vi snakker mye om dette der.

Hva er en VOD-pipeline, egentlig?​

Begrepet "VOD-pipeline" høres komplisert ut, men er bare en kjede av automatiserte steg som tar et live-opptak og gjør det klart for konsum etter at strømmen er avsluttet. En typisk pipeline ser slik ut:

1. Opptak — Live-strømmen fanges opp samtidig som den sendes til seere, og lagres som en flat fil (TS, FLV eller MP4)
2. Segmentering — Lange opptak deles i håndterbare biter (timesvis eller per scene)
3. Transkoding — Råfilen kjøres gjennom FFmpeg for å produsere distribusjonsklare formater (H.264 MP4 i ulike oppløsninger, eventuelt HLS-segmenter)
4. Generering av metadata — Thumbnails, varighet, sceneskift-indeks
5. Distribusjon — Filene flyttes til CDN, lastes opp til YouTube via API, eller publiseres på egen webserver
6. Arkivering — Råfilen flyttes til kald lagring (S3 Glacier, Backblaze B2 eller eget NAS)

Uten en pipeline ender du med en mappe full av navnløse .flv-filer som du må manuelt konvertere hver gang du skal bruke dem. Med en pipeline er dette automatisk fra det øyeblikket du klikker "End Stream" i OBS.

Innspillingsformater og kvalitet​

Hvilket format bør du ta opp i?​

For live-streaming-opptak er det tre hovedformater som er aktuelle:

FLV (Flash Video) — Dette er det "native" RTMP-formatet og brukes av OBS og MediaMTX som standard. Fordeler: lite overhead, robust mot brå avbrudd (filen blir spillbar selv om du krasjer midt i opptaket). Ulemper: dårlig kompatibilitet med moderne videoredigeringsprogrammer.

MPEG-TS (Transport Stream) — Brukt for HLS og kringkastingsformater. Fordel: håndterer pakketap og avbrudd bedre enn nesten noe annet format, og er trivielt å segmentere. Ulempe: krever ofte transkoding før det kan redigeres.

MP4 (med fragmentert moov-atom) — Det moderne valget. Bruker -movflags +frag_keyframe+empty_moov i FFmpeg slik at filen blir spillbar selv om opptaket avbrytes uventet. Fordel: direkte avspillbar, redigerbar, distribusjonsklar. Ulempe: marginalt mer overhead enn FLV/TS.

For StreamAdmin-pipelines anbefaler vi MP4 med fragmenterte atomer som standard, og fall-back til TS hvis du har spesielt ustabile innspillingstjenere.

Bitrate og oppløsning for opptak​

Et viktig prinsipp: opptak skal ALDRI ha lavere bitrate enn det du sender til live. Hvis du sender 6000 kbps til Twitch og tar opp på 4000 kbps lokalt, har du destruert 33% av kvaliteten på arkivet ditt for å spare diskplass. Diskplass er billig — gjenopptak er umulig.

For seriøse arkiver bør du faktisk ta opp i høyere kvalitet enn live-strømmen. Hvis live-strømmen er begrenset til 6000 kbps for Twitch, ta opp lokalt på 12000-15000 kbps med samme oppløsning. Når du så transkoder for distribusjon kan du senke til ønsket nivå, men du har den høykvalitets-mesteren liggende.

Automatisk opptak med StreamAdmin​

StreamAdmin sin streaming-profil har innebygd opptak via MediaMTX. Når du oppretter en profil, kan du sette:

recording:
  enabled: true
  format: mp4
  segment_duration: 3600  # ny fil hver time
  output_path: "/var/streamadmin/recordings/{stream_name}/{date}/{time}.mp4"
  delete_after_processing: false
  max_disk_usage_gb: 500

segment_duration på 3600 sekunder (én time) er en god default. Det gir håndterbare filstørrelser (cirka 4-8 GB per time ved 1080p60), og hvis disken fylles eller MediaMTX kræsjer, mister du maks én time.

Filene navngis automatisk med tidsstempel, og StreamAdmin lagrer metadata (start-tid, varighet, peak-viewers, peak-bitrate) i vod_recordings-tabellen. Dette gjør at du kan finne et spesifikt opptak via panelet uten å lete i filsystemet manuelt.

Trigger transkoding ved end-of-stream​

Når en live-økt avsluttes, sender MediaMTX et webhook-kall til StreamAdmin sin API. Dette webhook-et trigger en kø-jobb (Laravel Queue) som starter transkodings-pipelinen. Den asynkrone modellen er viktig: transkoding av en 4-timers økt kan ta 30-60 minutter, og det skal ikke holde på MediaMTX sin tråd.

// StreamAdmin job som trigges ved end-of-stream
class TranscodeVodJob implements ShouldQueue
{
    public function handle(): void
    {
        $this->transcodeToMp4();      // hovedfil i 1080p
        $this->generateThumbnails();   // 10 thumbnails per time
        $this->generateHlsManifest();  // for direkte avspilling
        $this->uploadToStorage();      // S3, B2, eller egen tjener
        $this->notifyWebhooks();       // varsle om at VOD er klar
    }
}

Transkoding til ulike oppløsninger med FFmpeg​

FFmpeg er hjernen i enhver VOD-pipeline. Den kommandoen du velger her bestemmer kvalitet, filstørrelse og kompatibilitet på sluttbruker-siden.

Standard transkode-kommando for VOD​

ffmpeg -i input.mp4 \
  -c:v libx264 \
  -preset slow \
  -crf 21 \
  -pix_fmt yuv420p \
  -profile:v high \
  -level 4.1 \
  -movflags +faststart \
  -c:a aac \
  -b:a 160k \
  -ar 48000 \
  output_1080p.mp4

Nøkkelparametere å forstå:

• -preset slow — Tar lengre tid å enkode, men gir bedre kvalitet per byte. For VOD (asynkron) er slow eller slower riktig valg. Aldri bruk ultrafast eller veryfast for arkiv-kvalitet.
• -crf 21 — Constant Rate Factor. Lavere tall = bedre kvalitet og større filer. 18-23 er normalt området; 21 er en god default for 1080p.
• -movflags +faststart — Flytter moov-atomet til starten av filen. Dette gjør at videoen kan starte avspilling før den er fullstendig nedlastet — kritisk for web-streaming.
• -pix_fmt yuv420p — Sikrer kompatibilitet med eldre nettlesere og mobile enheter. Uten dette risikerer du at videoen ikke spiller på iPhone.

Multi-bitrate transkoding for adaptiv strømming​

Hvis du vil tilby HLS adaptiv strømming på egen tjener, må du produsere flere oppløsninger samtidig:

ffmpeg -i input.mp4 \
  -filter_complex "[0:v]split=3[v1][v2][v3]; \
    [v1]scale=1920:1080[v1080]; \
    [v2]scale=1280:720[v720]; \
    [v3]scale=854:480[v480]" \
  -map "[v1080]" -c:v:0 libx264 -b:v:0 5000k -preset slow \
  -map "[v720]"  -c:v:1 libx264 -b:v:1 2800k -preset slow \
  -map "[v480]"  -c:v:2 libx264 -b:v:2 1400k -preset slow \
  -map 0:a:0 -map 0:a:0 -map 0:a:0 \
  -c:a aac -b:a 128k \
  -f hls \
  -hls_time 6 \
  -hls_playlist_type vod \
  -hls_segment_filename "v%v/segment_%03d.ts" \
  -master_pl_name master.m3u8 \
  -var_stream_map "v:0,a:0 v:1,a:1 v:2,a:2" \
  "v%v/playlist.m3u8"

Dette produserer tre kvalitetsnivåer (1080p, 720p, 480p) i HLS-format, klare for direkte avspilling i en HTML5-spiller eller via en CDN.

Lyd: ikke gå på akkord​

Lyd er det første publikum klager på, og det er gratis å gjøre riktig. Bruk alltid AAC i -b:a 160k eller høyere, samplingrate 48 kHz. Hvis kildematerialet er stereo, behold stereo. Ikke down-mix til mono "for å spare plass" — det merkes umiddelbart.

Distribusjon: YouTube, egen CDN, eller dedikerte arkiv-tjenere​

YouTube via Data API v3​

Mange streamere klipper hovedhøydepunkter manuelt og laster opp til YouTube. Dette skalerer dårlig hvis du streamer 4-5 økter per uke. YouTube Data API v3 lar deg laste opp programatisk, og StreamAdmin kan integrere mot dette via OAuth:

# Pseudo-flow:
# 1. Bruker autentiserer med YouTube OAuth i StreamAdmin
# 2. StreamAdmin lagrer refresh token kryptert
# 3. Etter VOD-transkoding: laster opp via API
# 4. Setter tittel, beskrivelse, thumbnail, kategori, taggene fra stream-metadata

Vær oppmerksom på YouTube sine kvotegrenser — Data API v3 har en daglig kvote på 10 000 enheter, og hver upload koster 1600 enheter. I praksis betyr dette omtrent 6 uploads per dag før du må be om kvote-økning.

Egen CDN: Cloudflare R2 eller Backblaze B2​

Hvis du vil hoste VOD-arkivet selv (kontroll, ingen YouTube-monetiseringsregler, lavere kostnader på lang sikt), er Cloudflare R2 og Backblaze B2 de to beste alternativene. Begge tilbyr S3-kompatible APIer, og begge har gratis egress når du serverer via Cloudflare.

# Eksempel: last opp til Cloudflare R2 med rclone
rclone copy /var/streamadmin/recordings/processed/2026-05-02_episode-87.mp4 \
  r2:streamadmin-vods/2026/05/ \
  --progress \
  --transfers 4

Cloudflare Stream er et alternativ til "ren" R2 hvis du vil ha innebygd HLS adaptiv strømming uten å selv segmentere. Det koster mer per minutt video, men sparer deg for FFmpeg-arbeidet.

Dedikert arkiv-tjener med Nginx​

For den som vil ha full kontroll: en VPS med stor disk (Hetzner sitt SX-line, OVH eller eget hardware) og Nginx med mp4-modulen aktivert gir deg en personlig YouTube. Pseudo-konfig:

location /vod/ {
    mp4;
    mp4_buffer_size 1m;
    mp4_max_buffer_size 5m;
    add_header Accept-Ranges bytes;
    root /var/vods;
}

Med dette serveres MP4-filer med byte-range support, slik at sluttbrukere kan hoppe frem og tilbake i videoen uten å laste den helt ned.

Lagringsstrategi og kostnader​

Her er hvor mange streamere undervurderer kompleksiteten. La oss regne på en realistisk produksjonsstreamer som streamer 4 ganger i uka, 4 timer per økt:

• 16 timer/uke live-tid
• 1080p60 ved 6 Mbit/s = ca 2,7 GB/time
• Live-arkiv: 16 × 2.7 = ~43 GB/uke = ~2,2 TB/år

Hvis du i tillegg lagrer et høykvalitets-master på 12 Mbit/s, dobles dette til ~4,4 TB/år. Etter tre år snakker vi 13 TB ren videodata. Dette er ikke "litt diskplass" lenger — det er en datasenter-investering.

Tre-nivå lagringsstrategi​

Den profesjonelle løsningen er tiered storage:

1. Hot tier (siste 30 dager): SSD eller raskt NVMe på selve transkode-tjeneren. Brukes til umiddelbare klipping/distribusjon. Pris: høy per GB.
2. Warm tier (30 dager - 1 år): Spinning rust på samme tjener, eller B2/R2 standard. Sjelden tilgang, men rimelig hentbar. Pris: lav per GB.
3. Cold archive (>1 år): S3 Glacier Deep Archive eller eget NAS-system uten online-tilgjengelighet. Pris: nesten ingenting per GB, men dyrt å hente ut.

StreamAdmin sin VOD-modul kan automatisk flytte filer mellom disse nivåene basert på alder via en kø-jobb som kjører nattlig.

Avslutning​

En VOD-pipeline er ikke noe du setter opp på 30 minutter mellom to streams. Det er infrastruktur som krever planlegging av lagring, encoding-kvalitet, distribusjon og arkivering — men det er også infrastruktur som lønner seg eksponensielt over tid. En streamer med tre års velorganisert VOD-arkiv har en innholdsbase som er nesten umulig å kopiere; en streamer uten arkiv starter på null hver gang.

Vil du komme i gang? Les den fullstendige dokumentasjonen på doc.geektech.no/streamadmin eller opprett en konto direkte på streamadmin.no. Hvis du har spørsmål om FFmpeg-parametere, transkode-strategier eller har funnet en bedre kombinasjon enn det vi anbefaler her, snakk med oss i Discord — vi sitter ofte og diskuterer encoding-tradeoffs sent på kveld der.