madVideoRenderer - high quality video renderer (GPU assisted)

**Mike5** · 24-04-2009, 09:24

Originariamente scritto da ciuchino

i decoder usati sono quelli che leggi nel current graph...

Ok, non avevo capito la schermata di TheaterTek e quindi è confermato che quello che ho detto non aveva senso

Ma il video piccolo lo ottenete solo con i sottotitoli ?

Io purtroppo non posso fare prove al lavoro perchè la scheda video vecchia con madVR mi dà l'errore che non supporta texture che non siano potenze di due.

**ciuchino** · 24-04-2009, 09:30

Anche in altri casi come detto da piperprinx.
Poi ogni catena fara' storia a se' ... comunque migliorera' lasciamolo lavorare tranquillo che gia' lo martellano di brutto

**Mike5** · 24-04-2009, 09:51

Originariamente scritto da ango

Esiste una discussione dove è spiegato per benino la sequenza temporale e il ruolo del flusso dati dal DVD al monitor?

Non sono sicuro di aver capito le tue domande e non so nulla di regolazione di un CRT, ma posso riassumere la catena dei filtri.

Sorgente (Media/DVD/BD...) -> source/splitter (es. Haaili splitter per gli .mkv) -> flusso video + flusso audio + (eventuale) flusso sottotitoli

A questo punto ogni flusso prende la sua strada. Per il video:

Flusso video -> decoder (es. CoreAVC) -> video decodificato -> eventuale post-processing (es. ffdshow) -> video decodificato e manipolato -> renderer video

Lo scaling può avvenire nella fase di post-processing (se richiesto) o avviene comunque nel renderer se la risoluzione del video è diversa da quella del monitor. Può anche avvenire in entrambi.

La conversione colore può avvenire in una o più fasi distribuite tra decoder, post-processing e renderer. Avviene comunque nel renderer per il discorso che ho fatto alcuni post su.

Il tearing è legato alla tempistica del disegno del frame rispetto ai sincronismi video. Durante la durata di un refresh sul monitor, solo una parte del tempo è dedicata a trasmettere l'immagine (la cosiddetta parte attiva); la rimanente parte è costituita da Front Porch, Vertical Blank e Back Porch.

Ad esempio a 50Hz, un refersh dura 20ms. Di questi, solo ad esempio, 17 sono impiegati per trasmettere l'immagine al monitor. Gli altri tre sono disponibili per trasmettere altre cose (è qui per esempio che il PAL mette le informazioni TeleText, etc...).

La scheda video usa di norma due buffer dove accumula il disegno del frame. Quando finisce un frame, scambia i buffer, quello finito va al monitor e l'altro diventa disponibile per disegnare il frame succcessivo. Questo scambio può avvenire quando vogliamo, ma l'invio deve avvenire durante il Vertical Blank.

Se all'arrivo del Vertical Blank la scheda video sta ancora disegnando il frame, lo scambio viene forzato e al monitor che aveva già disegnato un pezzo del frame precedente, arriva il frame successivo: il risultato è due pezzi di due frame diversi sul monitor, separati da uno "strappo", in inglese tearing.

Perchè succede ? Un motivo è la scheda video troppo lenta: se nel caso dei 50Hz impiega più di 20ms a disegnare il frame, avremo tearing. In questo caso l'unica soluzione è cambiare scheda video.

Un altro motivo, più comune, è che il renderer comincia a disegnare il frame troppo a ridosso del Vertical Blank. Ad esempio, la scheda video impiega solo 12ms, ma comincia a disegnare solo a 8 ms dal Vertical Blank: risultato, tearing. In questo caso la soluzione è software e va dall'uso dell'Exclusive Renderless alla patch di Beliyaal in MPC-HC, all'uso del VSync di Reclock, etc...

Spero di aver risposto ad alcuni dubbi.

**Mikemacd60** · 25-04-2009, 11:29

[QUOTE=ciuchino]
Con DVD originale mi da' codice errore regionale , macrovision mi sa' piu' di uscita componente ... bo'.

