Vai al contenuto
Offerte

scrcpy 5.0 sposta la decodifica sulla GPU: CPU da 103% a 3,6%

In questo articolo Indice dei contenuti 2 sezioni

Con il rilascio di scrcpy 5.0, il noto strumento per il mirroring di Android su computer cambia profondamente il modo in cui gestisce il flusso video. La decodifica può ora passare ai blocchi hardware della GPU, con un calo molto marcato dell’uso della CPU e, di riflesso, meno calore e consumi più contenuti. Il programma continua a permettere la visualizzazione e il controllo di dispositivi Android da Windows, Linux e macOS tramite USB o TCP/IP, senza root e senza dover installare stabilmente un’app sul telefono.

Mostrare sul PC lo schermo di uno smartphone significa gestire in tempo reale un flusso continuo. Il telefono acquisisce e comprime le immagini, di norma in H.264, il segnale viaggia attraverso ADB (Android Debug Bridge) e il computer deve decodificare decine di fotogrammi al secondo abbastanza in fretta da tenere bassa la latenza. Finora quel lavoro ricadeva quasi tutto sul processore tramite FFmpeg, e il peso cresceva parecchio con risoluzioni elevate, frame rate sostenuti e sessioni prolungate.

Come funziona la decodifica hardware di scrcpy 5.0

Le schede grafiche, comprese quelle integrate nei chip Intel, AMD, Apple e Qualcomm, dispongono di unità pensate apposta per la decodifica video. Si tratta di circuiti specializzati che consumano meno energia e svolgono questo tipo di elaborazione con un’efficienza molto superiore rispetto ai core general purpose del processore. La nuova versione non si lega a una singola tecnologia proprietaria ma sceglie il backend più adatto al sistema operativo. Su Windows usa D3D11VA, su Linux VA API, mentre su macOS si appoggia a VideoToolbox.

Per l’utente l’attivazione è praticamente trasparente. Basta impostare l’opzione hwdec su auto e scrcpy prova a inizializzare un decoder hardware compatibile con il codec in uso. Se qualcosa non va, torna da solo alla decodifica software. Nella maggior parte dei casi non serve conoscere il modello esatto della scheda grafica né selezionare il decoder a mano. Chi vuole toccare con mano la differenza può impostare la stessa opzione su disabled, avviare il programma in entrambe le modalità e osservare il carico dal Task Manager di Windows o da strumenti equivalenti su Linux e macOS. Su alcune macchine lo scarto salta subito all’occhio.

I numeri diffusi dagli sviluppatori sono notevoli. Su un sistema Windows x86 a 64 bit con Ryzen 5 5600G il carico è sceso da circa 103,2% a 3,6%, mentre su Windows ARM64 si è passati da circa il 112% all’8%. Su Linux, con Intel Core Ultra X7 358H, il confronto riportato va da 48,5% a circa 3%. I risultati cambiano in base al sistema operativo, al modo in cui lo strumento conteggia i core, al codec, alla risoluzione, al frame rate e all’hardware, ma Genymobile parla comunque di una riduzione nell’ordine di 10 volte. Il beneficio diventa tangibile quando il programma resta aperto a lungo, accanto ad Android Studio e a un browser pieno di schede, insieme a OBS Studio per registrare tutorial oppure durante le sessioni di assistenza remota.

Codec, impostazioni e consumi reali

L’accelerazione hardware non garantisce che qualunque PC gestisca qualsiasi formato, perché tutto dipende dal decoder integrato nella GPU e dai driver installati. H.264 offre la compatibilità più ampia ed è il codec predefinito, H.265 è diffuso sulle schede relativamente recenti e AV1 richiede hardware più moderno. Se lo smartphone produce un flusso che il PC non sa gestire in hardware, il programma continua a usare FFmpeg sul processore. L’opzione list encoders mostra quali encoder mette a disposizione il telefono, ma il computer deve avere un decoder compatibile. Scegliere AV1 su una macchina priva di supporto dedicato potrebbe quindi produrre l’effetto opposto.

H.265 e AV1 comprimono meglio, eppure qui conta soprattutto la latenza. Si muove il mouse, si digita, si apre un’app e il risultato deve comparire subito. Per questo H.264 resta una scelta vantaggiosa, visto che è supportato quasi ovunque e le implementazioni sono mature. Per alleggerire ancora il lavoro si può ridurre la quantità di dati generati, per esempio limitando la dimensione massima del video a 1600 pixel con l’opzione max size, che mantiene le proporzioni dello schermo. Allo stesso modo max fps limita il frame rate e video bit rate controlla il bitrate.

Meno processore impegnato significa in genere meno consumi, anche se non esiste un rapporto diretto tra percentuale risparmiata e watt assorbiti dall’intero sistema, dato che anche il decoder grafico consuma energia, solo in modo più efficiente. Su un desktop la differenza si traduce soprattutto in temperature più basse e ventole meno rumorose, mentre su un portatile può allungare l’autonomia nelle sessioni di lavoro lunghe. Dietro le quinte i frame possono restare nella memoria grafica fino al rendering e la gestione delle code tiene conto dei limiti dei decoder hardware. scrcpy 5.0 introduce infine build native per Windows ARM64, pensate soprattutto per i PC Windows 11 basati sui più recenti SoC Snapdragon, che non devono più affidarsi alla traduzione del codice x86 o x64 e possono sfruttare direttamente la piattaforma ARM.

Fonte: TecnoAndroid

Condividi:
195 Condivisioni