[Thread Ufficiale] HD Video Nvidia: driver, programmi, PureVideo, problemi, novità..

[Murakami]

Originariamente inviato da Gabriyzf

Complimenti anche da parte mia Murakami:
ma allora, nonstante si fosse sbandierato il contrario, sembrerebbe che anche NV40 sia in grado di accellerare il WMV, o mi sono perso qualcosa?
Comunque mi pare che ormai lo standard per gli imminenti video HD di blue-ray e hd-dvd siano in H264, no?

Non ti sei perso nulla: forse, una qualche forma di accelerazione è presente (contro quanto è dichiarato sul sito nVidia... ), stiamo ancora cercando di capirlo...a tal proposito, aspettiamo un test approfondito di qualche possessore di NV40...
Per quanto riguarda lo standard, dovrebbe effettivamente essere l'H.264.

[Murakami]

Ragazzi: qualcuno conosce un modo per far eseguire la sola MC ad hardware compatibile MC+IDCT?

[shodan]

Ciao Murakami,
ma il KyroII lavora tranquillamente con il decoder PureVideo? O meglio, quest'ultimo si attiva anche se non "sente" una scheda Nvidia? Non pensavo...
Forse ho capito male io, ma il KyroII con accellerazione attiva occupa _più_ CPU che usando la modalità solo software?

Ciao.

[Murakami]

Originariamente inviato da shodan

Ciao Murakami,
ma il KyroII lavora tranquillamente con il decoder PureVideo? O meglio, quest'ultimo si attiva anche se non "sente" una scheda Nvidia? Non pensavo...
Forse ho capito male io, ma il KyroII con accellerazione attiva occupa _più_ CPU che usando la modalità solo software?

Ciao.

Il decoder PureVideo funziona (in teoria) con una qualsiasi scheda video il cui driver supporta DXVA (è scritto chiaramente sul sito nVidia): ovviamente, dà il meglio di sè con schede video GeForce, oltre ad essere l'unico modo per sfruttare le funzionalità di deinterlacciamento avanzato, 3:2 e 2:2 pulldown, bad edit correction etc...del motore hardware PureVideo.
Dai test che ho effettuato, l'accelerazione hardware del chip Kyro2 occupa più CPU della modalità software: il motivo di questo anomalo comportamento mi è del tutto misterioso.

[shodan]

Originariamente inviato da Murakami

Dai test che ho effettuato, l'accelerazione hardware del chip Kyro2 occupa più CPU della modalità software: il motivo di questo anomalo comportamento mi è del tutto misterioso.

Non c'è che dire: una features davvero utile!

[Murakami]

