Direktsänd ert företagsallmöte on-prem, utan att skicka det till en SaaS

När 4 000 anställda ansluter till samma all-hands samtidigt är det någon som betalar någon för dessa byte. Vanligtvis är denna någon en prenumeration på Microsoft Stream, Zoom Webinar, Vimeo Enterprise eller Brightcove. Byten lämnar kortvarigt företagsnätverket, studsar mot ett tredjepartsdatacenter och kommer tillbaka in i samma nätverk via en annan anslutning. VD:n sitter i ett mötesrum två dörrar bort, och videon av honom åker till Frankfurt och tillbaka.

Det här fungerar bra tills någon ställer frågan som inte har ett bra svar. “Varför går trafiken från vårt interna town hall via en tredjeparts-SaaS?” Compliance ställer den inför en revision i en reglerad bransch. Säkerhetsavdelningen ställer den efter varje incidentrapport som nämner en streamingleverantör. CFO ställer den när SaaS-fakturan per tittare ska förnyas. IT ställer den första gången byggnadens WAN-länk mättas eftersom all-hands slog publikrekord.

Det ärliga svaret är att företagslivesändning utvecklats kring RTMP-encoders och SaaS-plattformar eftersom alternativen antingen var dyra (Cisco enterprise video, eCDN-appliances från Kollective och Hive, intern CDN-utrustning) eller hemmabyggda på ett sätt som ingen i ett typiskt IT-team hade kapacitet att underhålla. Företag valde SaaS eftersom inget annat var inom räckhåll.

Det har förändrats. Encodern, transkodaren, paketeraren och publiceraren har slagits samman till en enda mjukvara som körs på en Mac. Destinationen behöver inte vara en leverantör. Riktad mot en webbserver innanför din brandvägg producerar samma mjukvara HLS av broadcaststandard som dina anställda strömmar över företagets LAN, och inget lämnar nätverket.

Den här artikeln handlar om att göra precis det.

Hur “intern företagslive” faktiskt ser ut

Det mesta interna videoinnehållet på ett typiskt företag faller in i en kort lista av återkommande användningsfall.

Kvartalsvisa all-hands och VD-town halls. Stora publiker (ofta hela företaget), låg frekvens (fyra till tolv gånger per år), måttliga produktionsvärden. Latenstoleransen är generös, femton till trettio sekunder är okej eftersom det inte finns någon tvåvägsinteraktion under keynoten och Q&A hanteras i en separat kanal.

Utbildningssessioner och certifieringskurser. Ibland live, ofta omtittade. Som mest några hundra samtidiga tittare. Produktionen består av en kamera, en presentatör, slides delade från en laptop.

Produktlanseringar och tekniska tillkännagivanden. Endast internt eftersom tillkännagivandet är för personalen innan det når pressen. Känsligt för läckor.

Compliance- och HR-genomgångar. Årlig etikutbildning, regulatoriska uppdateringar, hälsa och säkerhet. Spårbarhet är viktigare än produktionspolering.

Säkerhetsincidentuppdateringar. Endast internt som standard eftersom innehållet är incidentdetaljer. Måste stanna på insidan.

I vart och ett av dessa användningsfall är publiken interna anställda på företagsnätverket eller på företagets VPN. Innehållet är internt enligt policy. Att skicka byten till en SaaS, låta SaaS:en servera dem tillbaka till dina anställda, betala per minut och be juristerna lägga till ännu ett databehandlingsavtal är minsta motståndets väg, inte rätt arkitektur.

Hur ett on-prem-alternativ ser ut 2025

Arkitekturen är liten nog att ritas på en post-it-lapp.

En Mac i mötesrummet. Talarens MacBook, en USB-kamera, byggnadens AV-system som matar in ljud i Macen, eller någon kombination av detta. Apple silicon har en hårdvaruencoder för H.264, HEVC och AV1 som är identisk med den Final Cut Pro använder vid export. Att encoda 1080p i 5 Mbps, 720p i 3 Mbps och 540p i 1,8 Mbps samtidigt, i realtid, är precis vad chippet är designat för.

En webbserver innanför brandväggen. Vad som helst som accepterar HTTPS PUT och serverar filer. En återanvänd filserver, en liten Linux-VM, en befintlig intern IIS eller nginx som redan serverar intranätinnehåll. Endpointen tar emot små fragmenterade MP4-segment (sex sekunder vardera) och små .m3u8-spellistefiler. Lagringen är försumbar: en timmes sändning i tre kvalitetsnivåer använder ungefär 4 GB. Servern transkodar inte, paketerar inte om, den bara lagrar och serverar.

En HLS-spelare inbäddad i intranätssidan. Vilken modern HLS-spelare som helst fungerar: hls.js för webbläsare utan inbyggd HLS, webbläsarens inbyggda stöd i Safari, Apple TV i kafeterian, mötesrummens skärmsystem som de flesta företag redan har.

