|
|
inviato il 30 Dicembre 2025 ore 13:59
Ciao a tutti,
riprendo un tema iniziato in un altro thread, che può essere di interesse comune.
H265
Per oltre 20 anni per la transcodifica H264 AVC ho utilizzato Megui, una interfaccia grafica che viene sempre aggiornata per sfruttare i codec allo stato dell'arte gratuiti (x264, x265, ffmpeg, etc.). E' però una app per power user, anche se da qualche anno è diventata meno ostica con un wizard chiamato one-click encoder.
Adesso sto sperimentando un'altra ottima interfaccia gratuita, shutter encoder, che sfrutta ffmpeg per la codifica h264,h265 e h266 (si esiste ma per ora poco utilizzato), e supporta gli encoder hardware più noti: NVENC, dovrebbe anche sfruttare AMD VCN e Intel QuickSync.
Come benchmark sono partito da un suggestivo filmato che ho girato con una Z6 nel trenino delle grotte di Postumia, della durata di 7.41m, in 3840x2160 29.97fps H264 AVC. Un filmato che non condividerò, essendo personale, ma che costituisce un buon banco di prova, con immagini in movimento e zone scure. Il bitrate è elevatissimo anche per un 4K, 125mbit/s, ed il filmato occupa circa 7GB.
Ho sfruttato tre miei PC con:
1) Core Ultra 7 265KF con Nvidia RTX4070 e 2x24GB DDR5 CUDIMM @ 8400MHz (124GB/s di banda), Windows 11 Pro
2) Core Ultra 7 265KFcon Nvidia RTX2080 Super e 2x24GB DDR5 UDIMM @ 8000MHz (120GB/s di banda), Windows 11 Pro
3) DUAL CPU Xeon E5-2696V4 con Quadro M4000 e 8x16GB DDR4 RDIMM ECC @ 2133MHz (configurazione a 8 canali complessivi, 120GB/s di banda), Windows Server 2025
Ho provato a transcodificarlo in H265 HEVC per ottenere un output di circa 800MB, circa nove volte più piccolo, con un ragionevole bitrate di 14-15mbit/s e un fattore Bits/(Pixel*Frame) di 0.06. Ho utilizzato la modalità constant quality, con valori CRF di 22 o 23 , tranne che per le transcodifiche con la quadro in cui ho dovuto utilizzare 27 perchè genera file più grandi a parità di CR. Per shutter encoder con NVENC, ho utilizzato la modalità standard e quella Max Quality. E' inutilizzabile, perchè troppo lenta, da CPU.
Di seguito i tempi di trascodifica, cominciando dalle modalità software
Core Ultra 7 265K/KF - Megui: 646s 21.4fps
Dual Xeon E5-2646V4 - Megui: 1073s 12.88fps
Core Ultra 7 265K/KF - Shutter Encoder: 567s 24.38fps
Dual Xeon E5-2646V4 - Shutter Encoder: 1002s 13.8fps
Megui utilizza x265, mentre shutter encoder ffmpeg con integrazione di libavc, etc. Megui non supporta encoding harware. Per quanto riguarda i tempi, megui è più lento perchè ho dovuto utilizzare la modalità one-click-encoder, che converte il sorgente da .mp4 a .mkv, per poi estrarre ed indicizzare i flussi, rilevare eventuali interlacciamenti, e solo dopo queste operazioni comincia la codifica. Questo implica un ritardo di circa 1m 15s.
Inoltre, mentre i 20 core dei 265K/KF sono sfruttati al 100%, entrambi i codificatori faticano ad indirizzare gli 88 thread dei 44 core dei due xeon, con il risultato che le performance con il server sono inferiori di circa il 40-45%, laddove con altri software come cinebench pagano circa il 7%. Questa situazione sarebbe stata ancora più evidente se invece di utilizzare CQ avessi utilizzato VBR, che per motivi che non comprendo è ancora meno efficiente ad indirizzare tanti core negli xeon.
Vediamo alle codifiche hardware NVENC, tutte con shutter encoder:
RTX4070 NVENC: 101s 136.87fps
RTX4070 NVENC MaxQ: 284s 48.68fps
RTX2080 Super NVENC: 121s 114.25fps
RTX2080 Super NVENC MaxQ: 326s 42.4fps
Quadro M4000 NVENC: 394s 35.09fps
Quadro M4000 NVENC MaxQ: 557s 24.82fps
Il risultato della Quadro, soprattutto in MaxQ, è sorprendente se confrontato con le ben più prestanti RTX. C'è da dire che questa GPU utilizza una versione precedente di NVENC, come conseguenza a parità QF il file risulta essere grande il doppio.
L'utente Fraever, che ringrazio, mi ha suggerito una app che esegue misure metriche per valutare la fedeltà dei video compressi rispetto all'originale. Di seguito i risultati:
Precedentemente ho avuto problemi con Megui, perchè non settava correttamente i metadati dello spazio colore, ho corretto ped ora la metrica è identica a shutter encoder CPU, e tale è anche l'output
Ho incluso, solo per curiosità, megui con x265 e settaggio slower, ai fini pratici inutilizzabile perchè troppo lento (circa 2h per 7 minuti di filmato). Come potete vedere, però la lentezza paga, tutte e tre le metriche sono le migliori.
A parte questo, modalità software di shutter encoder e megui è quella che da i migliori risultati su tutte le metriche, risultando superiore a quelle hardware NVENC Sorprendentemente, la Quadro sembra comportarsi meglio delle RTX.
Il tool permette anche di estrarre i 5 peggiori frame per ogni metrica, e di confrontarli con quello originale di riferimento. Li trovate qua.
www.dropbox.com/scl/fi/zjwgm1skf2uebh901swhv/Bad-Frames.7z?rlkey=qrj25
Qui invece trovate un confronto in un frame abbastanza significativo
slow.pics/c/EZDm5bwl
AV1
Ho provato il codec AV1, più recente di HVEC/H265
Innanzitutto una precisazione sulla modalità Max Quality di shutter encoder. Essa sceglie, per ogni encoder, il preset a qualità più elevata, risultando inutilizzabile perchè troppo lenta con quelli software. Come vedremo più avanti, invece è consigliata con quelli hardware.
Nel caso di H265 NVENC, flaggandola si aggiunge la seguente opzione al comando:
-preset p7
Nelle opzioni avanzate, c'è un altra opzione, chiamata "force preset". Se scelgo veryslow, con NVENC viene sempre impostato p7.
Sulla documentazione Nvidia
docs.nvidia.com/video-technologies/video-codec-sdk/13.0/nvenc-applicat
p1 - p7 sono i preset di qualità dell'encoder hardware
Nel caso di AV1, essa imposta:
-preset p7 -tune uhq
Tune uhq è un'opzione specifica di AV1 per migliorare la qualità
In questo caso però l'opzione force preset mostra un numero che va da 0 a 13. Questi sono i preset dell'encoder AV1 software. Scegliendo 1 con NVENC, viene aggiunto:
-preset 1
Sulla documentazione Nvidia non c'è riportato nulla a riguardo di questa sintassi. Con tale valore i tempi di elaborazione e la qualità dell'output sono intermedi fra default e Max Quality. L'impostazione 0 invece sembra essere ignorata.
Fatta questa premessa, ho eseguito alcune conversioni con AV1. Nel caso di quella software, ho scelto il preset 4, un valore che permette tempi ragionevoli sul mio sistema. Ho poi scelto la modalità CQ con valori di CRF per avere un bitrate di circa 14-15Mbit/s. Ho scoperto che il valore di bitrate non dipende solo da CRF, ma dal preset: a parità di constant rate factor, un preset più lento ma di qualità più elevata genera un output con un bitrate inferiore. Probabilmente è così anche in H265, non ho verificato
Il problema è che con NVENC, anche scegliendo CRF altissimi, l'output risulta avere un bitrate più elevato. Ho dovuto usare quindi la modalità VBR. Come vedremo più avanti, ciò è dovuto al fatto che NVENC AV1 è scadente.
Infine, solo la serie RTX4000 e 5000 supporta l'encoding hardware AV1.
I tempi di decodifica sono risultati:
RTX 4070 NVENC: 112s - 123.43fps
RTX 4070 NVENC MaxQ: 563s - 23.52fps
Core Ultra 7 265K/KF: 560s - 24.69fps
Dual Xeon E5-2646V4: 1297s - 10.66fps
A parte NVENC MaxQ, sono allineati a quelli di H265. C'e da dire che cambiando il preset d1 AV1 da 4 (di default se non viene specificato è 8, molto veloce), si può scegliere in maniera più fine tempi e qualità, laddove con H265 ogni scatto ha un impatto pesantissimo sul tempo di decoding. Il preset MaxQ di NVENC risulta più lento del corrispondente H265.
Veniamo ora alle metriche
Per motivi a me sconosciuti, le metriche in AV1 risultano sistematicamente migliori di quelle in H265, laddove i miei occhi mi dicono che non è così. Anzi in questi giorni ho compresso un rip di un Blu Ray UHD HDR10, ed alla fine ho preferito H265. Direi che questi confronti di metrica vadano presi con le pinze se si tratta di codec diversi.
E' evidente come, facendo riferimento sopratutto a VMAF, NVENC sia inferiore.
Qui trovate un confronto fra: AV1 CPU preset 4, H265 CPU preset medium, AV1 NVENC MaxQ (preset p7, tune uhq), H265 NVENC MaxQ (preset p7)
slow.pics/c/584oBQqu
Ai miei occhi, le due modalità CPU sono indistinguibili, NVENC H265 è leggermente inferiore, mentre NVENC AV1 è decisamente peggio, ed è pure più lento di H265, per cui lo eviterei.
H266
Ho provato anche questo. I tempi di conversione sono molto lenti, siamo intorno a 5fps, e non c'è supporto hardware. La compatibilità è limitata, solo potplayer è riuscito a leggere l'output.. E' ancora acerbo
CONCLUSIONI E SUGGERIMENTI
Utilizzate H265 o AV1, sono encoder moderni diffusi e ben supportati, soprattutto il primo. Per la massima compatibilità, soprattutto con i player integrati nelle TV di 10-15 anni fa, scegliete H264. Direi di lasciare perdere i vecchi codec mpeg4 come Divx, Xvid, VMV, e quelli ancora più datati come mpeg, mpeg2, mjpeg.
Se non avete esigenze di controllo delle dimensioni dell'output, scegliete la modalità Constant Quality. E' più versatile quando si hanno sorgenti diverse per risoluzione, frame rate, spazio colore, ed inoltre ottimizza il bitrate anche in funzione della qualità di encoding. Se serve un controllo sul bitrate andate su VBR, a due passate se serve precisione assoluta. Come valore di Crf, partirei con 23.
Usate AV1 preset 4, H265 preset medium oppure H265 NVENC preset p7. Quale scegliere può dipendere anche dall'hardware, se avete CPU potenti e GPU scarse optate per la modalità software, e viceversa. Se entrambe sono veloci, può avere senso lanciare due encoding in contemporanea, uno da CPU e uno da GPU. Non ho fatto prove con Intel QuickSync e AMD VCN. Se volete una qualità migliore, dovete abbandonare NVENC ed utilizzare i preset 0-3 su AV1 oppure slow o slower su H265, entrambi in modalità software.
Controllate lo standard di codifica della sorgente in ingresso. I più comuni sono:
BT601 per SD segnali interlacciati o progressivi SD PAL o NTSC, compreso i VOB dei DVD
BT709 per HD
BT2020 per UHD
BT2020 con PQ o HLG per UHD HDR (è la codifica definita come BT2100, ma nei metadati trovete BT2020 + una delle due gamma HDR)
Controllate anche lo spazio colore (RGB o YUV/YCbCr), e la profondità (8-10-12 bit). Inoltre, queste codifiche hanno la possibilità di utilizzare un range limitato ( a 8 bit 15-235 per la luminanza, 15-240 per la crominanza) o full range(0-255).
Cercate di mantenere le impostazioni, oppure se volete di convertirle. State attenti anche ai metadati, spesso le GUI non cambiano la codifica del sorgente, ma non aggiungono o variano i metadati. Nel caso del blu ray UHD, a me al primo tentativo ha cambiato la profondità da 10 bit a 8bit. Questi tag, che rientrano nella categoria VUI (Video User Interface), possono essere ignorati dal player, ma se vengono utilizzati devono essere corretti. Eccezione per il tag del posizionamento del subsample chroma, che viene utilizzato solo se si fa una conversione di spazio colore. Non ho trovato un tool che permetta di modificarli, occorre rifare l'encoding.
Altro aspetto da tenere in conto. Lo standard HDR10 prevede che vengano aggiunti dei metadati nel flusso grezzo h265. Si può istruire x265 perchè lo faccia, aggiungendo le seguenti opzioni da CLI:
--video-signal-type-preset BT2100_PQ_YCC --master-display --master-display G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,100.0) --max-cll 1000,400 --profile main10
Il problema è NVENC non supporta la scrittura di questi metadati. La soluzione sarebbe di aggiungerli dopo, ma ho trovato una sola app in python per farlo, ma non è aggiornato e non funziona bene. In alternativa possono essere aggiunti nel container mkv. Anche se non ho trovato documentazione a riguardo, mi sembra che shutter encoder faccia così se usi NVENC.
Ho però trovato una GUI specializzata per i flussi HDR10 e HDR10+, che scrive tutti e metadati ed inoltre supporta una versione alternativa di NVENC che sembra più adatta per questi contenuti.
La app si chiama FastFlix. Attenzione che se avete attivo Smart App di windows 11 potreste essere costretti a disattivarla, peraltro per sempre, perchè la blocca.
Un altro aspetto da tenere conto è che per lo standard HDR10 occorre aggiungere dei metadati al flusso h265. E' possibile istruire x265 perchè lo faccia, le opzioni da CLI sono queste:
--video-signal-type-preset BT2100_PQ_YCC --master-display G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,100) --max-cll 1000,400 --profile main10
Il problema è che HVENC non li supporta. Shutter Encoder mi sembra che risolva aggiungendoli nel container mkv.
Sarebbe meglio aggiungerli direttamente al flusso, ma l'unica app che ho trovato allo scopo è datata e non funziona correttamente.
Ho scoperto però una GUI di ffmpeg specializzata nei contenuti HDR10 e HDR10+, che gestisce i metadati ed inoltre utilizza un alternativa NVENC a quella di ffmpeg, specializzata per i flussi HDR.
Si chiama FastFlix. E' possibile che dobbiate disattivare (per sempre, non è reversibile) smart app di windows 11 per avviarla.
WORK IN PROGRESS
|
|
|
inviato il 30 Dicembre 2025 ore 16:37
@Fraever c'è qualcosa che non torna nelle metriche, ho preso 3 screen di megui e CPU, e sono uguali bit a bit
Ho capito la stranezza: l'output di megui è identico a quello di shutter encoder, ma ancora lo spazio colore è diverso. Quando estraggo i frame con Ffmpeg si vede la differenza, ma poi Kmplayer utilizza lo stesso spazio e di screenshot sono identici.
C'è un'altra stranezza: ho provato a demuxare i flussi video, e rifare le metriche. L'estrazione dei bad frames funziona comunque, ma sbaglia l'indice del fotogramma nel nome. |
|
|
inviato il 31 Dicembre 2025 ore 13:06
Ho scoperto perchè la metrica era sballata con Megui, ho corretto e riaggiornato il primo post. |
|
|
inviato il 04 Gennaio 2026 ore 11:13
Ho aggiornato il post iniziale con la codifica AV1, suggerimenti e conclusioni |
|
|
inviato il 04 Gennaio 2026 ore 11:26
“ ontrollate lo standard di codifica della sorgente in ingresso. I più comuni sono:
BT605 per SD
BT709 per HD
BT2020 per UHD
BT2020 con PQ o HLG per UHD HDR (è la codifica definita come BT2100, ma nei metadati trovete BT2020 + una delle due gamma HDR) „
Occhio che per SDR si usa solo bt709 indipendentemente dalla risoluzione |
|
|
inviato il 04 Gennaio 2026 ore 11:38
“ Occhio che per SDR si usa solo bt709 indipendentemente dalla risoluzione „
Non sono troppo convinto, i VOB dei DVD sono in 601. Forse sono legati alla codifica mpeg2 |
|
|
inviato il 04 Gennaio 2026 ore 11:48
Cmq è difficile valutare diversi codec senza avere accesso al file originale. Sarebbe meglio se trovassimo un file a cui tutti possono accedere |
|
|
inviato il 04 Gennaio 2026 ore 11:52
Lo so, stavo pensando di fare un filmato di test con la Z6, codificarlo lossless ed uploadarlo.
Potrebbe andare bene anche quello che hai girato tu, ma servirebbe l'originale il 4K. |
|
|
inviato il 04 Gennaio 2026 ore 20:16
Ho dato un occhiata alla collezione ma sono quasi tutti 4128x2322, non mi sento di usarli per test a 3840x2160 visto che lo scaling non è proprio ideale. Magari vedo se riesco a registrare qualcosa a 8256x4644 così da avere un buon file 3840x2160 da utilizzare per fare prove |
|
|
inviato il 04 Gennaio 2026 ore 21:29
Ma perché quello strano formato su Z8 e Z9? |
|
|
inviato il 04 Gennaio 2026 ore 23:11
Non è uno strano formato, ma semplicemente la risoluzione nativa o dimezzata del sensore quando si registra in nraw (ticoraw) |
|
|
inviato il 05 Gennaio 2026 ore 9:04
OK, ma se è per fare test puoi tenere 4128x2322. Comunque un lanczos non credo abbia problemi a gestire un rescaling efficacemente, di solito si usa il bicubico.
Comunque trovo assurdo che per cambiare i metadati VUI occorra rifare l'encoding |
|
|
inviato il 05 Gennaio 2026 ore 11:49
Blade,
la macchina con doppio Xeon è una workstation HP? |
|
|
inviato il 05 Gennaio 2026 ore 12:16
No no, ho comprato una MB Machinist su aliexpress a 60€ |
Che cosa ne pensi di questo argomento?
Vuoi dire la tua? Per partecipare alla discussione iscriviti a JuzaPhoto, è semplice e gratuito!
Non solo: iscrivendoti potrai creare una tua pagina personale, pubblicare foto, ricevere commenti e sfruttare tutte le funzionalità di JuzaPhoto.
Con oltre 257000 iscritti, c'è spazio per tutti, dal principiante al professionista. |
Metti la tua pubblicità su JuzaPhoto (info) |
JuzaPhoto contiene link affiliati Amazon ed Ebay e riceve una commissione in caso di acquisto attraverso link affiliati.
