L'isola in mezzo al fiume

Bentornati sulle due rive. Fino a oggi abbiamo costruito ponti tra due rive sole. Ma una riunione di lavoro ha sei partecipanti, una lezione ne ha trenta, una diretta ne può avere migliaia. Oggi parliamo di cosa succede quando le rive si moltiplicano.

E per farlo dobbiamo aggiungere un elemento alla nostra metafora: un'isola in mezzo al fiume.

La prima idea, la più naturale, è non cambiare nulla. Se le rive sono quattro, ognuna costruisce un ponte verso ognuna delle altre. Si chiama rete a maglia, in inglese mesh.

Funziona, ed è bellissima sulla carta: nessun server multimediale, la latenza minima possibile, la cifratura sempre da un capo all'altro. Ma fate due conti. Con quattro partecipanti, ognuno manda il proprio video a tre persone. Se il video richiede un megabit e mezzo al secondo, servono quattro megabit e mezzo in uscita. Con otto partecipanti, più di dieci. La banda in uscita delle connessioni domestiche, soprattutto quelle non in fibra, finisce in fretta.

E non è solo banda. Ogni ponte ha il suo controllo della congestione, quindi il browser codifica il video più volte, una per ogni destinatario, a qualità diverse. Il processore si scalda, la batteria si svuota.

La regola pratica che si legge spesso è questa: la maglia va bene fino a tre, al massimo quattro partecipanti. Oltre, serve l'isola.

La prima forma storica dell'isola è il mulino. Si chiama MCU, unità di controllo multipunto, e viene dal mondo delle videoconferenze professionali di vent'anni fa.

Ogni partecipante costruisce un solo ponte, verso l'isola, e manda il suo video. Il mulino decodifica tutti i video, li compone in un'unica immagine, la classica griglia con tutti i volti, mescola tutti gli audio, e ricodifica il risultato. A ogni partecipante rimanda un solo flusso.

Per i partecipanti è il massimo della leggerezza: un flusso in uscita, un flusso in entrata. Ma per il server è un lavoro enorme: decodificare e ricodificare video in tempo reale costa moltissimo calcolo. E ogni partecipante vede la stessa composizione, decisa dal server. Oggi l'MCU si usa soprattutto per collegarsi ai sistemi di telefonia tradizionale, o per produrre una registrazione già composta.

L'architettura che domina oggi è un'altra, e si chiama SFU, unità di inoltro selettivo. Sull'isola non c'è un mulino, ma un mercato.

Ogni partecipante manda il proprio video all'isola, una volta sola. L'isola non lo decodifica: guarda soltanto le etichette sui pacchetti e li inoltra agli altri partecipanti. Ogni partecipante riceve quindi un flusso per ogni altra persona, e il browser li mostra come preferisce.

Il lavoro per il server è molto più leggero, perché inoltrare pacchetti costa poco rispetto a ricodificarli. La banda in uscita di ogni partecipante resta costante, qualunque sia il numero delle persone. E l'applicazione è libera di disporre i video come vuole: griglia, oratore in grande, miniature.

La parola chiave però è selettivo. Il mercato non inoltra tutto a tutti: sceglie.

Immaginate un partecipante con una connessione ottima e uno sul treno, con il telefono. Il primo vorrebbe il video in alta definizione, il secondo non riesce a riceverlo. Ma l'isola non ricodifica: come fa a mandare qualità diverse a persone diverse?

La risposta si chiama simulcast. Il mittente codifica il proprio video tre volte, a tre risoluzioni diverse: piccola, media e grande. E le manda tutte e tre all'isola. Costa un po' di banda in più in uscita, circa la metà in più, non il triplo, perché le versioni piccole pesano poco. L'isola, per ogni ricevente, sceglie quale delle tre inoltrare, in base alla banda di quel ricevente e alla dimensione con cui mostra quel video. La miniatura in un angolo riceve la versione piccola. L'oratore a tutto schermo, quella grande.

L'alternativa più moderna si chiama codifica scalabile, SVC, disponibile con VP9 e AV1. Invece di tre codifiche separate, una sola codifica fatta a strati: uno strato di base e strati che aggiungono risoluzione o fotogrammi. L'isola toglie gli strati che il ricevente non può permettersi. È più efficiente, ma richiede codec più recenti.

Le isole più evolute fanno anche altre scelte: inoltrano il video solo degli ultimi che hanno parlato, guardando il livello audio che il browser scrive in un'estensione dei pacchetti, e mettono in pausa i video di chi non è visibile sullo schermo.

Non serve costruire un'isola da zero. Esistono server SFU open source molto maturi.

Mediasoup è una libreria per Node.js con il cuore scritto in C più più: vi dà i mattoni e vi lascia tutta la libertà, compresa quella di sbagliare. Janus, scritto in C, è un server generico con un sistema di estensioni. Jitsi Videobridge, in Java, è il cuore di Jitsi Meet. LiveKit, scritto in Go, è una piattaforma completa, con strumenti per il client e per il server, e si appoggia a Pion, la realizzazione di WebRTC interamente in Go che useremo nel prossimo episodio.

Per pubblici molto grandi, le isole si mettono in fila: un'isola per ogni regione geografica, collegate tra loro. Si chiama cascata. Il video di chi parla da Milano arriva una volta sola all'isola di New York, che lo distribuisce ai partecipanti americani.

L'ultimo pezzo riguarda la trasmissione in diretta, e qui WebRTC ha colmato una lacuna storica.

Il problema era che ogni server multimediale aveva la propria segnalazione. Se volevate mandare una diretta da OBS Studio, il programma più usato da chi trasmette, a un server WebRTC, non c'era un modo standard di farlo. Così la diretta usava protocolli vecchi, come RTMP, con secondi di ritardo.

WHIP risolve il problema nel modo più semplice possibile: la segnalazione diventa una singola richiesta HTTP. Il mittente manda l'offerta SDP con una richiesta POST, il server risponde con la risposta SDP e con l'indirizzo della sessione. Per chiudere, una richiesta DELETE a quell'indirizzo. Tutto qui. WHIP è diventato la RFC 9725 a marzo 2025, e OBS lo supporta dalla versione 30. Il suo gemello per ricevere, WHEP, è ancora una bozza alla IETF, ma è già implementato in diversi server e lettori.

Con WHIP e WHEP, WebRTC diventa un'alternativa concreta per le dirette in cui il ritardo conta: aste, scommesse, eventi sportivi, lezioni interattive. Meno di mezzo secondo, invece dei cinque o dieci dei protocolli basati su HTTP.

Quindi, ricapitolando: la rete a maglia è perfetta per due o tre persone, poi serve un'isola. L'MCU mescola tutto e costa caro, la SFU inoltra senza decodificare ed è oggi la scelta normale. Simulcast e SVC le permettono di servire ogni ricevente al meglio, e WHIP e WHEP portano WebRTC nel mondo della diretta.

Abbiamo visto tutti i pezzi. Nel prossimo episodio apriamo il cantiere e li mettiamo insieme nel codice: un server di segnalazione in Go, un client in JavaScript e un pari scritto con Pion. Ci sentiamo lì.