Convertire GIF in WebM

Il motivo per scegliere WebM rispetto a MP4 non è che sia migliore in astratto; è che un elemento video può elencare più di una sorgente e il browser prende la prima che comprende. Mettendo il WebM per primo e l’MP4 dopo, ogni visitatore riceve il file più piccolo dove il suo browser lo supporta e un file funzionante dove non lo supporta.

Funziona solo se si possiede il markup. Una GIF inviata a un cliente, pubblicata su un forum o inserita in una slide non ha meccanismo di fallback, e lì WebM è una scelta peggiore di MP4 per una ragione che non ha nulla a che fare con il codec. Questa pagina presume che si stia editando l’HTML in proprio.

Entrambi i codec funzionano allo stesso modo in sintesi: memorizzano un frame completo, poi memorizzano le differenze. VP9 è arrivato circa un decennio dopo e spende considerevolmente più sforzo per frame nel decidere come partizionare l’immagine e dove cercare corrispondenze, il che compra byte reali su materiale che si ripete.

Il materiale da GIF è insolitamente adatto a questo. Colore piatto, bordi netti, ampie regioni invariate e moto sintetico sono tutti i casi in cui una ricerca più ampia trova di più, quindi il divario tra VP9 e H.264 su una GIF convertita è più ampio del divario su footage di videocamera. Il costo è il tempo di codifica, che si paga una volta, in questa scheda, anziché su ogni caricamento di pagina.

Il record del contenitore qui lo elenca come streamable, e questo è il secondo risparmio su una pagina. Un browser può iniziare a riprodurre un WebM dai suoi primi byte, quindi l’animazione parte mentre il resto sta ancora scendendo.

Una GIF non può farlo in alcun senso utile. I browser mostreranno i primi frame mentre arrivano, ma il loop non funziona correttamente finché l’intero file non è atterrato, il che su una connessione lenta significa un primo frame statico fermo lì per secondi. Sostituire una GIF con un WebM cambia la forma di quell’attesa oltre alla sua lunghezza.

WebM è uno dei pochissimi formati video in grado di memorizzare trasparenza, e il suo record in questo registro lo dice. Quella capacità è reale, e vale la pena conoscerla perché rende WebM il formato a cui la gente ricorre quando vuole un video che fluttua sullo sfondo di una pagina.

Il file scritto da questa conversione non lo usa. La traccia video è opaca, quindi una GIF il cui sfondo era dichiarato trasparente perde quello nel passaggio, e non c’è impostazione di colore di sfondo su questa coppia per controllare cosa lo sostituisce. Se la trasparenza è il punto dell’animazione, il WebP animato è la raccomandazione onesta: mantiene il canale alfa e viene riprodotto in ogni browser attuale.

Ogni frame di una GIF è disegnato da una palette di al massimo 256 colori. Qualunque gradiente o ombra morbida avesse l’animazione all’origine è stato ridotto a quello quando la GIF è stata scritta, spesso con dithering applicato per nascondere gli scalini.

VP9 memorizza ciò che riceve e non impone una palette propria, quindi l’animazione non peggiora. Non può nemmeno migliorare, e il dithering è attivamente costoso: è rumore, e il rumore è la cosa che sconfigge la ricerca di ridondanza di un codec video. Una GIF fortemente dithered produce un WebM più grande di una piatta delle stesse dimensioni, e alzare la banda di qualità spende byte per preservare il pattern di dithering anziché l’immagine.

I ritardi GIF sono per frame e memorizzati in centesimi di secondo, quindi una GIF spesso gira a frequenze che nessuna videocamera ha mai prodotto — 12,5 frame al secondo, o diverse frequenze diverse all’interno di un file. La conversione porta la durata propria di ciascun frame nel video anziché ricampionare a una frequenza costante.

Un ritardo memorizzato a zero è comune e significa «il più veloce che il display permette»; i browser lo hanno a lungo trattato come 100 millisecondi e così fa questa conversione. Il risultato pratico è che un’animazione temporizzata a occhio in un editor GIF gira alla stessa velocità di un WebM, il che non è qualcosa che una frequenza di frame fissa avrebbe conservato.

Entrambi i codec video usati su questo sito vogliono dimensioni in pixel pari, e una GIF non ha alcun obbligo del genere. Larghezze e altezze vengono arrotondate per eccesso al numero pari successivo prima che il primo frame venga disegnato, quindi una GIF larga 405 pixel produce un WebM largo 406 pixel.

Arrotondare per eccesso aggiunge una colonna anziché rimuoverne una, il che preserva il bordo dell’animazione. Se il video è disposto con una larghezza CSS fissa il pixel extra non emerge; se lo si sta confrontando con un’immagine di sfondo pixel per pixel, vale la pena sapere che il numero si è spostato.

Sostituire un elemento immagine con un elemento video non è uno scambio alla pari ed è il passaggio che più probabilmente va storto. Il video ha bisogno di una larghezza e altezza esplicite o di una regola sul rapporto d’aspetto, altrimenti la pagina reflowa quando carica — il che converte un problema di banda in un problema di spostamento del layout e lascia il report di performance non più felice.

Un frame di poster è l’altra cosa che vale la pena aggiungere. Senza ce n’è un rettangolo vuoto finché i primi frame non decodificano, dove la GIF almeno mostrava qualcosa. Esportare il primo frame come un WebP o PNG piccolo lo copre.

I frame sono letti dal decoder di immagini interno al browser e codificati dal suo encoder video interno, nella scheda che si sta guardando. Non c’è server nel percorso, nessuna coda, nessun account e nessuna quota giornaliera, e un batch prende 100 file in una volta.

Quel decoder non è presente ovunque. Dove manca la pagina lo dice e indica i browser che lo hanno, anziché inviare silenziosamente il file altrove perché sia finito — che è l’unica cosa che renderebbe falsa l’affermazione sopra.

Su Safari le vecchie versioni — pre-14, rilasciate prima del 2020 — non riproducevano VP9 e si limitavano a mostrare un riquadro vuoto. Una pagina che serve WebM come fonte unica lascia quei visitatori senza animazione, ed è esattamente per questo che l'approccio a due sorgenti con un MP4 di fallback è la risposta prudente: il browser prende la prima sorgente che sa riprodurre, e il visitatore vede qualcosa in entrambi i casi.

Se la pagina non può elencare due sorgenti — è il caso di una presentazione HTML statica senza JavaScript, o di un client email che accetta un solo allegato video — la scelta cade su MP4, che è la sorgente che non sorprende mai nessun browser oggi in produzione. WebM resta preferibile dove il controllo del markup lo consente, e per il resto è una questione di pubblico.