Probabilmente, per questi vecchi chip i test andrebbero ripetuti con Win98SE, vecchie versioni dei driver e vecchie versione dei player; ma non si può pensare che un utente faccia tutto questo, procedendo per infiniti tentativi...del tutto ingiustificabile, invece, il comportamento della GPU Volari V3XT, un prodotto recente e con drivers per WinXP ormai maturi (tra l'altro, PowerDVD 6 è espressamente indicato nel sito XGI tra i player che supportano pienamente le features dei loro chip).

[Murakami]

Altro articolo molto interessante... http://www.extremetech.com/article2/...1916994,00.asp
In sostanza, la tecnologia Avivo prevale, per ora, su quella PureVideo: l'unico settore dove nVidia si dimostra alla pari è quello dell'accelerazione WMV9-HD.

[Murakami]

Qui c'era un post colossale di lucusta: che fine ha fatto?
http://www.hwupgrade.it/forum/announ...uncementid=111 ora ho visto

[lucusta]

Originariamente inviato da Murakami

Qui c'era un post colossale di lucusta: che fine ha fatto?
http://www.hwupgrade.it/forum/announ...uncementid=111 ora ho visto

no, non mi va' di riscrivere tutto!

[shodan]

Originariamente inviato da lucusta

no, non mi va' di riscrivere tutto!

Cavolo mi sono perso il tuo post!
Ti prego fa almeno un riassuno...

[lucusta]

bhe', raccontavo delle evoluzioni dei codec per sottolineare la differenza tra' MPEG2 e MPEG4, cercando di mostrare perche' l'accellerazione HW dell'MPEG2 non e' del tutto complementare a quella dell'MPEG4, per rispondere a

Originariamente inviato da Murakami

Mi viene spontanea un'altra domanda: se ricordo bene, l'algoritmo di compressione MPEG4 si basa, più o meno, sugli stessi principi dell'MPEG2...se la premessa è giusta, perchè diavolo non esiste una VGA che ne acceleri la decodifica in hardware (e intendo proprio la decodifica, non una qualche forma di post processing -accelerato dalle GPU Radeon compatibili DX9-)...

ritornando nel discorso, posso dire le differenze:

- La Motion Compensation viene migliorata passando da -o+ 15 pixel a -o+ 15.5 pixel a passi di mezzo pixel, consentendo in piu' l'estensione dell'area di ricerca fino a -o+ 31.5 pixel, possibilita' molto apprezzata con l'uso dei grandi formati HDTV.
- viene applicata la Predictive Coding of Motion Vectors, ossia si considerano un gruppo di vettori per lo spostamento di vari oggetti, partendo dal presupposto che se e' l'obbiettivo a muoversi, gli oggetti che si muoveranno nel quadro avranno un vettore simile, indicando cosi' un unico vettore e le differenze per gli altri; in piu' viene consentito l'uso di vettori che indicano fuori dal quadro dell'immagine, per gli oggetti sul bordo, definendo la Unrestricted Motion Vector Mode (UMV)
- viene migliorata l'Entropy coding, ossia la tabbellizzazione delle ridondanze del fulsso dei dati, una sorta di zippata del file; in piu' viene aggiunta la Syntax-based Arithmetic Coding Mode (SAC) che consente inoltre una creazione "dinamica" delle tavole di ridondanza trovate sullo stesso file, mentre prima si avevano delle tabelle fisse (VLC=Variable Lenght Coding).
- Advanced Prediction Mode consente di appicare anche 4 vettori invece dei 3;
- L’ Overlapped block motion compensation (OBMC), consente di ridurre gli artefatti di codifica nei blocchi che stanno in spostamento e sui blocchi su cui si spostano gli oggetti.

gia' l'aumento a mezzo pixel per la ricerca dei blocchi che si spostano ed il relativo vettore di spostamento e sufficente per dire che un codificatore HW MPEG2 non puo' essere compatibile con un flusso dati MPEG4, ma il contrario si, ma la tecnica dei multivettori e' del puntamento fuori il quadro richiedono effettivamente una computazione molto piu' marcata, anche per la gia' elevata computazione che si otteneva da MPEG1 a MPEG2 con l'inserimento dei B frame, che erano in pratica fotogrammi da calcolare in toto.

comunque non e' vero che non ci sono schede video che decodificano MPEG4 in HW; la S3 integrata nei chipset via sulle epia hanno una sotra di decodifica piu' spinta in HW pe l'MPEG4, ma credo che si limiti alla MC con i passi a mezzo pixel e l'uso di multivettori.

[Murakami]

Lucusta, che mi dici dell'l'MPEG1? Come mai non è prevista accelerazione hardware nelle schede odierne (al di là del fatto che, data la leggerezza del formato e la potenza delle CPU, non è strettamente necessaria)?

[shodan]

Grazie mille lucusta,
sei stato gentilissimo!

[lucusta]

l'MPEG1 e' la base dei codec di compressione;
nel post #293 ho detto alcune imprecisioni:
sia la DTC che la MC sono sempre state utilizzate nei codec video fino ad ora fatti, con la DCT e' usata nel frame, comprimendolo come in una jpeg (quntizzazione e analisi delle frequenze spaziali, ossia dei dettagli minimi a quelli grossolani), e sulla sequenza video, mentre la MC si concentra sul piano temporale, calcolando gli spostamenti di moto degli oggetti nel quadro dell'imagine.

come negli altri, la DCT non e' cambiata piu' di tanto fino all'H.264, mentre la MC e stata via via piu' articolata.
dall'1 al 2 sono stati introdotti i B-frame, che sono fotogrammi con compressione per informazione bidirezionale, ossia prende informazioni sia dagli immediatamente precedenti che dagli immediatamente seguenti frame.

ora, credo che il fattore comunte tra' MPEG1-2-4 sia la DTC, almeno fino al 4 parte 10 (divx5), mentre per l'H.264 anche la DCT e' stata ulteriormente migliorata, eliminando i fattori di discrepanza tra' decoder e decoder, usando una DCT a interi, invece che a virgola mobile;
nel prossimo codec prevedo che sara' ancora questa a poter essere ulteriormente ritoccatta usando la DWT, ossia la trasformata discreta dell'onda delle frequenze e non piu' del suo coseno, come avviene nel jpeg2000.

percio' credo che sia la MC a dare problemi per decodificarla in HW, in quanto
e' composta da diversi fattori arbitrari degli algoritmi usati, come, ad esempio, il tipo di analisi che si fa' per determinare quale bloco si sposta (piu' su' H.26x che su MPEG, in quanto i primi sono delle linee guida, il secondo e' uno standard).

o forse e' la sua natura di streaming sequenziale ad impedirne una parziale decodifica HW, perche' la grande differenza tra' MPEG1 e MPEG2 e' l'impossibilita' del primo di poter riprodurre da un punto in poi, ossia l'indipendenza della decompressione, mentre nell'MPEG2 la riproduzione puo' avvenire da qualsiasi frame del video, perdendo i primi frame fino ad arrivare al K-Frame, ossia quello di sincronia.

[shodan]

Originariamente inviato da lucusta

l'MPEG1 e' la base dei codec di compressione;
nel post #293 ho detto alcune imprecisioni:
sia la DTC che la MC sono sempre state utilizzate nei codec video fino ad ora fatti, con la DCT e' usata nel frame, comprimendolo come in una jpeg (quntizzazione e analisi delle frequenze spaziali, ossia dei dettagli minimi a quelli grossolani), e sulla sequenza video, mentre la MC si concentra sul piano temporale, calcolando gli spostamenti di moto degli oggetti nel quadro dell'imagine.

come negli altri, la DCT non e' cambiata piu' di tanto fino all'H.264, mentre la MC e stata via via piu' articolata.
dall'1 al 2 sono stati introdotti i B-frame, che sono fotogrammi con compressione per informazione bidirezionale, ossia prende informazioni sia dagli immediatamente precedenti che dagli immediatamente seguenti frame.

ora, credo che il fattore comunte tra' MPEG1-2-4 sia la DTC, almeno fino al 4 parte 10 (divx5), mentre per l'H.264 anche la DCT e' stata ulteriormente migliorata, eliminando i fattori di discrepanza tra' decoder e decoder, usando una DCT a interi, invece che a virgola mobile;
nel prossimo codec prevedo che sara' ancora questa a poter essere ulteriormente ritoccatta usando la DWT, ossia la trasformata discreta dell'onda delle frequenze e non piu' del suo coseno, come avviene nel jpeg2000.

percio' credo che sia la MC a dare problemi per decodificarla in HW, in quanto
e' composta da diversi fattori arbitrari degli algoritmi usati, come, ad esempio, il tipo di analisi che si fa' per determinare quale bloco si sposta (piu' su' H.26x che su MPEG, in quanto i primi sono delle linee guida, il secondo e' uno standard).

o forse e' la sua natura di streaming sequenziale ad impedirne una parziale decodifica HW, perche' la grande differenza tra' MPEG1 e MPEG2 e' l'impossibilita' del primo di poter riprodurre da un punto in poi, ossia l'indipendenza della decompressione, mentre nell'MPEG2 la riproduzione puo' avvenire da qualsiasi frame del video, perdendo i primi frame fino ad arrivare al K-Frame, ossia quello di sincronia.

Se non ricordo male però all'epoca esistevano delle schede PCI dedicata proprio alla decodifica MPEG1 (seguite qualche anno dopo da quelle dedicate all'MPEG2...).

Ciao.

[lucusta]

Originariamente inviato da shodan

Se non ricordo male però all'epoca esistevano delle schede PCI dedicata proprio alla decodifica MPEG1 (seguite qualche anno dopo da quelle dedicate all'MPEG2...).

Ciao.

credo che si trattasse della sola IDCT, cosa che ora, con le SSE, le puo' fare tranquillamente il processore.
in effetti l'algoritmo dell'MPEG1 e' molto semplice, piu' semplice dell'MPEG2 visto l'assenza dei B-frame, quindi e' piu' probabile che l'opzione della decodifica totale in HW del'MPEG1 da parte delle schede video non sia stata usata solo per questioni commerciali: al tempo non interessava farlo.
non saprei, oggi, come poter testare l'assorbimento di risorse di una codifica interamente software di un MPEG1 a confronto di un'eventuale codifica parziale HW, in quanto le IDCT le puo' fare sia il processore che la maggior parte delle schede video da 4 anni a questa parte..

servirebbe un pentium liscio, senza MMX (ne dovrei avere uno a 200 Mhz), una scheda video senza accellerazione come una S3 trident64 (che ho), ed una con accellerazione delle IDCT, tipo una rage2 (che ho), in un'ambiente moderno come XP; non ricordo se ho la scheda madre...

[Murakami]

Originariamente inviato da lucusta

non saprei, oggi, come poter testare l'assorbimento di risorse di una codifica interamente software di un MPEG1 a confronto di un'eventuale codifica parziale HW, in quanto le IDCT le puo' fare sia il processore che la maggior parte delle schede video da 4 anni a questa parte..

servirebbe un pentium liscio, senza MMX (ne dovrei avere uno a 200 Mhz), una scheda video senza accellerazione come una S3 trident64 (che ho), ed una con accellerazione delle IDCT, tipo una rage2 (che ho), in un'ambiente moderno come XP; non ricordo se ho la scheda madre...

Hmm...schede senza IDCT ce ne sono a bizzeffe, anche tra quelle recenti: la mia domanda era volta a capire se quelle che ne sono dotate accelerano la decodifica MPEG-1 (cosa che, secondo me, non avviene).
Quanto al test, si fa molto presto: hai visto come è composto il mio nuovo muletto? Mi basta fare una prova con il modulo Rainbow Runner Studio inserito (che ha decodifica MPEG1 in hardware) e disinserito...

[lucusta]

ti sei procurato una millenium con modulo?

mhm.. sono tentato di prendere una matrox anche io, ma le nuove non hanno assolutamente accelerazione HW, percio' credo che aspettero' qualche scheda dedicata..

EDIT: accellerazione HW H.264, preciso.

[Murakami]

Originariamente inviato da lucusta

ti sei procurato una millenium con modulo?

Si, ho una Matrox Millennium 2 PCI con 8 mb di WRAM, con moduli Rainbow Runner Studio (uscite S-Video e composito, acquisizione MJPEG in hardware, decodifica MPEG1 in hardware, transizioni in fase di montaggio video accelerate in hardware) e Rainbow Runner TV (scheda ISA con sintonizzatore TV, collegata al modulo RRST tramite cavo), il tutto affiancato da una M3D: la cosa soprendente è che ho acquistato tutto questo materiale NUOVO, imballato, in un negozio che aveva fondi di magazzino invenduti, per una pipa di tabacco...

[lucusta]

aah.. non avevo notato la M3D.. come si comporta?