Una diretta può essere un evento singolo (una messa domenicale, il lancio di un prodotto, il keynote di una conferenza, un matrimonio, un webinar, una tavola rotonda a un piccolo festival), una trasmissione occasionale (uno show settimanale, una Q&A mensile) oppure un canale continuo 24/7. L’impalcatura che l’industria dello streaming ha costruito negli ultimi quindici anni dà per scontato che tutti e tre i casi richiedano lo stesso stack pesante: una camera, un encoder, un push RTMP verso uno streaming server, un transcoder in cloud, un packager, una CDN e un player. Cinque pezzi mobili, quattro fatture, tre punti dove l’autenticazione può fallire e un diagramma di architettura che nessuno nel tuo team riesce a disegnare a memoria.
Per un pubblico piccolo o medio, di tutto questo non hai bisogno. Né dello streaming server, né del transcoder in cloud, né del packager, né della CDN. Che tu stia trasmettendo per due ore la domenica mattina o gestendo un canale che non dorme mai, la stessa semplice architettura va bene per entrambi.
Il segreto sporco è che su un Mac moderno quattro di quei cinque blocchi esistono già dentro al portatile sulla tua scrivania. L’encoder H.264 che Final Cut Pro usa per l’export è lo stesso encoder hardware che si trova in ogni chip Apple silicon. Gli encoder HEVC e AV1 sono lì accanto. Impacchettare fragmented MP4 in segmenti HLS sono qualche centinaio di righe di codice. Caricare quei segmenti su un web server è HTTPS PUT, che ogni server già parla. Lo streaming server al centro non è una legge della fisica, è solo una cosa che l’industria si è abituata ad affittare.
My Live TV Channel è un’app per macOS che fa l’intera catena in un solo software. Cattura, codifica, packaging, pubblicazione. L’output è HLS broadcast-standard, lo stesso formato che Netflix, Apple, Disney+ e la BBC distribuiscono ai loro spettatori. La destinazione è qualunque endpoint HTTPS gli punti contro: il tuo sito su un hosting condiviso a poco prezzo (senza CDN davanti), un bucket S3, Cloudflare R2, Bunny Storage o Akamai MSL4 se per caso gestisci eventi live alla scala di un Super Bowl. All’app non importa: scrive segmenti, internet li raccoglie.
Questo articolo racconta cosa cambia quando si comprime la catena di streaming in un’unica app, quanto costa e dove sono i limiti.
Cosa ti serve davvero per andare in diretta
Tre cose, in quest’ordine.
Un Mac con un ingresso video. Va bene qualunque Mac Apple silicon (da M1 in poi). La camera FaceTime integrata basta per gli stream parlato. Una camera USB la attacchi e compare come sorgente. Il tuo iPhone compare come Continuity Camera, ed è davvero ottimo come B-camera per gli eventi perché Apple gestisce per te il wireless e l’autofocus. Scegli come ingresso una camera integrata, USB o Continuity Camera. Un’anteprima fluttuante picture-in-picture mantiene la camera visibile mentre lavori in un’altra finestra.
Un posto dove mettere i segmenti HLS. Questo è l’unico pezzo che conta davvero ed è anche l’unico su cui le persone pensano troppo. L’app carica file piccoli (segmenti .m4s, sei secondi ciascuno di default, più minuscoli file di playlist .m3u8) tramite HTTPS PUT o POST. Va bene qualunque cosa accetti HTTPS PUT:
- Una directory sul tuo web server, con PHP, Python, Node o quello che già hai in piedi, che riceve l’upload e lo scrive su disco. La maggior parte degli host statici (cPanel, Apache puro, nginx puro) si configura per farlo in meno di trenta minuti.
- Un bucket Amazon S3. Eventualmente con CloudFront davanti per la distribuzione globale.
- Cloudflare R2 (API S3-compatibile, niente costi di egress), Bunny Storage, Wasabi, Backblaze B2.
- Akamai MSL4, che è il livello di storage dietro all’ingest live di Akamai. Stesso protocollo, testato alla scala dei più grandi eventi live del pianeta.
- Qualunque altro endpoint che parli HTTPS PUT e risponda con un codice 2xx.
Una prova gratuita di 7 giorni dell’app. Dopo, la funzione di pubblicazione live richiede un abbonamento settimanale che parte da $0.99/settimana. L’anteprima della camera e la registrazione locale sono sempre gratuite, vale la pena saperlo se ti serve solo un registratore.
Questa è tutta la lista della spesa. Niente streaming server, niente RTMP, niente VM media server da tenere aggiornata. L’encoder, il transcoder, il packager e il publisher stanno dentro all’app sul tuo Mac. Sull’unico filo che esce c’è solo HLS finito, in una sola direzione, dentro a un bucket.
Cosa sostituisce
Vale la pena essere concreti su cosa sparisce dal diagramma di architettura.
Lo streaming server. Wowza Streaming Engine, Nimble Streamer, Ant Media Server, AWS Elemental MediaLive, l’ingest RTMP di Mux e le altre dieci soluzioni di questa categoria esistono per un motivo: ricevere uno stream RTMP da un encoder e trasformarlo in HLS. Se il tuo encoder produce HLS direttamente, lo streaming server non ha più nulla da fare. Lo puoi cancellare dal diagramma e dal budget.
Il transcoder in cloud. AWS Elemental MediaConvert, Mux Live, Bitmovin, Google Live Transcoder. Fatturano al minuto di input e al minuto di output. Uno stream 1080p mandato su a un solo bitrate, transcodificato in quattro bitrate di uscita, diventa subito una spesa seria anche per un solo evento di un pomeriggio, e una spesa molto seria su un canale continuo. L’encoder hardware Apple silicon nel tuo Mac è più veloce, gratis ed è la stessa famiglia di chip che esegue l’export di Final Cut Pro. Codificare le quattro varianti ABR direttamente sul Mac elimina del tutto la voce di transcodifica.
Il packager. AWS Elemental MediaPackage, Unified Streaming, il packager di Wowza Streaming Cloud, tutti esistenti per impacchettare uno stream in HLS o DASH. L’app produce HLS broadcast-standard alla sorgente. Non resta nulla da impacchettare.
La CDN, nel caso piccolo. Questa è quella che sorprende di più le persone. Le CDN esistono per due motivi: terminare traffico globale pesante vicino allo spettatore e assorbire il traffico improvviso di una flash crowd che un origin non riesce a reggere. Il web server economico che hai già consegna i segmenti HLS perfettamente bene da solo fino a un numero reale e finito di spettatori concorrenti. Il calcolo è lineare: una variante HLS 1080p a 5 Mbps su un uplink gigabit satura il link a circa 200 spettatori concorrenti (1000 ÷ 5). La variante 720p a 3 Mbps porta a circa 330. La variante 540p a 1.8 Mbps arriva intorno a 550. In un pubblico ABR reale gli spettatori sono distribuiti su tutti questi gradini (utenti mobili sulle varianti basse, desktop su quelle alte), quindi un piccolo VPS regge comodamente qualche centinaio di spettatori concorrenti, e spesso di più, a seconda del mix di dispositivi. Questo copre la stragrande maggioranza degli eventi singoli e dei canali piccoli e medi. Una CDN serve solo quando il pubblico supera stabilmente quella soglia, che è più tardi di quanto la gente pensi.
Sorprese sulla banda al GB. Quando il tuo origin è uno streaming server in affitto e la tua delivery è una CDN in affitto, ogni minuto-spettatore tocca entrambi i contatori. Auto-ospitare sposta il contatore sulla tua infrastruttura: un VPS da $5 con banda generosa, un bucket R2 senza costi di egress, una distribuzione CloudFront alla tariffa che hai già negoziato, qualunque cosa tu abbia in mano. Nessuno ti chiamerà a fine mese perché il tuo stream è diventato virale.
Termini di piattaforma. YouTube e Twitch ti danno un endpoint RTMP gratuito e un player, e in cambio decidono loro cosa è monetizzabile, cosa va bloccato per età, cosa viene raccomandato, cosa viene tolto e in quale settimana. Auto-ospitare non è gratis né in tempo né in soldi, ma non viene con il regolamento di un terzo. Il tuo stream, il tuo dominio, le tue regole.
Cosa resta uguale
Auto-ospitare è un cambiamento vero, ed è onesto essere chiari su cosa non cambia.
La banda la paghi comunque, da qualche parte. I byte devono uscire da qualche parte. La scelta è tra una SaaS di streaming che mette transcodifica e delivery in una sola fattura, e l’auto-hosting in cui paghi separatamente lo storage e l’egress. Per la maggior parte dei pubblici non banali la seconda strada è più economica. Per uno stream con cinque spettatori, un account YouTube gratuito è più economico. Adatta lo strumento al pubblico.
Ti serve comunque un player. Va bene qualunque
player HLS. Video.js, hls.js, Shaka Player, l’HLS nativo del browser in
Safari e su iOS, l’AVPlayer di Apple TV, i player di Roku,
Fire TV e Android. Nessuno di questi richiede nulla di particolare al
tuo origin. Se l’URL di destinazione serve un index.m3u8
valido, ogni player moderno lo riproduce.
Devi comunque pensare alla latenza. L’HLS standard con segmenti da sei secondi viaggia a circa 18 a 30 secondi di latenza glass-to-glass. Va bene per talk show, set musicali, sermoni, lezioni, contenuti dietro le quinte, highlight di gaming, canali FAST, qualunque cosa che non sia un’asta o un torneo esports. Per latenza sotto i cinque secondi servono LL-HLS, WebRTC o DASH-LL, e i conti cambiano.
Ti serve comunque uptime, proporzionato alla trasmissione. Un Mac sulla scrivania va benissimo per un evento singolo: un SSD, un UPS, una connessione cablata e sei a posto per il pomeriggio. Per una trasmissione lunga o sempre attiva conviene un Mac mini in un posto fresco, un UPS, una connessione cablata e idealmente un secondo Mac su cui poter fare failover. La funzione di registrazione locale dell’app ti dà un file di backup in entrambi i casi. Niente di tutto questo è più difficile che gestire uno streaming server, e quasi tutto è più amichevole.
Il test dei cinque minuti
Il modo più rapido per scoprire se funziona per te è pubblicare uno stream di prova su un endpoint pubblico e ispezionare il risultato. L’app include un tipo di destinazione “HTTP PUT Server” che non richiede né autenticazione né setup dalla tua parte:
- Apri l’app, vai in Destinations, tocca +.
- Scegli HTTP PUT Server.
- Chiamala “Test”, upload URL
https://ams.ireplay.tv/hls/test/, playback URL la stessa. - Lascia l’autenticazione vuota.
- Test Connection. Il server restituisce HTTP 201.
- Salva.
- Profiles, crea un profilo, scegli la destinazione di test, i default vanno bene.
- Live, scegli il profilo, Go Live. Parla davanti alla camera per trenta secondi, Stop.
- La schermata di riepilogo mostra la playback URL. Aprila in Safari,
in
ffprobe, in un qualunque player HLS.
Se parte, il tuo Mac ha appena fatto da encoder, transcoder, packager e publisher. Da capo a fondo, senza streaming server in mezzo. I byte che stai guardando sono passati direttamente dall’encoder H.264 sul tuo chip Apple a un bucket pubblico e poi al tuo player. L’intera pipeline è vissuta dentro un’unica app.
Quel tipo di destinazione punta a qualunque endpoint HTTPS PUT. Sostituisci la URL con quella di un tuo bucket e stai auto-ospitando uno stream sulla tua infrastruttura.
Stream singolo, oppure un canale 24/7 che lo avvolge
Una singola diretta è un prodotto completo di per sé. Premi Go Live per la durata dell’evento, Stop quando finisce, lasci la registrazione sul tuo dominio come replay. È un uso perfettamente valido dell’app ed è quello che la maggior parte degli utenti farà la maggior parte delle volte.
La domanda che separa un evento da un’emittente è cosa succede quando non sei in onda. Se uno spettatore atterra sulla pagina del tuo canale un martedì pomeriggio mentre non sta andando in onda nulla, vede una schermata di “stream offline” e rimbalza via. La maggior parte dei broadcaster indipendenti perde quel traffico senza accorgersene.
L’app companion, My TV Channel, copre quel buco. È uno strumento di playout 24/7: gli dai in pasto la tua libreria video esistente e lui costruisce un palinsesto lineare continuo (VOD2Live, a volte chiamato FAST) che gira tutto il giorno. Gli spettatori che si sintonizzano in qualsiasi momento della giornata trovano sempre qualcosa, anche quando non c’è alcun evento live in corso. Lo stesso account My TV Channel che usi per il playout si collega direttamente all’app My Live TV Channel, quindi quando premi Go Live il tuo segnale live viene inserito nel palinsesto in corso. Gli spettatori sintonizzati sul VOD2Live vedono la tua diretta prendere il sopravvento. Quando ti fermi, il palinsesto riprende dal punto giusto.
Puoi adottare le due cose nell’ordine che preferisci. Inizi con singoli eventi live e aggiungi la presenza 24/7 più avanti, quando il pubblico la chiede. Oppure parti da un palinsesto 24/7 e usi l’app live per inserire notizie, momenti dell’ultim’ora, sessioni di Q&A o show live programmati sopra di esso.
Lo strumento live, lo strumento di playout e lo strumento di pubblicazione sono tre app che condividono una sola destinazione di storage. In questa architettura non c’è uno streaming server da nessuna parte: c’è solo lo storage che hai scelto, il Mac sulla tua scrivania e i player nelle mani dei tuoi spettatori.
Verdetto onesto
Se stai trasmettendo un piccolo show con tre spettatori e nessun piano di crescita, apri un account YouTube gratuito e metti l’embed sul tuo sito. Non sei tu il pubblico di questo articolo.
Se stai gestendo uno stream a pagamento, una trasmissione riservata ai membri, una messa domenicale per la tua congregazione, un canale FAST di nicchia, un evento live aziendale, una ritrasmissione interna (town hall, formazione) verso il tuo server web on-prem, una lega sportiva, la diretta di un matrimonio per i parenti lontani, un canale lineare di proprietà di un creator, o qualunque cosa in cui i termini di piattaforma e le bollette al GB sono costi reali, i conti diventano interessanti molto in fretta. Un Mac mini, un bucket di destinazione o anche solo un web server normale, e un abbonamento da $0.99/settimana sostituiscono uno stack di fatture cloud che, messe insieme, partivano da tre cifre al mese e salivano da lì. Il diagramma di architettura sta su un post-it. Il numero di fornitori che possono toglierti lo stream con un aggiornamento dei TOS passa da “diversi” a “zero”.
Lo streaming server al centro è sempre stato opzionale. L’hardware in ogni Mac su ogni scrivania aspettava silenziosamente di fare quel lavoro da anni. My Live TV Channel è il software che finalmente glielo lascia fare.