|
|
inviato il 26 Dicembre 2025 ore 11:03
“ La storia dell'encoding NVENC più scarso di quello della CPU l'ho sempre sentita ma mai nessuno che portava evidenze.
L'unico thread dove ne abbiamo parlato sul forum aveva sbagliato la risoluzione di output e quindi risultava più scarso. „
Guarda, sto facendo dei test proprio ora, adesso ho il pranzo di Santo Stefano. Nei prossimi giorni pubblicherò i risultati.
Vi anticipo una sintesi: questi encoder hardware sono pensati per transcodificare al volo l'output per lo streaming. Sono poco configurabili, e sono impostati per dare un frame rate fisso, adattando la qualità in base alla potenza della scheda. Inoltre utilizzano algoritmi percettivi. Il risultato è che in alcuni casi durante la proiezione si percepisce il calo di qualità. Inoltre, se fai degli screenshot noterai che, rispetto all'encoding da CPU, tendono a perdere dettagli fini. Morale: se hai una CPU potente, e vuoi ridimensionare i tuoi video mantenendo la massima qualità possibile, sfrutta lei. |
|
|
inviato il 26 Dicembre 2025 ore 11:32
Le elaborazioni video che facevo erano miniclip per il microstock. I video in buona luce cambiava nulla ai miei occhi, i plugin di denoise usava l'accelerazione hw e la qualità percepita era uguale.
Quello che dici tu lo si può notare in scene con poca luce, ma se il problema non era evidente tanto da scartarmi il video per scarsa qualità manco perdevo tempo. Usato premiere e davinci e montato anche video di famiglia.
Cosa diversa se mi dici sono un cultore della massima qualità una cpu multicore é quella ci vuole.
|
|
|
inviato il 26 Dicembre 2025 ore 13:58
“ La storia dell'encoding NVENC più scarso di quello della CPU l'ho sempre sentita ma mai nessuno che portava evidenze. „
Murphy ti posso GARANTIRE che è un dato di fatto, tutti gli HW encoder fanno e sempre faranno cagare in termini di rapporto qualità/bitrate, stessa cosa vale per gli asic professionali come quelli prodotti da Alveo.
Del resto la velocità si paga a caro prezzo, come il triangolo esposizione-iso-diaframma stessa cosa vale per velocità-qualità-consumi.
discord.gg/vpmY3DGZ se chiedi qua dove ci sono professionisti che lavorano a fork di svtav1 e hanno lavorato ai famosi fork di aomenc, ti diranno la stessa cosa.
Infatti mi auguro che chiunque faccia editing video si prenda la cura di esportare in proresHQ o lossless ffv1 e di ricodificare con calma (usando ffmpeg se non si è pratici) in hevc o svtav1 10bit con crf |
|
|
inviato il 26 Dicembre 2025 ore 14:02
@fraever
come detto sopra, il messaggio prima, dipende il risultato perché ti serve.
|
|
|
inviato il 26 Dicembre 2025 ore 15:56
“ Blade, scrivi quello che vuoi. Intel ha perso tipo il 90% del mercato con le sue ultime 3 generazioni di cpu, saremmo tutti acquirenti poco attenti ai grafici.
I Ryzen sono più efficienti (di moltissimo), si raffreddano benissimo con una ventolina da 35€, costano meno, sono „ non c'è UNA cosa vera di quello che hai scritto e le quite di intel perse sono ovviamente molto meno di quell'apocalittico 90% |
|
|
inviato il 26 Dicembre 2025 ore 16:02
“
Vi anticipo una sintesi: questi encoder hardware sono pensati per transcodificare al volo l'output per lo streaming. Sono poco configurabili, e sono impostati per dare un frame rate fisso, adattando la qualità in base alla potenza della scheda. Inoltre utilizzano algoritmi percettivi. Il risultato è che in alcuni casi durante la proiezione si percepisce il calo di qualità. Inoltre, se fai degli screenshot noterai che, rispetto all'encoding da CPU, tendono a perdere dettagli fini. Morale: se hai una CPU potente, e vuoi ridimensionare i tuoi video mantenendo la massima qualità possibile, sfrutta lei.
„
è un problema che c'è anche nei videogames. anche perché usano un sacco di silicio della gpu per sezioni che sono tra loro alternative e molto specializzate lasciando meno potenza di calcolo reale al programmatore. stanno lavorando sui framerate con effetti che sono più posticci degli algoritmi tradizionali che sono teoricamente molto più finti.
leggo molte frasi fatte qui senza che vi sia una reale conoscenza di bench, architetture e impieghi. „ |
|
|
inviato il 26 Dicembre 2025 ore 16:15
@Black imp
Se ti riferisci alla multiframe(2 x, 3x, 4x)di nvidia é puro marketing che ha senso solo in particolari scenari, ovvero ho frame alto e voglio più fps, se lo si usa quando hai 10fps hai lag tra i comandi e quello che vedi a schermo.
Cosa diversa se si fa riferimento all'upscaler.
Io aspetto ancora i bench a cui fai riferimento, così da porter discutere.
Ti ricordo che fino a qualche tempo fa la tua prima scelta era il 7900, ora giustamente I7 265k, ti ho detto che sei impazzito o non capisci nulla? Non mi sembra, mi sembra un ragionamento corretto fatto oggi con le cpu disponibili e il costo dell'intera piattaforma oggi.
Quota di mercato desktop amd insegue sarà sui 28%, ambito server invece si parla che ha raggiunto il 50% ed eguagliato Intel.
Il 90% si ha forse solo in ambito handled, una nicchia.
|
|
|
inviato il 26 Dicembre 2025 ore 17:12
“ Io aspetto ancora i bench a cui fai riferimento, così da porter discutere.
Ti ricordo che fino a qualche tempo fa la tua prima scelta era il 7900, ora giustamente I7 265k, ti ho detto che sei impazzito o non capisci nulla? Non mi sembra, mi sembra un ragionamento corretto fatto oggi con le cpu disponibili e il costo dell'intera piattaforma oggi „
ma te li ho fatti vedere. ma parli dei bench del 265k o del paragone tra 5950x e 12900x? comunque se guardi Techpowerup e cerchi la review dell'amd 9800x3d vedi i valori aggiornati di tutti questi e vedi che nelle applicazioni che usano di più la virgola mobile persino il 265k è davanti al 9950x.
la mia scelta del 7900 era perché aveva consumi limitatissimi e comunque potenza più che a sufficienza mentre la generazione 14 di Intel era incomprabile e catastrofica. Non c'erano ancora gli Arrow Lake. Adesso che sono usciti e ho pensato alle applicazioni che voglio usare, dopo i vari aggiornamenti del microcodice e degli algoritmi dei dispatcher sui sistemi operativi, il 265k è risultato nettamente più interessante e non consuma uno sproposito.
per quello che riguarda le gpu sono tutti meccanismi con cui sostituiscono la potenza vera con escamotage, si anche l'upscaling. |
|
|
inviato il 26 Dicembre 2025 ore 17:24
l'escamotage del upscaler torna utile perché ad oggi non hai potenza per fare andare il path tracing, per esempio. In futuro chissà.
Sui benchmark, li vedo tutti su technopower, e se noti ad oggi sui quei software dove servono pochi core e frequenze alte gli amd hanno un poco di vantaggio.
Con i nuovi prezzi sugli ultimi Intel , amd deve correre ai ripari per essere competitiva.
Ma con ciò non dico che sono scarsi. |
|
|
inviato il 26 Dicembre 2025 ore 19:33
Eccomi Murphy.
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, Vulkan, 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 provato a transcodificarlo per ottenere un output di circa 700MB, 10 volte più piccolo, comunque con un ragionevole bitrate di 12mbit/s, con un fattore Bits/(Pixel*Frame) di 0.05. E' il target di default di shutter encoder per la codifica H265 HEVC.
Di seguito i tempi di trascodifica:
NVENC H265 Normal: 180s 138.2fps
NVENC H265 MaxQ: 284s 48.65fps
Vulkan H265 (Normal/MaxQ): 221s 62.52fps
CPU H265 Normal: 576s 23.99fps
CPU H264 Normal: 249s 55.49fps
Alcune spiegazioni: è possibile scegliere una modalità "Maximum quality" (MaxQ) per ogni transcodifica. Questa modalità con Vulkan non ha nessun effetto, con NVENC cambia significativamente il tempo di codifica, ma ahimè anche la qualità dell'output, mentre è inutilizzabile da CPU (va a 2fps). Poi in H264 di default si ottiene un output di circa 1.3GB, ho cambiato manualmente la dimensione in 700MB per il test. Non ho utilizzato H264 da GPU perchè non si ottengono benefici sostanziali in velocità rispetto a H265. Per tutti i test ho utilizzato VBR a singola passata
Di seguito i migliori risultati. Questi confronti hanno un problema di fondo: se viene cambiato il tipo di frame (I,B o P) la resa può essere diversa, ed una valutazione su singolo fotogramma potrebbe essere fuorviante. Posso dirvi che ho guardato altri punti, e mi sembrano in linea con questo.
A destra abbiamo il video originale, a sinistra quello con CPU, al centro NVENC Maximum Quality. Come potete vedere guardando la zona attorno all'ombra al centro, la CPU mantiene molto dettaglio fine che la GPU perde. Poi vi posso dire che NVENC Normal è ancora peggio, e Vulkan non ha nemmeno senso utilizzarlo, in quanto è più lento di NVENC Normal e peggiore. H264 con CPU è circa come NVENC Normal.
Per come la vedo io, se è per una transcodifica di materiale da mettere in un social, NVENC Normal va benissimo, ma per conservare un video andrei di CPU, magari con due passate.
Più avanti magari proverò Megui
Altro aspetto: Ho usato un 265KF ed una RTX4070. Mentre usavo la CPU il consumo era sopra i 200W, quando usavo la GPU ero al 25% di carico su questa, 10% sulla CPU. Mi aspetto che con un sistema simile, ma un 225F i tempi con NVENC siano simili, con la CPU raddoppiati. |
|
|
inviato il 26 Dicembre 2025 ore 19:57
blade usa slow.pics |
|
|
inviato il 26 Dicembre 2025 ore 20:21
eccola qua una bella comparison: slow.pics/c/AhyCR188
è stato usato x265 con preset veryslow usando CRF, e nvenc_hevc su ampere con -rc vbr -tune uhq -preset p7
Entrambi i 4 files hanno lo stesso identico peso per coppia.
Aomenc pesa 69MB al posto di 63
Qui si trovano i file da scaricare, assieme all' originale: drive.google.com/drive/folders/1Vch2Dqn8elhRXoWot0bqz4He6rs99OxR?usp=s
il file originale è nraw high quality (che ricordo essere comunque lossy visto che usa ticoraw) a 4128x2322, è stato successivamente rimpicciolito a 1920x1080 con ffmpeg e codificato con x264 -qp 0 (che è matematicamente lossless)
Ricordo che usando i tasti numerici si possono cambiare velocemente le foto visualizzate su slow.pics |
|
|
inviato il 26 Dicembre 2025 ore 20:22
Azz un test veramente professionale 
Sono da cellulare e si fa fatica a capire le differenze, provo dopo da laptop.
Domanda: ma vedendo il video senza fermo immagine balza subito all'occhio la differenza?
Perché la posterizzazione salta subito al occhio, il micro dettaglio se non sai dove guardare magari fai fatica.
Anche quello di Fraever lo guardo dopo. |
|
|
inviato il 26 Dicembre 2025 ore 20:25
Dipende dal bitrate, ma il blocking causato dagli hw encoders personalmente si nota molto.
Purtroppo non ho una gpu ada lovelace o blackwell quindi non posso provare se nvenc_av1 soffre meno di blocking
Ah cavolo adesso che si penso mi son dimenticato di includere uno screenshot del file originale, vabbè cmq in caso c'è il file su google drive |
|
|
inviato il 26 Dicembre 2025 ore 21:36
“ Azz un test veramente professionale Sorriso
Sono da cellulare e si fa fatica a capire le differenze, provo dopo da laptop.
Domanda: ma vedendo il video senza fermo immagine balza subito all'occhio la differenza?
Perché la posterizzazione salta subito al occhio, il micro dettaglio se non sai dove guardare magari fai fatica.
Anche quello di Fraever lo guardo dopo. „
Fraever ha utilizzato, nelle versioni low bitrate, un valore di Bits/(Pixel*Frame) di 0.15, 0.65 nelle versioni bitrate più elevato. Si tratta di valori pari al triplo e 13 volte tanto quelli che ho utilizzato io. Nonostante ciò i suoi output risultano peggiori dei miei. La parte critica nel suo caso sono le foglie degli alberi.
A low bitrate NVENC è inguardabile, x265 meglio ma si nota la perdita.
A bitrate più elevagto x265 è perfetto, NVENC se ci guardi noti qualcosa di strano, ma comunque è decente. Ma stiamo parlando di bitrate elevati.
Nel mio caso le perdite di dettaglio sono più a chiazze. Ti posso dire che NVENC Max Quality senza fermo immagine è comunque buono, mentre con Vulkan e NVENC liscio si percepisce una minore incisività.
Ma al di là di questo, se lo scopo è di archiviare i propri video ottimizzando lo spazio, NVENC non va bene, perchè il dettaglio perso è irrecuperabile. |
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.
