Når 4 000 ansatte logger seg på samme all-hands samtidig, er det noen som betaler noen for de bytene. Vanligvis er den noen et abonnement på Microsoft Stream, Zoom Webinar, Vimeo Enterprise eller Brightcove, bytene forlater bedriftsnettet et øyeblikk, spretter mot et tredjeparts datasenter, og kommer tilbake til samme nett via en annen forbindelse. Konsernsjefen sitter i et møterom to dører bortenfor, og videoen av ham reiser til Frankfurt og tilbake.
Dette fungerer fint helt til noen stiller spørsmålet det ikke finnes et godt svar på. «Hvorfor går trafikken fra vår interne town hall via en tredjeparts SaaS?» Compliance spør om det før en revisjon i en regulert bransje. Sikkerhetsavdelingen spør om det etter hvert sikkerhetsbrudd der en strømmeleverandør nevnes. Finansdirektøren spør om det når SaaS-regningen per seer skal fornyes. IT spør om det første gang byggets WAN-link blir mettet fordi all-hands-en setter rekord i oppmøte.
Det ærlige svaret er at corporate live-strømming utviklet seg rundt RTMP-encodere og SaaS-plattformer fordi alternativene enten var dyre (Cisco enterprise video, eCDN-utstyr fra Kollective og Hive Streaming, internt CDN-utstyr) eller hjemmesnekret på en måte ingen i et typisk IT-team hadde kapasitet til å vedlikeholde. Bedrifter valgte SaaS fordi ingenting annet var innen rekkevidde.
Det har endret seg. Encoderen, transkoderen, pakkeren og publisher-en har smeltet sammen til ett stykke programvare som kjører på en Mac. Destinasjonen trenger ikke være en leverandør. Pekt mot en webserver innenfor brannmuren produserer den samme programvaren broadcast-standard HLS som de ansatte strømmer over bedrifts-LAN-et, og ingenting forlater nettet.
Denne artikkelen handler om akkurat det.
Hvordan «intern corporate live» faktisk ser ut
Det meste av intern video i en typisk bedrift faller inn i en kort liste tilbakevendende bruksområder.
Kvartalsvise all-hands og town hall med konsernsjefen. Store publikum (ofte hele selskapet), lav frekvens (fire til tolv ganger i året), beskjeden produksjon. Latenstoleransen er romslig, femten til tretti sekunder er greit fordi det ikke er toveis interaksjon under foredraget, og Q&A håndteres i en separat kanal.
Opplæring og sertifiseringskurs. Noen ganger live, ofte sett om igjen. Maks noen hundre samtidige seere. Produksjonen består av ett kamera, én foredragsholder og lysbilder delt fra en laptop.
Produktlanseringer og engineering-kunngjøringer. Kun internt, fordi kunngjøringen er for de ansatte før den når pressen. Sensitivt med tanke på lekkasjer.
Compliance- og HR-orienteringer. Årlig etikkopplæring, regulatoriske oppdateringer, helse og sikkerhet. Sporbarhet betyr mer enn produksjonsglans.
Oppdateringer ved sikkerhetshendelser. Kun internt som standard, fordi innholdet er detaljer om hendelsen. Det må holde seg innenfor.
I hvert av disse bruksområdene er publikum interne ansatte på bedriftsnettet eller bedriftens VPN. Innholdet er internt etter retningslinjene. Å sende bytene til en SaaS, la SaaS-en levere dem tilbake til de ansatte, betale per minutt og be juridisk legge til enda en databehandleravtale, er veien med minst motstand, ikke den riktige arkitekturen.
Hvordan et on-prem-alternativ ser ut i 2025
Arkitekturen er liten nok til å tegnes på en Post-it.
Én Mac i møterommet. Foredragsholderens MacBook, et USB-kamera, byggets AV-system som mater lyd inn i Mac-en, eller en kombinasjon av disse. Apple silicon har en H.264-, HEVC- og AV1-encoder i maskinvaren som er identisk med den Final Cut Pro bruker ved eksport. Å kode 1080p i 5 Mbps, 720p i 3 Mbps og 540p i 1,8 Mbps samtidig, i sanntid, er nettopp det brikken er designet for.
Én webserver innenfor brannmuren. Hva som helst som
tar imot HTTPS PUT og leverer filer. En filserver brukt på nytt, en
liten Linux-VM, en eksisterende intern IIS eller nginx som allerede
leverer intranettinnhold. Endepunktet tar imot små fragmented
MP4-segmenter (seks sekunder hver) og bittesmå
.m3u8-spillelistefiler. Lagring er trivielt: en time med
sending på tre kvalitetsnivåer bruker rundt 4 GB. Serveren transkoder
ikke, den pakker ikke om, den lagrer og leverer.
En HLS-spiller innebygd i intranettsiden. Hvilken som helst moderne HLS-spiller fungerer: hls.js for nettlesere uten innebygd HLS, nettleserens innebygde støtte i Safari, Apple TV i kantinen, møteromsskjermene de fleste selskaper allerede bruker.
Det er hele arkitekturen. Bytene forlater aldri nettet. Det finnes ingen strømmeserver å lisensiere, ingen sky-transkoder å betale for, ingen eCDN-agent å installere på hver eneste laptop, ingen SaaS-abonnement. Mac-en kjører My Live TV Channel, som koder strømmen og laster den opp. Webserveren du allerede har, gjør resten.
Hvorfor dette skalerer på et bedrifts-LAN
Den første reaksjonen fra infrastrukturfolk er gjerne at én webserver ikke kan håndtere et town hall-publikum. På åpent internett stemmer den intuisjonen. På et bedrifts-LAN gjør den det ikke.
En 1080p HLS-variant i 5 Mbps over en 1 Gbps-uplink metter linken ved rundt 200 samtidige seere (1000 ÷ 5). Samme uplink i 10 Gbps bærer omtrent 2 000 samtidige 1080p-seere. 720p-varianten i 3 Mbps gir tallene 333 og 3 300. I en adaptiv bitrate-stige der seerne fordeler seg på flere trinn, vil de fleste bedriftslaptopper havne på 720p så snart HLS-adaptiv logikk finner det komfortable trinnet, og realistisk samtidskapasitet på én enkelt 10 Gbps-server er flere tusen ansatte.
Hvis publikum er større enn det, er ikke neste skritt en SaaS. Det er en server til internt, eller det interne CDN-et du allerede har (de fleste store bedrifter har allerede caching-infrastruktur for programvareoppdateringer og intranettinnhold), eller en enkelt nginx-cache-tier foran opplastingsserveren. Ingenting av dette krever en leverandør, og alt sammen er billigere enn SaaS-fakturering per seer.
Når publikum er for stort for unicast
Unicast-LAN-regnestykket over topper seg rundt noen tusen samtidige seere per server. Hvis en global all-hands lander 50 000 ansatte på samme byggs nett samme minutt, eller du strømmer til en arenastor sal full av selskapets laptoper, treffer unicast en vegg, og å stable på flere servere blir sløsing.
Det tradisjonelle svaret er multicast: én kopi av hvert segment går til en multicast-gruppe, hver seer abonnerer, og nettet duplikerer pakker i svitsjer og rutere etter behov. En enkelt strøm på 5 Mbps mater hele campus fra én kilde, uten båndbreddemultiplikasjon per seer.
I praksis er multicast på et bedriftsnett en «ja, men»-situasjon:
- Det fungerer bare inne i et multicast-aktivert nett. De fleste bedriftsnett har IGMP og PIM deaktivert som standard av sikkerhetshensyn. Å skru dem på er et nettverksingeniørprosjekt, ikke en innstilling.
- Det krysser ikke de fleste VPN-forbindelser. Eksterne ansatte faller tilbake til unicast.
- Det krysser ikke WAN-linker mellom kontorer uten eksplisitt MPLS-multicast eller tilsvarende.
- Det er hovedsakelig nyttig innenfor ett campus eller ett bygg der IT bevisst har bygget multicast-trærne.
Hvis nettet ditt støtter det, brukes det med denne arkitekturen ved å la encoder-Mac-en gjøre det den gjør (HLS via HTTPS PUT til den interne webserveren), og legge til en multicast-oversetter nedstrøms. Åpen kildekode-verktøy som tsduck og kommersielle bokser fra nettverksleverandører vil følge HLS-utgangen, bygge en MPEG-TS multicast-feed, og kunngjøre den via SAP eller SDP. Endepunkter som støtter multicast (VLC, set-top-bokser i møterom, smart-TV-er i kantinen) blir med i gruppen i stedet for å hente unicast-HLS. Endepunkter som ikke gjør det (de fleste laptoper i en nettleser) fortsetter med unicast-HLS-spilleren som leveres fra samme webserver. Én Mac, én opplastingsdestinasjon, pluss én multicast-oversetter dekker begge seertypene.
For de fleste selskaper er denne delen teoretisk: unicast håndterer all-hands-en uten besvær. For de få store bedriftene der det ikke er teoretisk, lar arkitekturen seg utvide uten å endre encoderen.
Sette det opp første gangen
Første kjøring tar en ettermiddag for et IT-team som ikke har drevet intern strømming før. Grov rekkefølge:
Velg destinasjons-webserveren. Hvilken som helst intern webserver med HTTPS fungerer. Konfigurer en katalog som
/intranet-broadcasts/town-hall-2025-q4/med HTTPS PUT aktivert, uten autentisering hvis den står bak brannmuren, eller basic auth hvis du foretrekker det. nginx meddav_modulegjør dette på rundt ti linjer config. Apache medmod_daver det tilsvarende.Test endepunktet. Fra hvilken som helst intern maskin skal
curl -X PUT https://intranet.corp/intranet-broadcasts/test/index.m3u8 --data "test"returnere en 201. Hvis den gjør det, er destinasjonen klar.Konfigurer My Live TV Channel på foredragsholderens Mac. Legg til en HTTP PUT-destinasjon som peker mot katalogen. Lagre. Test forbindelsen. Lag en Stream Profile med bitrate-stigen du ønsker.
Bygg inn en HLS-spiller på intranettsiden. En
<video controls>-tag som peker på avspillings-URL-en holder i Safari. For Chrome og Edge legger du inn hls.js (én script-tag, én linje JavaScript). Hele spilleren er færre enn tretti linjer HTML.Generalprøve med det tekniske teamet. Stream fra Mac-en i ti minutter. La noen interne seere koble seg på. Følg med på dashbordet. Bekreft at segmentene dukker opp på destinasjonsserveren, at spilleren plukker dem opp, og at latensen er akseptabel.
Det er hele oppsettet. Påfølgende sendinger gjenbruker samme destinasjon, samme profil og samme spillerintegrasjon.
Hva med Q&A, avstemninger og resten
Arkitekturen over håndterer kringkastingen, ikke det interaktive laget. Til Q&A, avstemninger og reaksjoner under town hall-en har interne selskaper som regel allerede en kanal i Slack eller Microsoft Teams som fungerer utmerket, kjører med subsekund-latens over samme interne nett, og integrerer seg med katalogen resten av selskapet bruker. Forsøket på å gjøre en strømme-SaaS til chat-verktøy også er det som gjør de produktene dyre. Å splitte kringkasting og interaksjon inn i verktøyene selskapet allerede kjører, er det som gjør arkitekturen billig.
Hvis du ønsker en intern informasjonskanal som går 24/7 («CorpTV»), fyller My TV Channel playout-appen tiden mellom direktesendinger med planlagt innhold (arkiverte all-hands-opptak, opplæringsvideoer, internnyheter, oppdateringer fra ledelsen). Samme destinasjonsserver, samme spillerintegrasjon. Ansatte som lander på kanalsiden en tirsdag ettermiddag, finner noe som spiller, ikke en «stream offline»-skjerm.
Hva som fortsatt er ditt problem
Selvhosting av intern video har avveininger det er verdt å være ærlig om.
Opptak og lagringstid. Destinasjonsserveren beholder hver sending på ubestemt tid med mindre du setter opp en oppryddingsjobb. Det er bra for arkivene og dårlig for lagringen hvis du glemmer det. De fleste selskaper ønsker en oppbevaringspolicy for interne sendinger (typisk justert mot regulatoriske eller juridiske krav). Sett det opp én gang i cron, og glem det.
Teksting og tilgjengelighet. Live-teksting er ikke bygget inn i encoder-appen, og det viser seg å være et mindre problem enn det høres ut som. Moderne nettlesere og operativsystemer genererer live-teksting på klientsiden, på enheten, helt uten serverinvolvering: Chromes Live Caption-funksjon fungerer på all video som spilles av i nettleseren, macOS Live Captions gjør det samme systemvidt i Safari, og Edge har sin egen variant. Hver seer slår teksting på eller av i sin egen nettleser. Hvis du av compliance-grunner trenger serverside-teksting (tekstene må være en del av opptaket, eller du kan ikke stole på seerens nettleser), ruter du lyden gjennom en tekstetjeneste (Microsofts innebygde teksting, AWS Transcribe, interne verktøy) og legger tekstene oppå i spilleren. HLS-laget endrer seg ikke i noen av tilfellene.
Autentisering. Innenfor brannmuren er ofte «alle på bedriftsnettet kan se» akseptabelt. Hvis du trenger sterkere garantier (lederbriefinger, M&A-kunngjøringer), legger du avspillings-URL-en bak eksisterende SSO eller VPN-postursjekker. Standard webautentisering, ikke noe video-spesifikt.
Kontorer på tvers av regioner. Hvis du har kontorer på flere kontinenter som blir med på én sending, vil du enten ha en regional cache-server i hver region, eller ta et bevisst valg om å bruke bedriftens WAN. WAN-er er typisk båndbreddebegrenset, så LAN-regnestykket over gjelder ikke. Planlegg deretter.
Den ærlige dommen
Kostnadsspørsmålet er det enkleste å overdrive. SaaS-regninger for intern strømming finnes, men de er sjelden den avgjørende faktoren alene. Det avgjørende for de fleste selskaper som flytter til en on-prem-arkitektur, er at intern video bør forbli intern. Konsernsjefens stemme, engineering-kunngjøringen, M&A-briefen, debriefingen etter en sikkerhetshendelse, compliance-opplæringen: ingen av dem trenger å forlate bedriftsnettet for å nå det bedriftspublikummet som sitter på det. Når det blir rammen, er det «vi sender en kopi gjennom en leverandørs datasenter og betaler for tur-retur» som trenger begrunnelse, ikke on-prem-alternativet.
Compliance-team stiller det samme spørsmålet i regulerte bransjer: hvilke tredjeparter har tilgang til opptak av interne ansattmøter? Sikkerhetsteam stiller det etter hvert sikkerhetsbrudd som nevner en strømmeleverandør. Reglene for dataresidens i enkelte regioner stiller det før sendingen i det hele tatt finner sted. En arkitektur der bytene aldri forlater nettet, fjerner spørsmålet.
Hvis du har de bekymringene og IT-teamet ditt er lei av å rulle ut enda en leverandørs eCDN-agent på hver laptop, er det praktiske svaret nå lite nok til å settes opp på en ettermiddag. En Mac i møterommet, en webserver du allerede har, og en app du kan prøve gratis i en uke. Arkitekturskissen får plass på en Post-it. Antall leverandører med tilgang til konsernsjefens stemme går fra «flere» til «null».