Ho notato che se apro DVD originale oppure un Dvd da Hdisk ( iso Caricato su Daemon o Cartella Video_ts col comando apri folder ) cnn Mpc hc di Casimir usando madVR mi da sempre codice Dvd:Macrovision Fail.
Gli stessi Dvd li apro tranquillamente con mplayerc_homecinema_x86_v1.2.908.0 con EVR custom pres.
Con Vlc tutto ok.
Qualcun'altro ha avuto gli stessi problemi ?

**Mike5** · 25-04-2009, 12:18

Si, è un problema noto, probabilmente non ben compreso neanche da chi sviluppa, e in attesa di soluzione.

Michele

**Mikemacd60** · 25-04-2009, 14:18

Grazie per la tempestività.

**ciccio1112** · 25-04-2009, 14:35

madVR 0.7 released

http://madshi.net/madVR.zip

Code:
* fixed: video size/position was incorrect with Zoom Player & CoreAVC
* precompiled shaders are now loaded from "shaders.dat" (for testing)
* various shaders files are shipped created with different compiler versions
* OSD now shows 4 different display refresh rate estimates (for testing)
* fixed: with bilinear chroma resampling luma was always resampled, too

**Mike5** · 25-04-2009, 18:35

La versione 0.7 dovrebbe risolvere il problema del video piccolo in TheaterTek. Sembra che succedesse anche con ZP ma solo con CoreAVC. Provate.

Con la 0.7 se aprite un file diverso dopo il primo eseguito otterrete un errore di apertura del file shader. E' un bug già noto e verrà corretto nella prossima versione.

**ciuchino** · 25-04-2009, 19:24

Dal poco che ho provato , solo XP , con Theatertek il problema non sembra risolto ... almeno completamente.
Purtroppo TT e' "progetto chuso" al momento per cui chiedere qualcosa di la' e' mission impossible

.

**f_carone** · 27-04-2009, 09:35

madVR 0.8 released

http://madshi.net/madVR.zip

Code:
* fixed: only the first movie played fine, a 2nd movie stayed black
* 3dlut creation should work again now (broken in v0.7)
* minor improvement in display refresh rate calculation
* some minor changes in window management

ciao,
fil

**f_carone** · 27-04-2009, 09:51

Con TheaterTek & coreAVC ancora problemi di videosize, ma questo problema esiste anche con Haali renderer, la nota positiva è che risulta nettamente migliorata la fluidità nei panning v/h anche con MPC-HC .

ciao.
fil

**Mike5** · 27-04-2009, 10:16

Originariamente scritto da f_carone

la nota positiva è che risulta nettamente migliorata la fluidità nei panning v/h anche con MPC-HC .

L'ho notato anch'io, anche se teoricamente madshi non ha ancora fatto niente sul fronte della fluidità.

**f_carone** · 05-05-2009, 08:08

madVR v0.9

http://madshi.net/madVR.zip

* bigger part of initialization is done before playback is allowed to start
* if Direct3D device is lost and can't be recovered, playback is paused
* if paused playback is restarted, madVR tries to recover lost device again
* decoders are now forced to deliver video width which is devidable by 16
* reduced CPU consumption a bit
* changed video -> GPU uploading method -> lower GPU rendering times (?)
* OSD lists texture uploading times again
* OSD now only increases CPU consumption in detailed mode (2x Ctrl+J)
* external shader*.dat files are gone, compiler 41 is now always used
* when final VSync estimate if off a lot, a file "vsync.dat" is created
* fixed: 3dlut colors were ever so slightly incorrect
* fixed: shader math colors were slightly incorrect

ciao,
fil

**Renzo 1969** · 10-05-2009, 11:35

Scusate la mia ignoranza, ma dopo avere installato madVR v0.9, cosa è necessario fare per utilizzarlo?
Con MPC-HC continua a rimanere non selezionabile.

**ciccio1112** · 10-05-2009, 17:44

Ciao renzo, le ultime versioni di mpc hc includono già il nuovo renderer maVR fra i renderer di uscita, e dovrebbe apparire selezionabile dopo aver installato manualmente il renderer stesso.

Per il resto non devi fare altro, se non fare partire un video,altrimenti riprova ad installarlo nuovamente.

Discussione: madVideoRenderer - high quality video renderer (GPU assisted)

Strumenti Discussione

Ricerca discussione

Permessi di scrittura