Quando 4.000 dipendenti si collegano allo stesso all-hands nello stesso momento, qualcuno sta pagando qualcun altro per quei byte. Di solito quel qualcuno è un abbonamento a Microsoft Stream, Zoom Webinar, Vimeo Enterprise o Brightcove: i byte escono brevemente dalla rete aziendale, rimbalzano su un datacenter di terze parti e rientrano nella stessa rete su una connessione diversa. Il CEO è in una sala riunioni due porte più in là e il suo video va a Francoforte e ritorna.
Funziona bene finché qualcuno non pone la domanda che non ha una buona risposta. “Perché il traffico del nostro town hall interno transita per un SaaS di terze parti?” La compliance la pone prima di un audit in un settore regolamentato. La security la pone dopo ogni breach disclosure che cita un fornitore di streaming. Il CFO la pone quando si rinnova la fattura SaaS calcolata per spettatore. L’IT la pone la prima volta che il link WAN dell’edificio satura perché l’all-hands ha registrato un’affluenza record.
La risposta onesta è che il live streaming aziendale si è sviluppato attorno a encoder RTMP e piattaforme SaaS perché le alternative erano costose (Cisco enterprise video, appliance eCDN di Kollective e Hive, hardware CDN interno) oppure artigianali in un modo che nessuno in un team IT tipico aveva il tempo di mantenere. Le aziende hanno scelto il SaaS perché niente altro era a portata di mano.
Le cose sono cambiate. L’encoder, il transcoder, il packager e il publisher si sono compattati in un singolo software che gira su un Mac. La destinazione non deve essere un fornitore. Puntato su un web server dentro il tuo firewall, lo stesso software produce HLS conforme agli standard broadcast che i tuoi dipendenti guardano sulla LAN aziendale, e niente esce dalla rete.
Questo articolo parla esattamente di come fare tutto ciò.
Com’è davvero il “live aziendale interno”
Quasi tutti i video interni in un’azienda tipica rientrano in una piccola lista di casi d’uso ricorrenti.
All-hands trimestrali e town hall del CEO. Audience numerose (spesso l’intera azienda), bassa frequenza (da quattro a dodici volte l’anno), valori produttivi modesti. Le tolleranze sulla latenza sono morbide: dai quindici ai trenta secondi vanno bene perché non c’è interazione bidirezionale durante il keynote e le Q&A sono gestite su un canale separato.
Sessioni di formazione e corsi di certificazione. A volte in diretta, spesso riguardati. Massimo qualche centinaio di spettatori in concorrenza. La produzione è una telecamera, un relatore, slide condivise da un laptop.
Lanci di prodotto e annunci di engineering. Solo interni perché l’annuncio è destinato allo staff prima di arrivare alla stampa. Sensibili alle fughe di notizie.
Briefing di compliance e HR. Formazione annuale sull’etica, aggiornamenti normativi, salute e sicurezza. L’audit trail conta più della rifinitura produttiva.
Aggiornamenti su incidenti di sicurezza. Solo interni per definizione, perché il contenuto sono i dettagli dell’incidente. Devono restare dentro.
In ognuno di questi casi d’uso, il pubblico è composto da dipendenti interni sulla rete aziendale o sulla VPN aziendale. Il contenuto è interno per policy. Mandare i byte a un SaaS, far sì che il SaaS li serva di nuovo ai tuoi dipendenti, pagare al minuto e chiedere all’ufficio legale di aggiungere un altro accordo di trattamento dati è la via di minor resistenza, non l’architettura corretta.
Com’è un’alternativa on-prem nel 2025
L’architettura è abbastanza piccola da poter essere disegnata su un post-it.
Un Mac nella sala riunioni. Il MacBook del relatore, una telecamera USB, l’impianto AV dell’edificio che porta l’audio nel Mac, oppure una qualsiasi combinazione di queste. Apple silicon ha un encoder hardware H.264, HEVC e AV1 identico a quello che Final Cut Pro usa per l’export. Codificare 1080p a 5 Mbps, 720p a 3 Mbps e 540p a 1,8 Mbps simultaneamente, in tempo reale, è esattamente ciò per cui il chip è progettato.
Un web server dentro il firewall. Qualsiasi cosa
accetti HTTPS PUT e serva file. Un file server riutilizzato, una piccola
VM Linux, un IIS o nginx interno già esistente che serve già contenuti
intranet. L’endpoint riceve piccoli segmenti fragmented MP4 (sei secondi
ciascuno) e minuscoli file di playlist .m3u8. Lo storage è
banale: una trasmissione di un’ora con tre livelli di qualità usa circa
4 GB. Il server non transcodifica, non ripacchettizza, semplicemente
memorizza e serve.
Un player HLS embeddato nella pagina intranet. Va bene qualsiasi player HLS moderno: hls.js per i browser senza supporto nativo HLS, il supporto integrato del browser su Safari, l’Apple TV in mensa, i sistemi display delle sale riunioni che la maggior parte delle aziende già usa.
Questa è l’intera architettura. I byte non lasciano mai la rete. Non c’è nessun streaming server da licenziare, nessun transcoder cloud da pagare, nessun agent eCDN da installare su ogni laptop dei dipendenti, nessun abbonamento SaaS. Il Mac fa girare My Live TV Channel, che codifica lo stream e lo carica. Il web server che hai già fa il resto.
Perché funziona su scala su una LAN aziendale
La prima reazione di chi gestisce l’infrastruttura è di solito che un singolo web server non possa reggere un pubblico da town hall. Sull’internet pubblico, quell’intuizione è corretta. Su una LAN aziendale, no.
Una variante HLS 1080p a 5 Mbps su un uplink da 1 Gbps satura il link a circa 200 spettatori in concorrenza (1000 ÷ 5). Lo stesso uplink a 10 Gbps trasporta circa 2.000 spettatori 1080p in concorrenza. La variante 720p a 3 Mbps porta quei numeri rispettivamente a circa 333 e 3.300. In una scaletta a bitrate adattivo dove gli spettatori si distribuiscono su più livelli, la maggior parte dei laptop aziendali atterrerà su 720p una volta che la logica adattiva HLS trova il livello comodo, quindi la capacità realistica in concorrenza su un singolo server da 10 Gbps è di diverse migliaia di dipendenti.
Se il tuo pubblico è più grande di così, il passo successivo non è un SaaS. È un secondo server interno, oppure il tuo CDN interno esistente (la maggior parte delle grandi aziende ha già infrastruttura di caching per gli aggiornamenti software e i contenuti intranet), oppure un singolo livello di caching nginx davanti al server di upload. Niente di tutto questo richiede un fornitore, e tutto è più economico della fatturazione SaaS per spettatore.
Quando il pubblico è troppo grande per l’unicast
I conti unicast sulla LAN qui sopra si fermano attorno a qualche migliaio di spettatori in concorrenza per server. Se un all-hands globale fa atterrare 50.000 dipendenti sulla rete dello stesso edificio nello stesso minuto, oppure stai trasmettendo a una venue di dimensioni stadionali piena di laptop aziendali, l’unicast sbatte contro un muro e accatastare più server diventa uno spreco.
La risposta tradizionale è il multicast: una singola copia di ogni segmento viaggia verso un gruppo multicast, ogni spettatore si iscrive, la rete duplica i pacchetti su switch e router quando serve. Un singolo stream da 5 Mbps alimenta l’intero campus da una sola sorgente, senza moltiplicazione di banda per spettatore.
Nella pratica, il multicast su una rete aziendale è una situazione “sì, ma”:
- Funziona solo dentro una rete con multicast abilitato. La maggior parte delle reti aziendali ha IGMP e PIM disabilitati per default per ragioni di sicurezza. Attivarli è un progetto di network engineering, non una semplice impostazione.
- Non attraversa la maggior parte delle connessioni VPN. I lavoratori da remoto ricadono sull’unicast.
- Non attraversa i link WAN tra uffici senza MPLS multicast esplicito o equivalenti.
- È perlopiù utile dentro un singolo campus o un singolo edificio dove l’IT ha costruito gli alberi multicast con cura.
Se la tua rete lo supporta, il modo per usarlo con questa architettura è lasciare che il Mac encoder faccia ciò che fa (HLS via HTTPS PUT verso il web server interno) e aggiungere un traduttore multicast a valle. Strumenti open source come tsduck e appliance commerciali dei vendor di rete leggono in coda l’output HLS, costruiscono un feed multicast MPEG-TS e lo annunciano via SAP o SDP. Gli endpoint che supportano il multicast (VLC, set-top box nelle sale riunioni, smart TV in mensa) si uniscono al gruppo invece di tirare HLS unicast. Gli endpoint che non lo supportano (la maggior parte dei laptop in un browser) continuano a usare il player HLS unicast servito dallo stesso web server. Un Mac, una destinazione di upload e un singolo traduttore multicast coprono entrambi i tipi di spettatore.
Per la maggior parte delle aziende questa sezione è teorica: l’unicast gestisce l’all-hands senza difficoltà. Per le poche grandi aziende per cui non lo è, l’architettura si estende senza cambiare l’encoder.
Configurarlo la prima volta
La prima esecuzione richiede circa un pomeriggio a un team IT che non ha mai fatto streaming interno prima. L’ordine grossolano:
Scegli il web server di destinazione. Va bene qualsiasi web server interno con HTTPS. Configura una directory tipo
/intranet-broadcasts/town-hall-2025-q4/con HTTPS PUT abilitato, senza autenticazione se è dietro al firewall, oppure con basic auth se preferisci. nginx con ildav_modulelo fa in circa dieci righe di config.mod_davdi Apache è l’equivalente.Testa l’endpoint. Da qualsiasi macchina interna,
curl -X PUT https://intranet.corp/intranet-broadcasts/test/index.m3u8 --data "test"dovrebbe restituire un 201. Se lo fa, la destinazione è pronta.Configura My Live TV Channel sul Mac del relatore. Aggiungi una destinazione HTTP PUT che punti alla directory. Salvala. Testa la connessione. Crea uno Stream Profile con la scaletta di bitrate che vuoi.
Embedda un player HLS nella pagina intranet. Un tag
<video controls>che punta all’URL di playback è sufficiente su Safari. Per Chrome ed Edge, aggiungi hls.js (un tag script, una riga di JavaScript). Tutto il player è meno di trenta righe di HTML.Fai una prova generale con il team tecnico. Trasmetti dal Mac per dieci minuti. Fai sintonizzare alcuni spettatori interni. Guarda la dashboard. Verifica che i segmenti appaiano sul server di destinazione, che il player li stia raccogliendo e che la latenza sia accettabile.
Questo è tutto il setup. Le trasmissioni successive riusano la stessa destinazione, lo stesso profilo e lo stesso embed del player.
E le Q&A, i sondaggi e tutto il resto
L’architettura qui sopra gestisce la trasmissione, non il livello interattivo. Per Q&A, sondaggi e reazioni durante il town hall, le aziende interne tipicamente hanno già un canale Slack o Microsoft Teams che funziona perfettamente, gira a latenza sub-secondo sulla stessa rete interna e si integra con la directory che usa il resto dell’azienda. Cercare di trasformare uno streaming SaaS anche nello strumento di chat è ciò che rende quei prodotti costosi. Separare la trasmissione e l’interazione negli strumenti che la tua azienda già usa è ciò che rende l’architettura economica.
Se vuoi un canale informativo interno 24/7 (“CorpTV”), l’app di playout My TV Channel riempie il tempo tra le trasmissioni live con contenuti programmati (archivi di all-hands registrati, video di formazione, news interne, aggiornamenti dei manager). Stesso server di destinazione, stesso embed del player. I dipendenti che approdano sulla pagina del canale un martedì pomeriggio trovano qualcosa in onda invece di una schermata “stream offline”.
Cosa resta un tuo problema
Il self-hosting del video interno ha dei trade-off su cui vale la pena essere onesti.
Registrazione e retention. Il server di destinazione conserva ogni trasmissione a tempo indeterminato, a meno che tu non imposti un job di pulizia. Va bene per gli archivi e male per lo storage se te ne dimentichi. La maggior parte delle aziende vuole una policy di retention sulle trasmissioni interne (di solito allineata ai requisiti normativi o legali). Configurala una volta, in cron, e dimenticatene.
Sottotitoli e accessibilità. Il sottotitolaggio in tempo reale non è integrato nell’app encoder, e si rivela un problema meno serio di quanto sembri. Browser e sistemi operativi moderni generano sottotitoli live lato client, on-device, senza coinvolgimento del server: la funzione Live Caption di Chrome funziona su qualsiasi video in riproduzione nel browser, macOS Live Captions fa lo stesso a livello di sistema in Safari, Edge ha il suo equivalente. Ogni spettatore attiva o disattiva i sottotitoli nel proprio browser. Se hai bisogno di sottotitolaggio lato server per ragioni di compliance (i sottotitoli devono far parte della registrazione, oppure non puoi affidarti al browser dello spettatore), instrada l’audio attraverso un servizio di sottotitolaggio (i sottotitoli integrati di Microsoft, AWS Transcribe, strumenti interni) e sovrapponi i sottotitoli nel player. Il livello HLS non cambia in nessuno dei due casi.
Autenticazione. Dentro il firewall, “chiunque sulla rete aziendale può guardare” è spesso accettabile. Se ti servono garanzie più forti (briefing dirigenziali, annunci di M&A), metti l’URL di playback dietro al tuo SSO esistente o a controlli di posture VPN. Auth web standard, niente di specifico per il video.
Uffici cross-region. Se hai uffici su più continenti che si uniscono a una singola trasmissione, vorrai o un server di cache regionale in ogni regione, oppure una decisione consapevole di usare la WAN aziendale. Le WAN sono tipicamente rate-limited, quindi i conti sulla LAN qui sopra non si applicano. Pianifica di conseguenza.
Il verdetto onesto
La questione del costo è quella più facile da sopravvalutare. Le fatture SaaS per lo streaming interno esistono, ma raramente sono il fattore decisivo da sole. Il fattore decisivo per la maggior parte delle aziende che passano a un’architettura on-prem è che il video interno dovrebbe restare interno. La voce del CEO, l’annuncio di engineering, il briefing di M&A, il debrief sull’incidente di sicurezza, la formazione di compliance: nessuno di questi ha bisogno di lasciare la rete aziendale per essere consegnato al pubblico aziendale che è seduto su quella stessa rete. Una volta inquadrata così la cosa, è “mandiamo una copia attraverso il datacenter di un fornitore e paghiamo per il viaggio andata e ritorno” la parte che ha bisogno di essere giustificata, non l’alternativa on-prem.
I team di compliance pongono la stessa domanda nei settori regolamentati: quali terze parti hanno accesso alle registrazioni delle riunioni interne dei dipendenti? I team di security la pongono dopo ogni breach disclosure che cita un fornitore di streaming. Le regole di data residency in alcune regioni la pongono prima che la trasmissione abbia luogo. Un’architettura in cui i byte non lasciano mai la rete elimina la domanda.
Se hai queste preoccupazioni e il tuo team IT è stanco di provisionare l’ennesimo agent eCDN di un fornitore su ogni laptop, la risposta pratica è ora abbastanza piccola da essere configurata in un pomeriggio. Un Mac in sala riunioni, un web server che hai già e un’app che puoi provare gratis per una settimana. Il diagramma dell’architettura sta su un post-it. Il numero di fornitori con accesso alla voce del tuo CEO passa da “diversi” a “zero”.
Prova My Live TV Channel gratis per 7 giorni sul Mac App Store →