Det är hela arkitekturen. Byten lämnar aldrig nätverket. Det finns ingen streamingserver att licensiera, ingen molntranskodare att fakturera, ingen eCDN-agent att installera på varje anställdas laptop, ingen SaaS-prenumeration. Macen kör My Live TV Channel, som encodar strömmen och laddar upp den. Webbservern du redan har sköter resten.

Varför det skalar på ett företags-LAN

Den första reaktionen från infrastrukturfolk är oftast att en webbserver inte klarar av en town hall-publik. På det publika internet är den intuitionen rätt. På ett företags-LAN är den det inte.

En 1080p HLS-variant i 5 Mbps över en 1 Gbps-uplink mättar länken vid omkring 200 samtidiga tittare (1000 ÷ 5). Samma uplink i 10 Gbps bär ungefär 2 000 samtidiga 1080p-tittare. 720p-varianten i 3 Mbps tar siffrorna till cirka 333 respektive 3 300. I en adaptiv bitrate-stege där tittarna sprids över flera nivåer landar de flesta företagslaptops på 720p så snart HLS adaptiva logik hittar den bekväma nivån, så realistisk samtidig kapacitet på en enskild 10 Gbps-server är flera tusen anställda.

Om din publik är större än så är nästa steg inte en SaaS. Det är en andra intern server, eller ditt befintliga interna CDN (de flesta större företag har redan cachinginfrastruktur för mjukvaruuppdateringar och intranätinnehåll), eller ett enskilt nginx-cachinglager framför uppladdningsservern. Inget av detta kräver en leverantör, och allt är billigare än SaaS-fakturering per tittare.

När publiken är för stor för unicast

Unicast-LAN-matematiken ovan tar slut runt några tusen samtidiga tittare per server. Om en global all-hands får 50 000 anställda på samma byggnads nätverk vid samma minut, eller om du strömmar till en arena fylld av företagslaptops, slår unicast i taket och att stapla fler servrar blir slöseri.

Det traditionella svaret är multicast: en kopia av varje segment färdas till en multicastgrupp, varje tittare prenumererar, nätverket duplicerar paket vid switchar och routrar efter behov. En enskild 5 Mbps-ström matar hela campus från en källa, utan bandbreddsmultiplikation per tittare.

I praktiken är multicast på ett företagsnätverk ett “ja, men”-läge:

• Det fungerar bara inuti ett multicast-aktiverat nätverk. De flesta företagsnätverk har IGMP och PIM avstängda som standard av säkerhetsskäl. Att slå på dem är ett nätverksingenjörsprojekt, inte en inställning.
• Det går inte över de flesta VPN-anslutningar. Distansarbetare faller tillbaka på unicast.
• Det går inte över WAN-länkar mellan kontor utan explicit MPLS-multicast eller liknande.
• Det är mest användbart inuti ett campus eller en byggnad där IT byggt multicast-träden medvetet.

Om ditt nätverk stödjer det är sättet att använda det med den här arkitekturen att låta encoder-Macen göra det den gör (HLS över HTTPS PUT till den interna webbservern) och lägga till en multicast-translator nedströms. Open source-verktyg som tsduck och kommersiella appliances från nätverksleverantörer kan följa HLS-utdata, bygga ett MPEG-TS multicast-flöde och annonsera det via SAP eller SDP. Endpoints som stödjer multicast (VLC, set-top-boxar i mötesrum, smarta TV-apparater i kafeterian) ansluter till gruppen istället för att hämta unicast-HLS. Endpoints som inte gör det (de flesta laptops i en webbläsare) fortsätter använda unicast-HLS-spelaren som serveras från samma webbserver. En Mac, en uppladdningsdestination, plus en enskild multicast-translator täcker båda tittartyperna.

För de flesta företag är detta avsnitt teoretiskt: unicast hanterar all-hands utan svårighet. För de få stora företag där det inte är teoretiskt utökas arkitekturen utan att encodern ändras.

Att sätta upp det första gången

Första körningen tar ungefär en eftermiddag för ett IT-team som inte gjort intern streaming tidigare. Den ungefärliga ordningen:

1. Välj destinationswebbservern. Vilken intern webbserver med HTTPS som helst fungerar. Konfigurera en katalog som /intranet-broadcasts/town-hall-2025-q4/ med HTTPS PUT aktiverat, ingen autentisering om den ligger bakom brandväggen, eller basic auth om du föredrar. nginx med dav_module gör detta i ungefär tio rader konfiguration. Apaches mod_dav är motsvarigheten.

2. Testa endpointen. Från valfri intern maskin ska curl -X PUT https://intranet.corp/intranet-broadcasts/test/index.m3u8 --data "test" returnera en 201. Om den gör det är destinationen redo.

3. Konfigurera My Live TV Channel på presentatörens Mac. Lägg till en HTTP PUT-destination som pekar mot katalogen. Spara den. Testa anslutningen. Skapa en Stream Profile med den bitrate-stege du vill ha.

4. Bädda in en HLS-spelare på intranätssidan. En <video controls>-tagg som pekar mot uppspelnings-URL:en räcker i Safari. För Chrome och Edge, släng in hls.js (en script-tagg, en rad JavaScript). Hela spelaren är färre än trettio rader HTML.

