HTPC, aiuto per la guida di ffdshow

[Riker]

ecco il risultato, confrontiamolo con gli altri :

Urk... completamente da ritarare, mi sa che si fa prima a far le prove con ColorMatrix (Senza e con) per vedere come comportarsi...

[ciuchino]

scusate scusate errore mio, avevo inavvertitamente settato la saturazione a 58 invece che 50 sulle impostazioni della scheda video nvidia ;

Ah ecco ... default e per sempre default

[Riker]

ecco ora sì, il colormatrix fa il suo dovere e riporta sia il rosso che il verde alle giuste tonalità

Ora ho trovato anche io
Se nella schermata di test dei colori il giallo è virato al verde significa che va messo ColorMatrix

[Neo85]

sì infatti, ma nell'immagine hd l'uso di colormatrix modifica il colore originale, infatti credo proprio che per filmati 720p codificati in x264 nn deve essere utilizzato.....

[Neo85]

tra qualche minuto posto i printscreen dell'uso di avisynth resize e unsharpmask su file HD

[ciuchino]

Penso anchio , se il filmato e' stato codificato correttamente e la scheda video lo riconosce come HD dovrebbe applicare corretamente il Rec.709.
Io pero' vado a letto

[Neo85]

ahaahh okok io li posto lo stesso

[Neo85]

posto una piccola comparativa sull'uso di sharpen su materiale HD compresso a 720p:

immagine originale (solo resize 1920x1080 laczos par 2 senza nessuno sharp):


resize 1920x1080 lanczos par 2 luma sharpen = 2.0 :


resize 1920x1080 lanczos par 2 luma sharpen = 0
unsharp mask 37:


resize 1920x1080 lanczos par 2 luma sharpen = 2.0
unsharp mask 37:

[stealth82]

Ma così facendo cambi la decodifica del colore da quello dei DVD a quello degli HD...
Non mi torna molto
(A meno che il display non pensi di avere in ingresso un segnale HD)

Veramente l'intento è questo, e ben dichiarato:

ColorMatrix corrects the colors of mpeg2 streams of dvds. More correctly, those mpeg2 streams are encoded using a different set of coefficients as used by AviSynth's color conversion routines or by the XviD/DivX decoders, with the result that DivX/XviD clips or mpeg2 clips encoded by TMPGEnc/CCE using AviSynth or VirtualDub are displayed with slighty off colors (which looks like a small difference in brightness[*]). This can be checked by opening the mpeg2 stream directly in VDubMod. More info can be found in the readme.

This filter recalculates the yuv values assuming the coefficients which are used by AviSynth/VDub/DivX/XviD, with the consequence that your final encoding (mpeg2 or mpeg4) is displayed correctly.

I709 = type 1 = MPEG2 default
FCC = type 4 = FCC standard
I470 = type 5 = MPEG1 default
S170 = type 6 = SMPTE 1700M standard
S240 = type 7 = SMPTE 240M standard

[stealth82]

Allora prova preliminar; se metto il resize con la chiamata di avisynth prima di LSF scatta tutto anche se la cpu nn supera il 90% di utilizzo, per avere fluidità bisogna mettere la chiamata di LSF prima del resize in questo modo:

Non mi stupisco affatto. Considerato che, abituato a come sei, ovvero resizer dopo, usi un SS di 1.4. Non è mica la stessa cosa metterlo dopo

Dovresti abbassare il SS come minimo.

con questa chiamata e il mio E6400 ho il seguente consumo CPU... che nn è ben diviso tra i due core

Ho notato bene questa cosa e mi sembra di notare che lo Spline è molto meno lineare del Lanczos nella ripartizione del lavoro sui due core. Ovvero per l'ultimo i due core sono simili. Mentre per lo Spline uno dei due lavora di meno.

[stealth82]

questo invece è il consumo CPU con la seguente chiamata di avisynth:

SetMemoryMax(1024)
MT("LimitedSharpenFaster(ss_x=1.4, ss_y=1.4, Smode=3, strength=230, overshoot=0, soft=60)",3)
ColorMatrix(Mode="Rec.601->Rec.709",clamp=false,threads=2)

e resize impostato sul tab di ffdshow:
lanczos par 2 (sia su luma che chroma) 1280x720

