Quando si creano video, si convertono file esistenti o si preparano contenuti video per un sito web, scegliere il formato e le impostazioni di compressione è una delle decisioni più importanti. Il file più piccolo possibile non è necessariamente il migliore: deve anche essere riprodotto in modo affidabile nei browser, funzionare sugli smartphone, essere decodificato in maniera efficiente e conservare una qualità visiva adeguata allo scopo.
Ho esaminato MP4, WebM, H.264, H.265/HEVC, VP9, AV1, FFmpeg, i preset dell'encoder x264, la compatibilità dei browser, la decodifica hardware sui dispositivi mobili e le misure della qualità video. Ho anche condotto prove pratiche di compressione, codificando lo stesso video sorgente con diversi valori di CRF e confrontando i risultati sia visivamente sia con misurazioni oggettive.
Alla fine ho deciso di privilegiare MP4 con H.264 quando un unico file video deve funzionare sulla più ampia gamma possibile di browser, telefoni e applicazioni esterne.
Per i video brevi destinati soprattutto alla visione su smartphone, nei quali il caricamento rapido e le dimensioni ridotte contano più della conservazione di ogni minimo dettaglio, ho scelto x264 con CRF 30: durante la normale riproduzione non riuscivo a distinguere differenze visive significative tra CRF 22 e 30, neppure su un grande monitor da computer.
Questa decisione richiede però una precisazione importante: CRF 30 non è una raccomandazione per film, produzioni video di alto livello o riprese in cui la massima fedeltà visiva è fondamentale. Per questi impieghi, un valore decisamente più prudente, spesso intorno a CRF 20, può essere un punto di partenza migliore. Non ho condotto un'indagine analoga su lungometraggi o filmati cinematografici di alta qualità, quindi tali impostazioni vanno considerate soltanto come basi per ulteriori prove specifiche.
In questo articolo spiego il ragionamento tecnico, i risultati concreti della compressione, i limiti di quei risultati e come scegliere formato e qualità video in base alle esigenze del proprio progetto.
1. Contenitori video e codec sono due cose diverse
Prima di confrontare MP4 e WebM è essenziale capire la differenza tra un contenitore e un codec.
Un contenitore riunisce in un unico file video, audio, marcature temporali e metadati. Un codec video stabilisce invece come vengono compressi e decodificati i fotogrammi.
Per esempio, MP4 può contenere video H.264, HEVC oppure AV1. Anche se condividono la stessa estensione, queste combinazioni hanno caratteristiche di compressione e requisiti dei dispositivi differenti.
| Componente | Esempi | Funzione |
|---|---|---|
| Contenitore video | MP4, WebM, MOV, MKV | Raggruppa video, audio e informazioni temporali |
| Codec video | H.264, HEVC, VP9, AV1 | Comprime e decomprime i fotogrammi video |
| Codec audio | AAC, Opus, MP3 | Comprime e decomprime l'audio |
| Encoder video | x264, x265, SVT-AV1, libvpx-vp9 | Esegue la compressione video |
Rinominare un file da .webm a .mp4 non converte il codec video. Allo stesso modo, inserire AV1 in un contenitore MP4 non lo rende riproducibile su dispositivi privi del supporto alla decodifica AV1.
Quando si parla di compatibilità video bisogna considerare l'intera combinazione: contenitore, codec video, codec audio, profilo del codec, profondità in bit e ambiente di riproduzione.
2. MP4 o WebM: qual è il formato migliore per i video sul web?
MP4 e WebM sono entrambi validi contenitori video moderni. Nessuno dei due è superiore in assoluto, perché le caratteristiche pratiche dipendono dai codec presenti al loro interno.
MP4 con H.264: massima compatibilità pratica
MP4 con video H.264 e audio AAC ha alle spalle una storia di compatibilità eccezionalmente ampia. È supportato dai principali browser desktop e mobili, dai lettori video dei sistemi operativi e da numerose applicazioni di terze parti.
È inoltre comunemente supportato dai decoder video hardware di smartphone e computer. Rispetto alla decodifica software, quella hardware può ridurre il carico sulla CPU, rendere la riproduzione più efficiente e diminuire il consumo energetico.
Lo svantaggio principale è l'efficienza di compressione: i codec più recenti possono spesso raggiungere una qualità percepita simile con un bitrate inferiore.
Tuttavia, H.264 rimane un'ottima scelta quando l'affidabilità della riproduzione è più importante delle dimensioni minime assolute del file.
WebM con VP9: efficiente e adatto ai browser
WebM contiene comunemente video VP8, VP9 o AV1, con audio solitamente codificato in Opus o Vorbis.
A parità di qualità visiva, VP9 offre spesso una compressione più efficiente di H.264. È ampiamente supportato dai browser attuali, comprese le versioni moderne di Safari.
Sarebbe sbagliato affermare che Safari non supporta categoricamente WebM o VP9. La compatibilità dei browser è migliorata notevolmente nel tempo.
Il limite più importante riguarda invece la compatibilità al di fuori del browser. Le applicazioni native dei sistemi operativi, i dispositivi più vecchi e i software di terze parti potrebbero gestire WebM in modo meno uniforme rispetto al tradizionale MP4 con H.264.
Per un'applicazione usata esclusivamente nel browser, nella quale è possibile controllare le capacità di riproduzione, WebM è una soluzione valida. Per i video che gli utenti potrebbero scaricare e aprire in programmi diversi, MP4/H.264 rimane più prevedibile.
Le differenze pratiche
| Requisito | MP4 + H.264 | WebM + VP9 |
|---|---|---|
| Riproduzione nei browser moderni | Eccellente | Molto buona |
| Supporto di browser e dispositivi più vecchi | Generalmente migliore | Dipende maggiormente dall'ambiente |
| Compatibilità dei file scaricati | Generalmente migliore | Meno prevedibile nelle applicazioni native |
| Efficienza di compressione | Buona | Spesso migliore |
| Decodifica hardware | Molto diffusa | Comune, ma dipende dal dispositivo |
| Impiego più indicato | Un unico file ampiamente compatibile | Distribuzione web efficiente a client conosciuti |
La domanda fondamentale non è se WebM sia un buon formato, ma se i suoi vantaggi di compressione giustifichino i compromessi di compatibilità nel proprio ambiente.
3. H.264, H.265, VP9 e AV1: quale codec scegliere?
Ogni codec video importante offre un equilibrio diverso tra efficienza di compressione, costo della codifica, supporto hardware, compatibilità software e licenze.
| Codec | Efficienza di compressione | Compatibilità pratica | Utilizzi tipici |
|---|---|---|---|
| H.264 / AVC | Buona | Eccellente | Video web generici, riproduzione mobile, download |
| H.265 / HEVC | Generalmente migliore di H.264 | Dipende dall'ambiente | Dispositivi Apple compatibili, ambienti controllati, video ad alta risoluzione |
| VP9 | Generalmente migliore di H.264 | Molto buona nei browser moderni | Distribuzione video tramite browser |
| AV1 | Potenziale di efficienza eccellente | In crescita, con limiti sui dispositivi più vecchi | Streaming moderno e dispositivi compatibili |
Si tratta di confronti qualitativi, non di una classifica universale dei bitrate. L'efficienza reale dipende dal contenuto video, dall'implementazione dell'encoder, dalla qualità desiderata, dal preset di codifica e dal metodo di misurazione.
H.264: maturo, rapido da decodificare e ampiamente supportato
H.264 è altamente ottimizzato e supportato da una vastissima gamma di hardware e software. La sua maturità è un vantaggio quando un video deve funzionare in maniera affidabile senza richiedere un lettore speciale.
Il suo punto debole è che i codec più recenti possono spesso comprimere i video in modo più efficiente. H.264 comporta inoltre considerazioni relative a brevetti e licenze da valutare nei casi pertinenti di distribuzione commerciale.
H.265 / HEVC: compressione migliore, con compromessi di compatibilità
HEVC può ridurre sensibilmente il bitrate rispetto a H.264 mantenendo una qualità simile. È particolarmente interessante per i contenuti ad alta risoluzione e per gli ambienti in cui la compatibilità dei dispositivi è controllata.
Molti dispositivi Apple supportano molto bene HEVC. Tuttavia, il supporto nei browser e nelle applicazioni esterne varia in base al sistema operativo e ai componenti di decodifica installati. Anche le licenze sono un fattore da considerare.
HEVC può essere un'ottima soluzione, ma non lo renderei automaticamente l'unico formato scaricabile da un sito web generico.
VP9: un'alternativa aperta e pratica
VP9 offre una buona compressione e un'ampia compatibilità con i browser moderni. È una scelta convincente quando i video vengono riprodotti nel browser e l'ambiente di riproduzione è prevedibile.
Nel mio caso, il principale svantaggio era l'incertezza che emerge quando gli utenti scaricano i video o li aprono in applicazioni native che potrebbero non supportare WebM o VP9 in modo uniforme.
AV1: efficienza eccellente, ma supporto hardware non universale
AV1 è uno dei codec video moderni più promettenti. Può consentire riduzioni notevoli del bitrate rispetto ai codec precedenti e il supporto alla decodifica hardware continua ad ampliarsi.
Tuttavia, i dispositivi più vecchi potrebbero non avere un decoder AV1 o dover ricorrere alla decodifica software. Ad alta risoluzione, quest'ultima può consumare più risorse della CPU e più batteria, causando anche problemi di riproduzione sui dispositivi meno potenti.
Se controllate l'ambiente di riproduzione, AV1 merita una valutazione approfondita. Se un solo file deve funzionare su dispositivi vecchi e nuovi e nei comuni lettori video esterni, H.264 resta l'impostazione predefinita più sicura.
La guida MDN ai codec video contiene informazioni utili su questi codec e sui rispettivi requisiti di compatibilità nei browser.
4. Un solo formato video o più versioni?
Questa è una delle decisioni architetturali più importanti nella distribuzione dei video.
Quando è possibile fornire più versioni, un sito può offrire AV1 o VP9 ai dispositivi compatibili e usare H.264 come alternativa negli altri ambienti. Ciò può migliorare l'efficienza di compressione senza rinunciare a un'ampia copertura di riproduzione.
Gestire più versioni, però, aggiunge complessità alla codifica, all'archiviazione, alla cache, alla validazione e alla selezione della versione da riprodurre.
Se occorre esattamente un file video finale per ogni sorgente, spesso è preferibile una strategia che dia la priorità alla compatibilità.
Ho scelto MP4/H.264 perché volevo un unico file riproducibile nei principali browser, sugli smartphone e nei normali utilizzi dei video scaricati, senza dipendere da formati alternativi.
Questo non significa che MP4/H.264 offra la compressione migliore. È una decisione che privilegia la prevedibilità della riproduzione rispetto ai potenziali risparmi di spazio di un codec più recente.
5. Perché i video sui dispositivi mobili hanno priorità diverse
La compressione video deve rispecchiare il modo in cui i contenuti saranno effettivamente fruiti.
Un breve filmato visto soprattutto su smartphone ha esigenze diverse da quelle di un lungometraggio guardato su un grande televisore. Nel primo caso, il caricamento rapido e un minore consumo di dati mobili possono valere più della conservazione dei dettagli visivi più sottili. Nel secondo, la qualità dell'immagine può essere la priorità principale.
Per i video brevi destinati ai dispositivi mobili, file più piccoli possono offrire diversi vantaggi:
- Occorre trasferire meno dati prima di avviare la riproduzione.
- I download possono terminare prima sulle connessioni limitate.
- Serve meno spazio di archiviazione sul dispositivo.
- Gli utenti consumano meno dati mobili.
- La riproduzione può essere più resistente alla scarsa velocità della connessione quando il bitrate del video è inferiore.
Tuttavia, un file più piccolo non garantisce che il video non debba mai fermarsi per il buffering o bloccarsi. Contano anche le variazioni della rete, i picchi di bitrate, il comportamento del server, il buffering del lettore e le prestazioni di decodifica del dispositivo.
La compatibilità mobile dipende da molto più dell'estensione del file: sono importanti la decodifica hardware, il profilo e il livello del codec, la profondità in bit, il sottocampionamento della crominanza, la risoluzione, la frequenza dei fotogrammi e il bitrate di picco. Un video visualizzato con una larghezza di 390 pixel CSS può occupare molti più pixel fisici sullo schermo ad alta densità di uno smartphone. Di conseguenza, esaminare un fotogramma ridotto a 390 pixel di larghezza non equivale necessariamente a guardare il video originale su quel telefono. È necessario provare la riproduzione su dispositivi reali e in condizioni realistiche.
Il CRF controlla la qualità, non impone un limite massimo preciso al bitrate. Anche un video complesso con dimensioni complessive relativamente contenute può presentare picchi di bitrate impegnativi. Se una riproduzione affidabile su connessioni particolarmente lente è indispensabile, considerate vincoli espliciti sul bitrate o sul VBV, limiti adeguati alla risoluzione e test con condizioni di rete realistiche.
Il principio fondamentale è semplice: ottimizzate per l'esperienza di visione prevista, non per un obiettivo astratto di qualità massima.
6. Capire il CRF di x264: valori più bassi per la qualità, più alti per file piccoli
Dopo aver scelto H.264, la sfida successiva consiste nel decidere quanto comprimere il video.
In x264, il Constant Rate Factor, o CRF, regola il compromesso tra conservazione dei dettagli visivi e dimensioni del file.
Un CRF più basso produce generalmente file più grandi e di qualità superiore. Un CRF più alto produce generalmente file più piccoli, con una maggiore perdita dovuta alla compressione.
Il CRF non stabilisce un bitrate o una dimensione finale esatti. L'encoder distribuisce i bit in base al materiale sorgente, quindi una scena semplice e una ricca di dettagli possono produrre file di dimensioni molto diverse con lo stesso CRF.
Il CRF non determina neppure la compatibilità fondamentale con i decoder. Due video H.264 correttamente codificati con CRF 22 e CRF 30 possono avere lo stesso codec, profilo, livello, formato dei pixel, dimensioni e frequenza dei fotogrammi.
La differenza riguarda soprattutto la qualità della compressione e le caratteristiche del bitrate.
È importante ricordare che i valori di CRF non sono confrontabili direttamente tra implementazioni di codec differenti. Un CRF di 30 in x264 non corrisponde alla stessa qualità visiva di un CRF di 30 in un encoder AV1.
7. Il mio esperimento reale di compressione: da CRF 22 a 32
Volevo capire fino a che punto potessi comprimere un video prima che la differenza diventasse rilevante durante la normale riproduzione.
Ho utilizzato un breve video già compresso e ho generato versioni H.264 da confrontare con CRF 22, 24, 26, 28, 29, 30, 31 e 32.
Ho mantenuto invariati i parametri principali del video: risoluzione, frequenza dei fotogrammi, durata e numero di fotogrammi. Anche le impostazioni dell'encoder erano costanti, in modo da poter valutare l'effetto della sola variazione del CRF.
I risultati hanno mostrato differenze notevoli nelle dimensioni dei file.
| CRF | Dimensioni approssimative rispetto all'originale | Significato |
|---|---|---|
| 22 | 63% | Compressione più prudente e migliore conservazione dei dettagli |
| 24 | 49% | File più piccolo con una modesta perdita aggiuntiva di qualità |
| 26 | 38% | Ulteriore risparmio mantenendo molti dettagli |
| 28 | 30% | File compatto con una somiglianza alla sorgente relativamente elevata |
| 29 | 26% | Compressione più aggressiva |
| 30 | 23% | Il compromesso che ho preferito per il contenuto provato |
| 31 | 21% | Ulteriore risparmio con una minore fedeltà alla sorgente |
| 32 | 19% | File più piccolo della prova e maggiore perdita misurata di qualità |
Queste percentuali si riferiscono al video sorgente provato e non devono essere interpretate come risparmi tipici per qualsiasi video. I valori della tabella sono arrotondati separatamente: per calcolare risparmi relativi precisi bisogna usare le dimensioni effettive dei file, non dividere le percentuali arrotondate.
Il risultato più sorprendente è stato che durante la riproduzione normale non notavo differenze visive significative tra CRF 22 e CRF 30, nemmeno su un grande monitor da computer.
Ho esaminato anche versioni compresse più aggressivamente, compresa quella a CRF 32, senza rilevare differenze importanti durante la normale riproduzione di quello specifico filmato.
Era un'osservazione importante, perché gli stessi video erano destinati principalmente a schermi mobili più piccoli. Se il calo di qualità non disturbava la visione sul monitor del computer, avevo pochi motivi per accettare un aumento considerevole delle dimensioni in cambio di dettagli aggiuntivi che non miglioravano l'esperienza di visione prevista.
Si trattava però di un'osservazione soggettiva relativa a un particolare tipo di sorgente. Non dimostra che tutti gli utenti, gli smartphone o i video si comportino allo stesso modo. Gli schermi mobili ad alta densità e le distanze ravvicinate possono comunque mettere in evidenza artefatti, specialmente nei dettagli fini o nelle sfumature.
8. Le misurazioni oggettive hanno confermato una perdita reale di qualità
Non vedere differenze durante la riproduzione non significa che due video siano matematicamente identici.
Ho confrontato anche i risultati codificati usando misure oggettive della qualità dell'immagine. Con l'aumento del CRF, la somiglianza rispetto alla sorgente diminuiva.
Per un confronto con ridimensionamento uniforme, concepito per approssimare uno schermo mobile ad alta densità, i valori SSIM rappresentativi erano:
| CRF | SSIM approssimativo | Dimensioni rispetto a CRF 28 |
|---|---|---|
| 22 | 0.9934 | 2.13× |
| 28 | 0.9869 | 1.00× |
| 30 | 0.9837 | 0.79× |
| 32 | 0.9795 | 0.63× |
La tendenza è chiara: una compressione maggiore riduceva la fedeltà misurata del video codificato. Un esame ravvicinato mostrava anche lievi differenze nelle linee sottili e nelle texture.
Eppure, per il video testato, l'esperienza di visione normale rimaneva molto simile. È proprio per questo che misure oggettive e valutazione soggettiva dovrebbero essere utilizzate insieme.
SSIM misura la somiglianza delle immagini, non l'intera esperienza visiva umana. Non riesce a rappresentare completamente gli artefatti temporali, la nitidezza percepita, il comportamento del movimento o l'importanza soggettiva dei singoli dettagli.
VMAF è un'altra metrica utile della qualità percettiva. Netflix ha pubblicato i modelli VMAF v1 nel giugno 2026, tra cui un modello studiato per condizioni di visione su telefono. Questi modelli riconoscono esplicitamente che la qualità percepita dipende in parte dalle dimensioni dello schermo e dalla distanza relativa di visione.
Un campione codificato con impostazioni prudenti nell'indagine aveva un VMAF medio riportato di circa 95, ma non disponevo di una serie VMAF coerente per tutte le impostazioni CRF più aggressive. Per questo non ho utilizzato VMAF per sostenere che CRF 30 o 32 raggiungessero una soglia universale di qualità.
La conclusione pratica era più circoscritta: il breve video testato tollerava estremamente bene una compressione H.264 aggressiva durante la riproduzione normale.
9. Perché ho scelto CRF 30 per i video brevi su smartphone
Dopo aver confrontato i file, ho scelto CRF 30 per video brevi simili, guardati principalmente su dispositivi mobili.
Il ragionamento era semplice:
- I video erano brevi e non miravano a offrire una qualità d'immagine cinematografica.
- Il caricamento rapido e download più piccoli erano importanti.
- Non vedevo differenze significative tra CRF 22 e 30 su un grande monitor da computer.
- CRF 30 produceva file molto più piccoli rispetto alle impostazioni prudenti.
- CRF 32 era ancora visivamente accettabile nel campione testato, ma mi dava meno fiducia per materiali più complessi.
Rispetto a CRF 28, CRF 30 ha ridotto le dimensioni del risultato testato di circa il 21%. Rispetto a CRF 22, la riduzione superava il 60%.
Per brevi video mobili nei quali si cerca un'immagine piacevole, un caricamento rapido e un consumo ragionevole di banda, era un compromesso vantaggioso.
Ma la condizione è fondamentale: ho scelto 30 in base all'uso effettivo e ai risultati del materiale provato, non perché 30 sia intrinsecamente il miglior CRF per gli smartphone.
Un dispositivo mobile non richiede CRF 30: può riprodurre perfettamente anche video codificati con una fedeltà molto maggiore. CRF 30 è una scelta deliberata di sacrificare parte della fedeltà alla sorgente in cambio di file più piccoli quando questo compromesso è accettabile.
Prima di applicarlo a una raccolta con contenuti molto diversi, proverei più filmati rappresentativi, comprese scene con movimenti complessi, ambienti scuri, sfumature, testo e texture fini.
10. Perché non consiglio CRF 30 per film e video di alta qualità
Questo è il limite più importante dell'esperimento.
Non applicate alla cieca il mio risultato con CRF 30 a lungometraggi, contenuti video di alto livello, riprese professionali o filmati destinati ai grandi schermi.
Questi contenuti possono includere sfumature delicate, grana cinematografica, scene con poca luce, movimenti complessi, superfici ricche di texture fini e colori sottoposti a una correzione accurata. Conservare tali dettagli può essere più importante del risparmio di una quantità relativamente modesta di banda.
Per i normali video 1080p di alta qualità, inizierei da un'impostazione x264 molto più prudente, intorno a CRF 20, valutando poi valori sia superiori sia inferiori in base al materiale.
Quando la fedeltà visiva è importante, un intervallo iniziale pratico potrebbe essere CRF 18–22, anche se il valore appropriato può trovarsi fuori da quell'intervallo a seconda della risoluzione, del contenuto e dei requisiti.
Questo suggerimento è coerente con le indicazioni di codifica comunemente pubblicate. Per esempio, la documentazione di HandBrake sulla qualità raccomanda valori approssimativi di RF 20–24 per molti impieghi di x264 a 1080p.
Non ho svolto la stessa indagine controllata su lungometraggi o filmati cinematografici di alta qualità. Non posso quindi affermare che CRF 20 sia universalmente ottimale, che CRF 22 sia sempre sufficiente o che un determinato film risulterebbe necessariamente inaccettabile con CRF 30.
Il metodo corretto consiste nel selezionare scene rappresentative, codificarle a diversi livelli di qualità, confrontarle sullo schermo previsto e stabilire il punto in cui un'ulteriore compressione diventa visibilmente dannosa.
Se il video sarà archiviato, montato nuovamente o utilizzato come sorgente per codifiche future, è bene conservare un master di alta qualità separato dalla versione compressa destinata alla distribuzione.
11. Perché ho usato il preset veryslow di x264
Il CRF controlla un aspetto della qualità di compressione, mentre il preset x264 determina quanto lavoro l'encoder dedica alla ricerca delle scelte di codifica più efficienti.
x264 offre preset da molto veloci a molto lenti. In generale, quelli più lenti utilizzano più tempo della CPU e possono ottenere una compressione più efficiente a parità di qualità visiva.
Ho confrontato i preset medium e veryslow sulla stessa sorgente. Con l'impostazione di qualità provata, veryslow produceva un file più piccolo.
Quando un video viene codificato offline una sola volta e riutilizzato molte volte, il tempo di elaborazione aggiuntivo può valerne la pena.
Per questo ho scelto -preset veryslow.
Non è però la scelta migliore in assoluto. Se i video devono essere elaborati immediatamente, se le risorse CPU sono costose o se bisogna smaltire un arretrato enorme, slow o medium possono offrire un equilibrio operativo migliore.
Il preset modifica soprattutto la complessità della codifica e l'efficienza di compressione. Non trasforma H.264 in un altro codec né rende il file risultante intrinsecamente incompatibile con i dispositivi mobili.
12. Per i video anime utilizzo il parametro animation di x264
Quando la sorgente contiene animazione disegnata o immagini in stile anime, utilizzo -tune animation con x264.
Si tratta di un'impostazione distinta dal CRF. Un parametro di ottimizzazione modifica determinate decisioni dell'encoder per adattarle a particolari caratteristiche visive. Il parametro animation è pensato per materiali con contorni disegnati, aree dai colori uniformi e movimenti stilizzati.
Di conseguenza, queste sono le mie preferenze:
- Anime o video di animazione disegnata:
-preset veryslow -tune animation. - Normali riprese dal vivo: non abilitare automaticamente il parametro animation; partire dalle impostazioni predefinite dell'encoder oppure valutare separatamente un'ottimizzazione adeguata.
È importante non fraintendere l'effetto di questa impostazione. -tune animation non garantisce né una qualità visibilmente migliore né file più piccoli. Cambia il comportamento dell'encoder e il risultato dipende dal materiale.
Ho effettuato un confronto separato a CRF fisso utilizzando il parametro animation. In quel particolare confronto, abilitarlo ha prodotto un file più grande di circa il 6% e ha migliorato leggermente la somiglianza dell'immagine misurata. La differenza visiva era piccola.
Il confronto principale delle dimensioni tra CRF 22 e 32 è stato eseguito senza il parametro animation. Non si deve quindi presumere che dimensioni esatte e rapporti di compressione di quell'esperimento rimangano identici quando si attiva -tune animation.
Nonostante ciò, per i filmati anime preferisco usare l'ottimizzazione specifica per l'animazione e valutarne dimensioni e qualità all'interno del profilo di codifica di quel contenuto.
Le ottimizzazioni dell'encoder vanno considerate adattamenti dipendenti dal contenuto, non miglioramenti universali della qualità.
13. Le mie impostazioni FFmpeg consigliate per brevi video anime su smartphone
Per un normale video anime SDR che richiede effettivamente una transcodifica, questo comando rappresenta il profilo da cui partirei:
ffmpeg -i input.mp4 \
-map 0:v:0 -map '0:a:0?' \
-c:v libx264 \
-preset veryslow \
-tune animation \
-crf 30 \
-profile:v high \
-pix_fmt yuv420p \
-c:a aac -b:a 128k \
-movflags +faststart \
output.mp4Questo comando rende esplicite le scelte principali:
-c:v libx264utilizza l'encoder software H.264.-preset veryslowprivilegia l'efficienza di compressione rispetto alla velocità di codifica.-tune animationabilita gli adattamenti dell'encoder pensati per l'animazione.-crf 30applica il valore aggressivo di qualità costante scelto per questo tipo di video breve.-profile:v highseleziona un profilo H.264 comunemente supportato dai dispositivi moderni.-pix_fmt yuv420pproduce video a 8 bit con sottocampionamento 4:2:0.-map 0:v:0seleziona il primo flusso video.-map '0:a:0?'seleziona facoltativamente il primo flusso audio.-c:a aac -b:a 128kcodifica l'audio in AAC tradizionale, quando presente.-movflags +faststartsposta i metadati di inizializzazione MP4 verso l'inizio del file.
Questo è un esempio, non un comando universale per ogni file in ingresso. Le caratteristiche esatte del video sorgente potrebbero richiedere ulteriori interventi.
In particolare, non bisogna convertire alla cieca materiale HDR o a 10 bit in SDR a 8 bit senza un'adeguata gestione del colore: potrebbero risultarne colori errati, perdita di dettagli nelle alte luci o bande visibili nelle sfumature. Richiedono attenzione anche i metadati di rotazione, le frequenze dei fotogrammi variabili, i rapporti d'aspetto dei pixel, le sorgenti interlacciate, le configurazioni audio insolite e i limiti di risoluzione incompatibili.
Quando la frequenza dei fotogrammi e le dimensioni della sorgente sono già adeguate, conservarle facilita generalmente i confronti ed evita modifiche inutili alla scala o al movimento. Non imponete una frequenza costante alle sorgenti a frequenza variabile se non è necessario: la conversione può duplicare o eliminare fotogrammi. Se ridimensionate il video, mantenete il rapporto d'aspetto di visualizzazione e assicuratevi che le dimensioni siano compatibili con il formato di pixel 4:2:0 scelto. Risoluzioni, frequenze dei fotogrammi o livelli H.264 molto elevati possono superare i limiti di decodifica dei dispositivi più vecchi, quindi talvolta la compatibilità richiede di ridurre intenzionalmente la risoluzione o la frequenza dei fotogrammi.
14. Un punto di partenza FFmpeg più prudente per video di alta qualità
Se la fedeltà del video conta molto più delle dimensioni del file, iniziate con un CRF più basso e valutate il risultato.
Per esempio, il comando seguente è una base ragionevole per effettuare prove con normali riprese dal vivo in SDR:
ffmpeg -i input.mp4 \
-map 0:v:0 -map '0:a:0?' \
-c:v libx264 \
-preset slow \
-crf 20 \
-profile:v high \
-pix_fmt yuv420p \
-c:a aac -b:a 192k \
-movflags +faststart \
output.mp4Il preset slow di questo esempio rappresenta un pratico punto di partenza per usi generali, non un'affermazione che sia superiore a veryslow. Anche veryslow sarebbe ragionevole se il tempo aggiuntivo di codifica fosse accettabile.
Questo profilo di alta qualità è una raccomandazione da verificare con delle prove, non una configurazione dimostrata dal mio esperimento sui video brevi.
Per contenuti di alto livello, provate valori CRF vicini a 18, 20 e 22, poi scegliete in base ai risultati visibili. Grana o movimenti difficili possono richiedere impostazioni differenti, mentre i master di archivio potrebbero richiedere una compressione molto meno aggressiva.
15. Non ricodificate un video senza motivo
La compressione video con perdita di qualità ha un costo. Ricodificare un file già compresso può introdurre ulteriori artefatti, anche quando il nuovo video sembra simile alla sorgente.
Prima di effettuare una transcodifica, chiedetevi se il file originale soddisfa già i requisiti di compatibilità, dimensioni e qualità.
Se il file contiene già video H.264 compatibile e audio AAC e non serve alcuna trasformazione visiva, copiare i flussi può essere meglio di un'altra codifica con perdita.
ffmpeg -i input.mp4 \
-map 0:v:0 -map '0:a:0?' \
-c copy \
-movflags +faststart \
output.mp4Questa operazione copia i flussi compressi senza codificarli di nuovo. Può modificare l'organizzazione del contenitore evitando un'ulteriore generazione di perdite dovute alla compressione video.
Normalmente non produrrà le stesse riduzioni di dimensione di una nuova codifica a qualità inferiore.
Se il video che avete è già compatto, compatibile e visivamente soddisfacente, conservarlo potrebbe essere la migliore ottimizzazione possibile.
16. Verificate i video codificati, invece di fidarvi solo delle dimensioni
Un codice di uscita di FFmpeg che indica il successo non dimostra automaticamente che il video soddisfi tutti i requisiti.
Iniziate esaminando i flussi di uscita con FFprobe:
ffprobe -v error \
-show_entries stream=codec_name,profile,pix_fmt,width,height,avg_frame_rate,nb_frames:format=duration,size \
-of json output.mp4Verificate il codec, il formato dei pixel, le dimensioni, la frequenza dei fotogrammi, la durata e i flussi audio.
Successivamente, decodificate l'intero file di uscita per rilevare alcuni tipi di corruzione o errori di decodifica:
ffmpeg -v error -xerror -i output.mp4 -f null -Negli esperimenti di compressione, confrontate i risultati prodotti dalla stessa sorgente. Mantenete costanti le variabili importanti e modificate un solo parametro principale per volta.
Guardate il video in movimento, esaminate i dettagli fini e fate attenzione alle sfumature, alle aree scure, agli oggetti in movimento e al testo.
Se possibile, affiancate ai confronti visivi metriche oggettive come SSIM, PSNR o VMAF. Non interpretate un singolo punteggio elevato come prova che tutti gli artefatti siano invisibili.
Infine, provate il video su dispositivi rappresentativi e verificatene l'apertura anche dopo il download. Le informazioni sul supporto dei browser sono utili, ma le prove di riproduzione reali sono particolarmente importanti quando la compatibilità è una priorità.
17. Assicuratevi che i file MP4 vengano distribuiti correttamente
Buone impostazioni di codifica non possono compensare una distribuzione web inefficiente.
Per la normale riproduzione progressiva di un MP4, configurate correttamente l'intestazione Content-Type: video/mp4 e supportate le richieste HTTP per intervalli di byte quando sono necessari il recupero parziale e la ricerca di un punto nel video.
L'opzione FFmpeg +faststart sposta le informazioni di inizializzazione del contenitore MP4 verso l'inizio di un file convenzionale. Questo favorisce il caricamento progressivo, ma non migliora la qualità visiva né riduce il bitrate.
Un semplice elemento video HTML può distribuire un file MP4 H.264:
<video controls playsinline preload="metadata">
<source src="/media/video.mp4" type="video/mp4">
</video>L'attributo preload è un suggerimento per il browser, non un limite rigoroso ai download. Le regole dei browser per la riproduzione automatica possono inoltre richiedere video muti o privi di audio.
Se una pagina contiene più video, evitate di scaricarli tutti subito. Caricarli soltanto quando servono può ridurre il consumo di dati mobili e migliorare la reattività percepita.
Per i brevi filmati mobili, ottimizzare il momento in cui vengono avviati i download può essere importante quanto ridurre le dimensioni del video codificato.
18. Quale formato e quale qualità video scegliere?
La risposta giusta dipende da ciò che volete ottimizzare.
| Obiettivo | Punto di partenza consigliato |
|---|---|
| Un solo video ampiamente compatibile sul web e dopo il download | MP4 + H.264 + AAC, se è presente l'audio |
| Distribuzione sui browser moderni con più formati disponibili | AV1 o VP9, con H.264 come alternativa |
| Massima compressione sui dispositivi supportati | Valutare AV1 |
| Ambiente di riproduzione controllato e compatibile con HEVC | Considerare MP4 + HEVC |
| Brevi video mobili in cui contano soprattutto le dimensioni | Considerare x264 CRF 30 dopo prove rappresentative |
| Anime o animazione disegnata | Valutare x264 con -tune animation |
| Film di alta qualità o video di livello superiore | Partire da un CRF più prudente, vicino a 20, e fare delle prove |
| Codifica offline in cui il tempo CPU è meno importante | Considerare x264 slow o veryslow |
| Elaborazione rapida con risorse CPU limitate | Considerare x264 medium o slow |
| Video esistente che soddisfa già i requisiti | Conservarlo o cambiarne il contenitore senza ricodifica |
| Archiviazione o montaggio futuro | Conservare un master di alta qualità separato dai file di distribuzione |
19. La mia decisione finale e ciò che l'esperimento ha realmente dimostrato
Dopo aver analizzato formati video, compatibilità, efficienza della codifica e risultati concreti della compressione, ho scelto un profilo di distribuzione pratico per brevi video destinati soprattutto ai dispositivi mobili.
Il formato scelto è stato MP4 con H.264, perché una compatibilità prevedibile con browser, telefoni, download e applicazioni esterne era più importante che ottenere il file più piccolo possibile con un codec più recente.
L'encoder scelto è stato libx264 con il preset veryslow, perché potevo codificare il video offline e il tempo di elaborazione aggiuntivo era accettabile.
Per i video anime utilizzo il parametro animation, sapendo che modifica il comportamento dell'encoder senza garantire file più piccoli o risultati visivi universalmente migliori.
Per i brevi video destinati ai dispositivi mobili ho scelto CRF 30, perché il mio confronto mostrava una riduzione considerevole delle dimensioni senza differenze visive significative nella riproduzione normale, anche rispetto alla visione su un grande monitor da computer.
Questo risultato non significa che CRF 30 sia ideale per i film o per le riprese di alta qualità. Quando i dettagli fini, le sfumature, la grana e la fedeltà complessiva sono più importanti, inizierei a provare valori vicini a CRF 20 o altre impostazioni adeguatamente prudenti. Non ho svolto uno studio controllato analogo su filmati cinematografici, quindi non presento quel numero come un valore ottimale dimostrato sperimentalmente.
La conclusione più importante è che non esiste un codec, un formato o un valore CRF universalmente migliore per tutti i video.
Se la priorità è la massima compatibilità e volete un solo file, MP4/H.264 è un ottimo punto di partenza. Se potete offrire formati alternativi e desiderate una compressione migliore, valutate VP9 e AV1. Se codificate video brevi guardati soprattutto sui telefoni, verificate se un CRF più alto consenta di ottenere file sufficientemente piccoli senza compromettere l'esperienza prevista. Per i film o le riprese di alta qualità, utilizzate impostazioni più prudenti e verificatele con attenzione.
Definite prima i requisiti di riproduzione, scegliete poi il codec e solo alla fine la qualità di compressione. Testate il risultato sui dispositivi e nelle condizioni che contano davvero. È un approccio più affidabile che adottare ciecamente un codec o un valore CRF solo perché è più recente, più efficiente o consigliato spesso.