5. Provkör med tekniska teamet. Strömma från Macen i tio minuter. Låt några interna tittare ansluta. Håll koll på dashboarden. Bekräfta att segmenten dyker upp på destinationsservern, att spelaren plockar upp dem och att latensen är acceptabel.

Det är hela uppsättningen. Efterföljande sändningar återanvänder samma destination, samma profil och samma spelarinbäddning.

Hur är det med Q&A, omröstningar och resten

Arkitekturen ovan hanterar sändningen, inte det interaktiva lagret. För Q&A, omröstningar och reaktioner under town hall har interna företag oftast redan en Slack- eller Microsoft Teams-kanal som fungerar utmärkt, körs med subsekunders latens över samma interna nätverk och integrerar med den katalog som resten av företaget använder. Att försöka göra en streaming-SaaS till chattverktyg också är det som gör de produkterna dyra. Att dela upp sändningen och interaktionen i de verktyg ditt företag redan kör är det som gör arkitekturen billig.

Om du vill ha en intern informationskanal dygnet runt (“CorpTV”) fyller playout-appen My TV Channel tiden mellan livesändningar med schemalagt innehåll (arkiverade all-hands-inspelningar, utbildningsvideor, interna nyheter, chefsuppdateringar). Samma destinationsserver, samma spelarinbäddning. Anställda som hamnar på kanalsidan en tisdagseftermiddag hittar något som spelas istället för en “stream offline”-skärm.

Det som förblir ditt problem

Att självhosta intern video har avvägningar som är värda att vara ärlig om.

Inspelning och lagring. Destinationsservern behåller varje sändning på obestämd tid om du inte sätter upp ett städjobb. Det är bra för arkiv och dåligt för lagring om du glömmer det. De flesta företag vill ha en lagringspolicy för interna sändningar (typiskt anpassad till regulatoriska eller juridiska krav). Sätt upp den en gång, i cron, och glöm den.

Undertexter och tillgänglighet. Live-textning är inte inbyggt i encoder-appen, och det visar sig vara mindre av ett problem än det låter. Moderna webbläsare och operativsystem genererar live-undertexter på klientsidan, på enheten, utan serverinblandning: Chromes Live Caption-funktion fungerar på vilken video som helst som spelas i webbläsaren, macOS Live Captions gör samma sak systemövergripande i Safari, Edge har sin egen motsvarighet. Varje tittare slår på eller av undertexter i sin egen webbläsare. Om du behöver textning på serversidan av compliance-skäl (undertexterna måste vara en del av inspelningen, eller du kan inte förlita dig på tittarens webbläsare), dirigera ljudet genom en textningstjänst (Microsofts inbyggda undertexter, AWS Transcribe, interna verktyg) och lägg över undertexterna i spelaren. HLS-lagret ändras inte i något fall.

Autentisering. Innanför brandväggen är “alla på företagsnätverket får titta” ofta acceptabelt. Om du behöver starkare garantier (ledningsbriefingar, M&A-tillkännagivanden), lägg uppspelnings-URL:en bakom din befintliga SSO eller VPN-postureverifiering. Standardwebbautentisering, inget videospecifikt.

Kontor i flera regioner. Om du har kontor på flera kontinenter som ansluter till en enskild sändning vill du antingen ha en regional cacheserver i varje region, eller ett medvetet beslut att använda företagets WAN. WAN är typiskt ratebegränsade, så LAN-matematiken ovan gäller inte. Planera därefter.

Den ärliga slutsatsen

Kostnadsfrågan är den lättaste att överdriva. SaaS-fakturor för intern streaming finns, men de är sällan den avgörande faktorn på egen hand. Den avgörande faktorn för de flesta företag som flyttar till en on-prem-arkitektur är att intern video ska förbli intern. VD:ns röst, det tekniska tillkännagivandet, M&A-briefingen, säkerhetsincidentdebriefen, compliance-utbildningen: ingen av dem behöver lämna företagsnätverket för att levereras till företagspubliken som sitter på det. När det är ramen är “vi skickar en kopia genom en leverantörs datacenter och betalar för returresan” den del som behöver motiveras, inte on-prem-alternativet.

Compliance-team ställer samma fråga i reglerade branscher: vilka tredje parter har tillgång till inspelningar av interna personalmöten? Säkerhetsteam ställer den efter varje incidentrapport som nämner en streamingleverantör. Regler för dataresidens i vissa regioner ställer den innan sändningen ens äger rum. En arkitektur där byten aldrig lämnar nätverket tar bort frågan.

Om du har de bekymren och ditt IT-team är trött på att rulla ut ännu en leverantörs eCDN-agent på varje laptop, är det praktiska svaret nu litet nog att sätta upp på en eftermiddag. En Mac i mötesrummet, en webbserver du redan har, och en app du kan prova gratis i en vecka. Arkitekturdiagrammet får plats på en post-it. Antalet leverantörer med tillgång till din VD:s röst går från “flera” till “noll”.

Prova My Live TV Channel gratis i 7 dagar på Mac App Store →