La latenza della condivisione dello schermo è uno di quei problemi che noti solo quando è grave. Un relatore passa alla slide successiva e il pubblico che guarda lo schermo condiviso la vede un attimo e mezzo dopo. Non è proprio un guasto, semplicemente qualcosa non torna. Nel corso di alcune release abbiamo analizzato a fondo da dove arrivasse quel ritardo nella condivisione dello schermo di Cliqer e abbiamo portato la latenza costante da oltre due secondi a circa mezzo secondo, un miglioramento di circa quattro volte. Questa è la versione in parole semplici di come ci siamo riusciti.
Non nasconderemo nomi in codice né fingeremo che esistesse una soluzione miracolosa. Ci sono stati tre interventi distinti, ciascuno mirato a un punto diverso in cui si nascondeva il ritardo, e i loro effetti si sono sommati.
Quando condividi uno schermo, devono succedere tre cose prima che uno spettatore veda un fotogramma: il tuo computer deve catturarlo, codificarlo in video e inviarlo. Ognuno di questi passaggi può aggiungere ritardo senza dare nell'occhio, e l'effetto si accumula. Un encoder lento, più un buffer prudente, più l'attesa del successivo aggiornamento completo del fotogramma possono facilmente sommarsi fino a due o tre secondi, anche con una connessione veloce.
La parte insidiosa è che nessuno di questi elementi, preso da solo, sembra guasto. La cattura funziona. La codifica funziona. Lo stream arriva. Semplicemente arriva tardi, e “arriva tardi” è difficile da diagnosticare senza misurare ogni fase separatamente.
La prima fonte di ritardo era lavoro sprecato. Le condivisioni dello schermo e NDI venivano codificate due volte dietro le quinte, una per ciascun percorso di uscita, e una slide ferma veniva ricodificata di continuo anche se sullo schermo non era cambiato nulla. Questo raddoppiava il carico sull'encoder senza alcun beneficio visivo e rendeva la pipeline sempre più impegnata del necessario, spingendo ogni fotogramma più indietro nella coda.
Eliminare il passaggio di codifica duplicato, e saltare la ricodifica quando l'immagine non è cambiata, ha liberato subito un margine di CPU significativo. Meno contesa sull'encoder significa che ogni fotogramma che deve davvero essere codificato viene elaborato prima.
La seconda fonte era il buffer tra l'encoder e la rete, la parte che serve ad assorbire brevi intoppi di rete, così che un'esitazione sulla linea non diventi un'esitazione sullo schermo. Buffer di questo tipo sono per natura un compromesso: troppo piccoli e un minimo intoppo provoca glitch visibili, troppo generosi e aggiungi ritardo a ogni singolo fotogramma solo nel caso in cui qualcosa vada storto più avanti.
Il buffer era stato dimensionato con generosità, il che significava aggiungere ritardo a ogni fotogramma nel caso comune per proteggersi da un caso raro. Stringerlo ha ridotto il ritardo nel caso peggiore da qualche secondo a ben meno di uno, continuando ad assorbire brevi intoppi di rete senza glitch visibili. È il tipo di intervento che in un diff sembra la modifica di un piccolo numero ed è in realtà una scelta ponderata su quale modalità di guasto preferisci avere.
Il terzo intervento riguardava un momento specifico e fastidioso: cosa succede quando qualcuno si collega a una condivisione già in corso. La compressione video funziona inviando solo occasionalmente fotogrammi completi, chiamati keyframe, con in mezzo fotogrammi più leggeri del tipo “cosa è cambiato dall'ultima volta”. Uno spettatore che si collega a stream avviato non può interpretare quei fotogrammi intermedi finché non riceve un keyframe a cui agganciarsi, e prima questo significava aspettare il successivo keyframe programmato, fino a tre secondi dopo.
La soluzione è stata tenere in cache il keyframe più recente e consegnarlo a un nuovo spettatore nel momento in cui si collega, invece di fargli aspettare il successivo in programma. Insieme alla temporizzazione dei fotogrammi basata su intervalli descritta nella nostra documentazione sulla condivisione dello schermo, i nuovi spettatori ora vedono il video entro pochi millisecondi dal collegamento a una condivisione, invece di aspettare fino a tre secondi il keyframe successivo.
Sommando i tre interventi, la latenza costante di oltre due secondi di cui quasi nessuno si fidava davvero è diventata circa mezzo secondo, un miglioramento di circa quattro volte, con meno CPU e meno banda di prima. Anche il frame rate pieno conta: il video Program era silenziosamente limitato a circa 31 fotogrammi al secondo indipendentemente dalla sorgente, quindi ora una condivisione a 60fps appare fluida sul lato ricevente quanto sullo schermo del relatore.
Niente di tutto questo richiede di modificare un'impostazione. È incluso nella pipeline di condivisione dello schermo dell'app desktop e si applica sia che tu stia condividendo un singolo monitor per un pubblico ristretto, sia che tu stia gestendo una produzione completa in Studio con più sorgenti, compresi i flussi di lavoro vMix che contano su un feed veloce e prevedibile. In Cliqer 3, il video di Studio su Mac è a copia zero: i fotogrammi della videocamera, le sorgenti e Program restano nella memoria della GPU, e l'encoder hardware legge Program direttamente dalla superficie della GPU. Cliqer 3 mostra inoltre costantemente il frame rate di Program e il carico di GPU e CPU nella riga di stato di Studio, così puoi verificare da solo il frame rate in piena diretta. Se oltre al lavoro sulla latenza vuoi bilanciare qualità e banda, le impostazioni di condivisione dello schermo coprono la scelta del codec, la risoluzione e il bitrate, e la versione desktop 2.2.0 ha aggiunto l'opzione per includere direttamente l'audio di sistema o del microfono in una condivisione.
Per le configurazioni ibride, dove il ritardo era più evidente, in particolare quando un relatore da remoto guarda uno schermo condiviso e reagisce in diretta, questo si abbina alla nostra guida su come risolvere la latenza della condivisione dello schermo nelle riunioni ibride e al nostro approfondimento sul perché la latenza del telecomando per presentazioni in millisecondi conta sul lato del controllo tanto quanto sul lato video.
La condivisione dello schermo è una parte del percorso. L'altra è il percorso di rete stesso: se la connessione tra relatore e spettatore è diretta o tramite relay, e cosa succede sulle reti che bloccano il traffico peer-to-peer diretto. Trattiamo questo aspetto, incluso il motivo per cui su alcune reti non può mai essere eliminato del tutto, in server TURN spiegati e WebRTC è sicuro.
| Fase | Prima | Dopo |
|---|---|---|
| Codifica | Passaggio di codifica duplicato, ricodifica continua dei fotogrammi statici | Passaggio singolo, salta i fotogrammi invariati |
| Buffering | Buffer generoso, aggiunge ritardo a ogni fotogramma | Buffer più stretto, assorbe comunque brevi intoppi |
| Collegamento di un nuovo spettatore | Attende fino a 3 secondi il keyframe successivo | Keyframe in cache consegnato immediatamente |
| Latenza costante | Oltre 2 secondi | Circa 0,5 secondi |
Server TURN spiegati
Perché parte della latenza residua deriva dal percorso di rete, non dall'encoder.
Soluzioni per la latenza della condivisione dello schermo
Altre soluzioni per le configurazioni ibride in cui un relatore da remoto guarda lo schermo condiviso.
No. Questi interventi riguardano il ritardo e il lavoro di codifica sprecato, non la risoluzione o il bitrate. Puoi comunque scegliere risoluzione e bitrate in modo indipendente nelle impostazioni di condivisione dello schermo.
Non serve modificare manualmente alcuna impostazione. L'app desktop riceve automaticamente le nuove release e i miglioramenti della pipeline si applicano non appena usi una versione aggiornata.
Gli stream video si basano su fotogrammi completi periodici, chiamati keyframe, che permettono a un nuovo spettatore di iniziare la decodifica. Prima un nuovo spettatore doveva aspettare il successivo keyframe programmato, che ora l'intervento consegna invece immediatamente da una cache.
Sì. L'intervento sulla codifica duplicata riguardava specificamente sia le condivisioni dello schermo sia l'uscita NDI, e l'uscita Program di Studio beneficia degli stessi miglioramenti di frame rate pieno e di buffer.
Il modo più rapido per percepire la differenza è condividere uno schermo e osservare il volto di qualcun altro mentre lo vede. Scarica Cliqer gratis e prova una condivisione dello schermo sulla tua configurazione, oppure scopri tutte le funzionalità della condivisione dello schermo e confronta i piani nella pagina dei prezzi.
Monitor di ritorno spiegati: cosa vedono i relatori e perché
Cosa mostra un monitor di ritorno a un relatore, perché è importante e come crearne uno con un display di riserva e un conto alla rovescia.
Hardware, telefono o Internet: telecomandi per presentazioni a confronto nel 2026
Dongle USB, app per smartphone o telecomando via Internet? Portata, affidabilità, costi e configurazione a confronto per scegliere il telecomando giusto.
Continua a leggere
Guide pratiche per relatori, tecnici AV e team di eventi, più le release di Cliqer che contano davvero. Niente spam, ti disiscrivi con un clic.