Le routines di resize su ffdshow sono sempre state più veloci delle controparti Avisynth però, come avevo scritto nella guida - anche se adesso è temporaneamente rimosso, del risultato Avisynth ci si poteva fidare di più, almeno con risoluzioni intermedie.

In tutte le prove che ho fatto, perciò, ho testato i carichi solo con Avisynth.

[Riker]

I709 = type 1 = MPEG2 default
FCC = type 4 = FCC standard
I470 = type 5 = MPEG1 default
S170 = type 6 = SMPTE 1700M standard
S240 = type 7 = SMPTE 240M standard

Scusa stealth è che sono invetrato a capire cosa sia il rec 601 e 709 e relativi spazi colore/gamut.
Ed in teoria un dvd è encodato in 601 e come tale dovrebbe essere decodato.

In teoria se avisynth lavora in YUV la cosa dovrebbe essere trasparente (a meno che non giochi con i colori) perchè non fa nessuna conversione, se invece fa conversioni verso RGB o comunque conversioni di spazio colore allora diventa importante.

Bisognerebbe vedere se il problema dei colori virati, nel caso ci sia bisogno di attivare ColorMatrix, si ha anche non usando avisynth ma solo ffdshow in YUV.
Se anche con il solo ffdshow il problema c'è (a parita di resize e filtri) allora è un problema di visualizzazione (il fatto che il display pensa di avere un 709 in ingresso) e la necessità di ColorMatrix va valutata da caso a caso.
Se invece c'è solo con Avisynth allora è un problema di conversione sua e ColorMatrix va sempre messo indipendentemente dalla catena.

[ciuchino]

C'e' anche se usi il resize di Ffdshow.
La scheda video pensa che sia HD e sbaglia ...

http://forum.doom9.org/showthread.php?t=120013

On rereading this thread, I feel there is some confusion about Avisynth pixel format, i.e RGB24, RGB32, YUY2 and YV12 and how it relates to colorimetry.

In the core Avisynth colorimetry, i.e Rec601, Rec709, PC.601 and PC.709, is only used in RGB <-> YUV conversions. For this Avisynth uses Rec601 as the default matrix. So existing scripts and application can always continue to function the same way this default will not be changed.

So if you decode a stream into Avisynth as YUY2/YV12, process and edit in YUY2/YV12 and output to another app as YUY2/YV12 there will be no colorimetry change.

There are 3rd party plugins, like ColorMatrix that can directly adjust the colorimetry of YUV data. This is similar to adjusting the saturation, brightness, contrast or hue.

[stealth82]

Scusa stealth è che sono invetrato a capire cosa sia il rec 601 e 709 e relativi spazi colore/gamut.
Ed in teoria un dvd è encodato in 601 e come tale dovrebbe essere decodato.

Il problema è che entrano in gioco molti altri fattori quando si parla di HTPC, o computer in generale...

If the source is not the same colorimetry as the software or hardware you will be using to play it back (whatever eventually does the conversion to rgb) assumes it is then you will need to use colormatrix. It all has to do with what colorimetry is assumed when the eventual conversion to rgb occurs. If rgb is converted to yuv using one set of coefficients and the yuv is later converted back to rgb using a different set then this is where problems arise and is the reason colormatrix exists (since most software/hardware assume one specific set of coefficients and cannot use others). In the pc playback chain rec.601 is almost always assumed, but the typical dvd uses rec.709.

Pur se sì è sicuri di lavorare, dall'inizio alla fine, nel medesimo spazio colore.

[ciuchino]

"but the typical dvd uses rec.709"

Che in authoring facciano boiate e' vero ma che un tipico DVD SD usi quello ... mah

You are factually mistaken about this. It most certainly is at Studio levels. Video levels are 16-235, that is defined explicitly by SMPTE, and all DVD and HD video content that is properly mastered is encoded using Rec 601 and 709 standards which use video levels(obviously, since they are video). To retain proper playback, you should maintain studio levels if at all possible. Otherwise you clip head and toeroom, and inevitably introduce banding if you're doing an expansion to PC level (which decreases dynamic range) in 8-bit.


http://www.theatertek.com/Forums/showthread.php?t=10186