|
|
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, x265 ha un limite di 16 thread, con il risultato che il server è palesemente sottoutilizzato (le due CPU vanno al 30%). Questa situazione sarebbe stata ancora più evidente se invece di utilizzare CQ avessi utilizzato VBR, che per motivi che non comprendo è ancora meno efficiente.
Vediamo alle codifiche hardware NVENC, tutte con shutter encoder:
RTX4070 NVENC: 101s 136.87fps
RTX4070 NVENC MaxQ: 650s 21.27fps
RTX2080 Super NVENC: 121s 114.25fps
RTX2080 Super NVENC MaxQ: 731s 18.91fps
Quadro M4000 NVENC: 394s 35.09fps
Quadro M4000 NVENC MaxQ: 557s 24.82fps
Recentemente ho scoperto che per un baco di shutter encoder la modalità maxQ in H265 non impostava l'opzione -tune uhq, l'ho quindi aggiunta a mano. Inoltre in questo caso il container mp4 ha problemi, ho utilizzato mkv. La quadro invece non supporta -tune uhq, per questo il colo di fps a MaxQ è più contenuto. La quadro ha due encoder, ma per sfruttarli in parallelo occorre utilizzare un'altra gui, Fastflix.
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.
Le modalità hardware di default sono molto veloci, ma anche quelle che hanno le metriche peggiori. Quelle in UHQ sono paragonabili a quelle software di default, con VMAF comunque inferiore. Come da aspettativa, nella Quadro la differenza fra il preset di default e quello maxQ è più marginale, dato l'assenza del supporto a UHQ. Sorprendente il risultato in VMAF.
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 NVENC da Turing in poi per migliorare la qualità. Shutter encoder non imposta -tune uhq su HVEC perchè è bacato. Con Fastflix e Rigaya NVENC funziona.
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
Adesso che ho aggiornato la modalità NVENC con uhq, AV1 risulta 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 senza uhq)
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 o 5, H265 preset medium oppure H265 NVENC preset p7 e tune uhq. 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. A riguardo in questa immagine c'è la resa dei preset x265 in CQ:
Si vede come la differenza fra medium e slow sia netta, ma poi non serva utilizzare preset più lenti.
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 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.
Con l'ultima versione viene supportato anche la copia dei dati Dolby Vision, solo se si utilizza Rigaya NVENC encoder.
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.
*****PROVE DI CODIFICA 4K 60FPS, sorgente video di test da Nettlfix Open Source Content
Con l'aiuto di Fraever, ho fatto alcune prove di codifica con il seguente video test open source di netflix
download.opencontent.netflix.com.s3.amazonaws.com/Chimera/Chimera_DCI4
Ho impostato la codifica VBR a 20000Kb/s, ed utilizzato Fastflix con in modalità software oppure con Rigaya NVENC. Questa versione dell'encoder hardware permette anche di separare l'encoding in più flussi e parallelizzarli:
[IMG]https://github.com/rigaya/NVEnc/blob/master/data/nvencc_parallel_encode_20250320_en.png?raw=true[/IMG]
è utile in configurazioni multi-gpu oppure per quelle schede che hanno più di un encoder. Ho utilizzato la feature per la Quadro M4000 che ne ha due, di fatto dimezzando i tempi e raddoppiando i fps. Di seguito le prestazioni di codifica.
Da tenere presente che x265 è limitato a 16 thread, ed anche SVT-AV1 sembra avere tale limite
I test su Ryzen e RTX 5070 Ti sono stati condotti da Murphy, che ringrazio.
23.27fps CPU Core Ultra 265K H265 preset medium
19.98fps NVENC H265 RTX 4070 --preset p7 --tune uhq
25.67fps NVENC AV1 RTX 4070 --preset p7 --tune uhq
22.48fps CPU Core Ultra 265K AV1 preset 5
48.32fps NVENC H265 Quadro M4000 x2 --preset p7 (--tune uhq non disponibile)
53.1fps NVENC H265 RTX 5070 Ti x2 --preset p7 --tune uhq
65.6fps NVENCAV1 RTX 5070 Ti x2 --preset p7 --tune uhq - 2 pass encoding, solo la seconda passata
Sono abbastanza allineate, tranne per la Quadro che non supporta l'uhq, disponibile solo dalle GPU Turing. Quadro M4000 e RTX5070 Ti hanno due encoder e raddoppiano le performance.
Fraever ha utilizzato svt-hdr con i seguenti parametri
--preset 3 --crf 40 --tune 0 --enable-tf 0 --enable-restoration 0 --enable-cdef 0 --complex-hvs 1 --tx-bias 1 --ac-bias 4.00 --tile-columns 0 --tile-rows 0 --lookahead 120
Con una conversione molto lenta, ben sotto i 10fps. Ha inoltre codificato a 10 bit
Altre conversioni software, valide come benchmark di prestazioni:
10.22 fps CPU Xeon E5-2690 V4 H265 preset medium
12.95 fps CPU Xeon E5-2696 V4 x2 H265 preset medium
11fps CPU Xeon E5-2696 V4 x2 AV1 preset 5
13.35fps CPU Ryzen 5 7600x H265 preset medium
Qui le metriche. Ho usato come notazione la generazione dell'encoder (8 per la RTX4070, 5 per la Quadro), in quanto non varia fra schede della stessa serie.
Qui le metriche con RTX 5070 Ti (due encoder di generazione 9)
[IMG]https://postimg.cc/ph481fG3[/IMG]
AV1 risulta migliore in queste misure, vedremo se si confermerà anche negli screenshot.
Da notare che nella scena del bambino fra le fontanelle, piuttosto impegnativo per i dettagli in movimento, la codifica di Fraever con la metrica VMAF risulta nettamente migliore (è quella in blu)
La Quadro in questo caso si comporta decisamente peggio.
Mentre altrove è inferiore
Ipotizzo che questa discrepanza sia dovuta al fatto che ha utilizzato la codifica constant quality, che probabilmente ha sfruttato un bitrate superiore in quella scena, a scapito delle altre.
Ho anche calcolato le metriche SSIMULACRA2, Butteraugli e CVVDP per la codifica AV1 software.
“ SSIMULACRA2 Score Interpretation
90+ (Very High Quality): Visually lossless or nearly so, difficult to distinguish from the original.
70-90 (High Quality): Good quality with minimal, slightly annoying artifacts.
50-70 (Medium Quality): Noticeable but not overly distracting artifacts; a common range for quality/size tradeoffs.
Below 50 (Low Quality): Obvious and annoying distortions, like blockiness or banding.
Negative Scores: Extremely low quality, very strong distortion. „
SSIMU2 Result between .\Chimera_DCI4k5994p_HDR_P3PQ.mp4 and .\Chimera_DCI4k5994p_AV1_CPU.mp4
Computed 110935 frames at 60 fps
-----------SSIMULACRA2-----------
Average : 69.001573
Standard Deviation : 16.058778
Median : 70.378708
5th percentile : 37.675846
95th percentile : 97.125359
Minimum : -28.823952
Maximum : 99.907600
“ A Butteraugli score measures the perceived difference between two images, with lower scores being better, indicating less noticeable artifacts,
Score Interpretation Guidelines
0.0: Images are identical.
< 1.0: Imperceptible difference; excellent quality.
1.0: Considered a good/normal quality level.
1.0 - 1.6: Works as designed; a great value for compression.
1.6 - 2.1: Okayish; difference might be noticeable but not severe.
2.1+: Noticeable artifacts likely appear, especially in a flip test.
2.5+: Significant visible issues, beyond typical practical relevance. „
Butteraugli Result between .\Chimera_DCI4k5994p_HDR_P3PQ.mp4 and .\Chimera_DCI4k5994p_AV1_CPU.mp4
Computed 110935 frames at 26 fps
-------------2-Norm--------------
Average : 1.166669
Standard Deviation : 0.602001
Median : 1.207241
5th percentile : 0.018664
95th percentile : 2.197356
Minimum : 0.001238
Maximum : 5.134084
-------------3-Norm--------------
Average : 1.268339
Standard Deviation : 0.627278
Median : 1.290373
5th percentile : 0.041309
95th percentile : 2.360456
Minimum : 0.001440
Maximum : 5.594105
------------INF-Norm-------------
Average : 7.022492
Standard Deviation : 3.932461
Median : 6.423678
5th percentile : 0.723633
95th percentile : 13.641651
Minimum : 0.017417
Maximum : 39.526646
CVVDP Result between .\Chimera_DCI4k5994p_HDR_P3PQ.mp4 and .\Chimera_DCI4k5994p_AV1_CPU.mp4
Computed 110935 frames at 36 fps
----------------CVVDP---------------
Video Score: 9.7401
Risultato encoding di Fraever
SSIMULACRA AVG 66.0628
BUTTERAUGLI inf-norm 9.3517
CVVDP 9.728
Un primo comparison dove si può apprezzare come i diversi encoder gestiscono la grana
slow.pics/c/A8O8922L |
|
|
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 258000 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.
