Best downsize? Best filter? Best codec? with SSIM

[redfordxx]

Hello,

I will encode LotR TT and I've been thinking about how. Reading some content here in D9, some comparisons, some advices, some as "Nothing is best --- everybody has a different opinion...", I decided to find my best opinion.
I know, it will be many days and nights of processing time, so maybe I loose the strenght and stop suddenly. Apologies before.

Two reasons to publish:
1. Someone can make use of it.
2. You can help me to find better way to goal. PLEASE for suggestions, what to do better way.

Main idea:
For compressing video are used few steps:
1.Filtering
2.Resizing
3.Encoding (choosing codec, options, matrix)

Some filtering can improve quality but too much is too much;-) Downsizing is the same. Where is the best point?

****************************
As an original I consider dvd after deblocking
I add some post with my setup and scripts, so you can better follow.
*****************************

First I decided to find out, what resizing is the best.
I thought, that downsize exactly 2:3 or 3:4 etc. should be better than some more complicated fractions. See later post.

*****************************
*****************************

I will all test with SSIM. There are few possible test i can imagine.
0. SSIM(o,c1 us) ....... quality of the 1pass
1. SSIM(o,o ds us)...... downsizing efficiency
2. SSIM(o f ds, o ds) .. filters impact
3. SSIM(o,c2 us) ....... quality of the 2pass
4. SSIM(o f,c2 us) ..... quality of the 2pass (filters ignored)
5. SSIM(o ds,c2) ....... quality of the 2pass (downsize ignored)
6. SSIM(o f ds,c2) ..... quality of the 2pass (filters and downsize ignored)
7. SSIM(c2 dbl,c2) ..... blockiness of the 2pass
8. SSIM(c1 dbl,c1) ..... blockiness of the 1pass
9. SSIM(o fs,o ds fs)... similar to 1, on a fullscreen level (=equivalent of resizing 720 to 1280 horizontally, vertically anamorph related)


(o=original, c1=compressed 1stpass, c2=compressed 2ndpass, ds=downsized, us=upsized,f=filtered, fs=upsized to fullscreen, dbl=deblocking filter)

[Spyn]

hum i don't understand what's your goal and tests that you want to do...

if your source is clean, filtering (denoise) will only increase compressibility but may loose some details.

resizing : use lanczos or bicubic if the compressibility is not high enough

codec : at very low and maybe low bitrate RV10 will give the better quality else use Xvid

[redfordxx]

SW:
WinXP SP2
GKnot 0.33.1, I'll upgrade soon, but it shouldnot manipulate the results.
XviD-1.1.0-Beta1-16012005
My default: H263, B-f:2-1.5-1, Motion 6,4,VHQ for Bf, Chroma, Trellis, 1-31 --- other things off
AviSynth 2.55 (EDIT: upgraded to 2.56)

HW:
Athlon XP 2500+

Source:
LotR TTT EE 712x424@25 plus black bars around.
this is what i consider source for all further:
o-full.avs
# PLUGINS
LoadPlugin("C:\PROGRA~1\MULTIM~1\GORDIA~1\AviSynthPlugins\dgdecode.dll")
LoadVirtualdubPlugin("C:\Program Files\Multimedia\GordianKnot\VirtualDubMod\plugins\\deblock.vdf", "MSUDeBlock")

mpeg2source("D:\record\rip\lotr tt\1\tt1.d2v")
trim(1000,60000)
SelectRangeEvery(11000,3500)
crop(0,64,720,448)
ConvertToRGB32()
MSUDeBlock(1,1,1)
crop(4,12,712,424)
ConvertBackToYUY2()

Target for these 21000 frames is 157700kB-->whole movie to 4CDs.
For comparison I use only 688x416 in te middle of the video.


Example of comparison script (test 3)
c560x280-3.avs
# PLUGINS
LoadPlugin("C:\PROGRA~1\MULTIM~1\GORDIA~1\AviSynthPlugins\dgdecode.dll")
LoadPlugin("C:\PROGRA~1\MULTIM~1\GORDIA~1\AviSynthPlugins\SSIM.dll")

o=AVISource("D:\record\rip\lotr tt\final\test3\o.avs").trim(0,20990).ConvertToYV12

c=AVISource("D:\record\rip\lotr tt\final\test3\560x280\o560x280.avi").trim(0,20990).LanczosResize(700,420).crop(6,2,688,416)

return ssim(o,c,"r560x280-3.csv","a560x280-3.txt",lumimask=true)

[redfordxx]

Originally posted by Spyn
hum i don't understand what's your goal and tests that you want to do...

if your source is clean, filtering (denoise) will only increase compressibility but may loose some details.

resizing : use lanczos or bicubic if the compressibility is not high enough

codec : at very low and maybe low bitrate RV10 will give the better quality else use Xvid
wait a little...

[redfordxx]

Example of what I mean:
For "resizing efficiency" I used test like this
c616x296-1.avs
# PLUGINS
LoadPlugin("C:\PROGRA~1\MULTIM~1\GORDIA~1\AviSynthPlugins\dgdecode.dll")
LoadPlugin("C:\PROGRA~1\MULTIM~1\GORDIA~1\AviSynthPlugins\SSIM.dll")
LoadVirtualdubPlugin("C:\Program Files\Multimedia\GordianKnot\VirtualDubMod\plugins\\deblock.vdf", "MSUDeBlock")

mpeg2source("D:\record\rip\lotr tt\1\tt1.d2v")
trim(1000,60000)
SelectRangeEvery(11000,3500)
trim(0,20990)
ConvertToRGB32()
o=MSUDeBlock(1,1,1)

c=o.crop(8,77,704,440).LanczosResize(616,308).ConvertBackToYUY2().LanczosResize(704,440).crop(8,3,688,416).ConvertToYV12

o=o.ConvertBackToYUY2().crop(16,80,688,416).ConvertToYV12

return ssim(o,c,"r616x296v2-1.csv","a616x296v2-1.txt",lumimask=true)


All resizes I did without aspect error, in extreme cases using construction as.
crop(0,77,720,440)
AddBorders(0,0,180,0,0)
LanczosResize(896,308)
crop(8,0,704,296)



Tested resolutions (crop used before)
encoding res /display res / AR /H dwnsize / V dwnsize
704:416 1000:416 142,2% 100,0% 100,0%
704:336 800:336 113,8% 100,0% 80,0%
568:336 806:336 142,2% 80,0% 80,0%
704:312 750:312 106,7% 100,0% 75,0%
568:312 756:312 133,3% 80,0% 75,0%
528:312 750:312 142,2% 75,0% 75,0%
632:304 718:304 113,8% 90,0% 72,0%
704:296 704:296 100,0% 100,0% 70,3%
704:296v 704:296 100,0% 99,6% 70,0%
704:296v2 704:298 99,6% 100,0% 70,0%
616:296 700:296 113,8% 87,5% 70,0%
704:280 704:296 94,8% 100,0% 66,7%
672:280 672:280 100,0% 94,8% 66,7%
592:280 672:280 113,8% 83,3% 66,7%
568:280 672:280 118,5% 80,0% 66,7%
528:280 666:280 126,4% 75,0% 66,7%
472:280 670:280 142,2% 66,7% 66,7%


The interim partial results are here. Not all values filled, so the lines jump to zero... The items are sorted by 1passQ2 size (as for downsize used various crops, it was normalized --- to full picture). Left is biggest 1pass:
http://img210.exs.cx/img210/9320/downsize12ee.th.png (http://img210.exs.cx/my.php?loc=img210&image=downsize12ee.png)

Names of the items are HxV_??? (???=dflt... my default settings described in setup post, or descripion of differecne from dftl, e.g. d=v3hr=using EQM V3HR)
Trying to explain...:
*_0,1... means SSIM test value according to numbered description above with QPel off/on. (so Dflt_3 and QPel_3 are most interesting for final pass quality)
?1P_*... 1. pass values
?2P_*... 2. pass values
sizeMB... filesize
kpx size..pixel size of the picture (H*V)/1024
bpp... bit/pixel/frame
cmpr.ratio...

Don't kill me for using SSIM now, wait a little. For me visual comparison comes as last.



OK, not finished, but still some first observations:
1. Not always more downsize=more complessibility (compare trends of F1P-sizeMB and F1P-kpx) If downsize really necessary, 2/3 vertical seems to have good results

2. H.263 outperforms V3HR even at 472x280, where the V3HR cmpr.ratio is 81,5%. V3HR's claimed to be high bitrate maxtrix --- I think compression at 81.5% can be considered high bitrate. (Visualtest confirmed).

3. QPel decreases quality & compressibility(i.e. 1pass size) @704x416 but increases quality & compressibility (-5% of 1pass size) @ 472x280(=44%of704x416).

To be updated. Of course, conclusion can be differen after applying filters, denoisers... now it is only deblocked VOB.

EDIT: As nobody is much interested and i have to solve other issues (deblocking and colors) I stop publishing for now (or forever)

[Manao]

Those threads might interest you :

http://forum.doom9.org/showthread.php?s=&postid=412947&highlight=ssim#post412947
http://forum.doom9.org/showthread.php?s=&threadid=62332&perpage=20&highlight=ssim&pagenumber=1

[redfordxx]

Originally posted by Manao
Those threads might interest you :

http://forum.doom9.org/showthread.php?s=&postid=412947&highlight=ssim#post412947

The second one I saw, this one I missed though I searched... much thanks, maybe I little postpone my tests...

Pls, how about adding the picture to post, does anybody advice?

[Didée]

Originally posted by redfordxx
Pls, how about adding the picture to post, does anybody advice?
www.imageshack.us

Are you planning to finish testing within this year?

How long is the source - is it the theatre version, or the EE one?

Then, since you're after optimal quality, I wonder why you're doing the YV12->RGB->YUY2 journey ...

A rather quick way to get a really fine result, and have much more time for other things, would be:

Mpeg2Source( ... , cpu=2,moderat_h=40,moderate_v=50)
crop(4,76,-4,-76)
ColorMatrix()
FluxSmoothT(1)
LanczosResize(720,432, 0,2,712,422)
Limiter()

Feed that script to Vdub, choose XviD, load - just for example :) - SixOfNine as custom matrix, use defaults but +qpel, Bframes 2/1.5/0.5, sensitivity -1, VHQ4, VHQ for B's, chroma motion, Trellis. Do a 1st pass with quantizer 3 (through the zone settings). Do the 2nd pass to target size with that zone re-set to weight=1.0, all min/max quantizers @ 2/5, and put 10/10 in the curve compression field of 2nd pass' register.

After having done that, run all all your tests and see (with your eyes lloking at the movie, not at any metrics tables) how much you can further improve.

Room for improvement is plenty, I've encoded that source with several somewhat more complex scripts ;) But improvement makes only tiny steps, in the region of thin air.

[redfordxx]

Thanks much for help.
Originally posted by Didée

Are you planning to finish testing within this year?
I am not doing whole movie...

How long is the source - is it the theatre version, or the EE one?
EE

Then, since you're after optimal quality, I wonder why you're doing the
YV12->RGB->YUY2 journey ...
YV12->RGB(deblocking)->YUY2(some filters)->YV12(SSIM) --- in the brackets are operations which require these colors.
BTW: YV12->RGB->YUY2->YV12 conversion looses small quality (SSIM=99.94%)


Do a 1st pass with quantizer 3 (through the zone settings). Do the 2nd pass to target
size with that zone re-set to weight=1.0, all min/max quantizers @ 2/5,
and put 10/10 in the curve compression field of 2nd pass' register.
What is the benefit of setting 1pass quantizer to something? I thought only 2nd pass is important.
After having done that, run all all your tests and see (with your
eyes lloking at the movie, not at any metrics tables) how
much you can further improve.
I know metrics are not all. But it helps. Instead of having head as a baloon from watching the same video many times.

Room for improvement is plenty, I've encoded that source with several
somewhat more complex scripts ;)
Maybe it would be best to raise question in the forum, what are best settings for LotR's EE...;)

[redfordxx]

Originally posted by Didée
Mpeg2Source( ... , cpu=2,moderat_h=40,moderate_v=50)
I tried this. I looked quickly on some first frames, but really nothing special.
MSUDeBlock(1,1,1) really removes 99% blocks, preserves details and does not create gradients. Faaaar from what DGDecode deblocker does.Try it.

ColorMatrix()
I also tried (and read few posts in ColorMatrix v1.9 thread).
To see what it does I loaded to VDMod and compared 3 sources.
VOB, AVS with and without Colormatrix.
All three slightly different colors... conclusion...?

LanczosResize(720,432, 0,2,712,422)
Just why upszing?

[Didée]

Originally posted by redfordxx
What is the benefit of setting 1pass quantizer to something? I thought only 2nd pass is important. Explained e.g. here (http://forum.doom9.org/showthread.php?s=&threadid=83061).


BTW: YV12->RGB->YUY2->YV12 conversion looses small quality (SSIM=99.94%)Yeah, that's metrics. You are loosing tonalities through that forth-and-back conversion. With some bad luck, one can even notice enhanced banding effects in flat and near-black areas. But that doesn't matter, if only the metrics are good :rolleyes:


Thinking about it, FluxSmoothT(1) eventually is alittle too weak for that source, considering that your're aiming for a bitrate in the 1500 kpbs range. Probably LRemoveDust (http://forum.doom9.org/showthread.php?s=&postid=620669#post620669) with a setting of (4,1) would be suited for that target.

[Didée]

Originally posted by redfordxx
I tried this. I looked quickly on some first frames, but really nothing special. Possible. Those were rather passive settings with relative high 'moderate'-values. Mind that defaults are h=20 and v=40.


MSUDeBlock [...cheering, raving ... ]
Try it.Have been there before, sure. Shows some nice potential, but doesn't really impress me, either. Plus, I'm kinda allergic against that "black box principle" of MSU's filters. And I'm not a fan of processing YV12 sources in or through RGB.
Kicking the ball back to you -- have you already tried the h.264-technique deblocking routines, as implemented in MVTools and latest DGDecode builds? These are also very feasable alternatives.

However, you made me thinking about deblocking once more - and just this time I had a wonderful idea for a new "BlindDeBlock" filter chain ;)
Thank you very much! :) :)


Just why upszing? Just why downsizing?

[redfordxx]

Originally posted by Didée
Yeah, that's metrics. You are loosing tonalities through that forth-and-back conversion. With some bad luck, one can even notice enhanced banding effects in flat and near-black areas. But that doesn't matter, if only the metrics are good :rolleyes:
Again. I know metrics are not everything. But it helps. Instead of having head as a baloon from watching the same video many times. Kinda semifinal contest;)

In fact, I thought YV12-->RGB32 cannot have problem, since RGB32 contains full image information and in YV12 some pixels "share" information...

[redfordxx]

Originally posted by Didée
Possible. Those were rather passive settings with relative high 'moderate'-values. Mind that defaults are h=20 and v=40.Did try too. Thats about killing the detail, I wrote...

implemented in MVToolsI saw, tried but probably misunderstood and had no results.

DGDecode buildsI use with this MPEG2Source, I guess...

However, you made me thinking about deblocking once more - and just this time I had a wonderful idea for a new "BlindDeBlock" filter chain ;)
Thank you very much! :) :)I'm honored;)
+I would be interested.

Just why downsizing? Sure you know to save bits/pixel, But upsizing...?

[Spyn]

Originally posted by redfordxx

In fact, I thought YV12-->RGB32 cannot have problem, since RGB32 contains full image information and in YV12 some pixels "share" information...

this is not the problem, by converting colorspace you don't get exactly the same colors because conversion is approximate.

[redfordxx]

Originally posted by Spyn
this is not the problem, by converting colorspace you don't get exactly the same colors because conversion is approximate.
I seeee. I suppose YV12<-->YUY2 is not that case...
And concerning RGB32, maybe that's what ConvertBackToYUY2 is trying to solve (ofcourse only when coming back). Definitely it gives then much better results than ConvertToYUY2.

[Didée]

Originally posted by redfordxx
In fact, I thought YV12-->RGB32 cannot have problem, since RGB32 contains full image information and in YV12 some pixels "share" information...
Mate, go figure. It's a long-bearded story that YUV-RGB conversions looses information, and if the conversion can be avoided, the best thing to do IS to avoid it ...


But if it has to be by all means, then at least you should use full-range conversion. Standard conversion maps intervals [16,235] <--> [0,255] onto each other on forth and back conversions. That's my main issue here: YUV-->RGB creates "gaps" in a frame's histogram, the tonality range is no more smooth. Then one does some processing in RGB, which will "smear" those gaps. Then on backconversion to YUV, the (somewhat artificially) smoothed tonality range will melt some values together, because of the [0,255]-->[16,235] mapping. This is where the banding is created.

Have a closer look at AviSynth's documentation about "ConvertToXYZ", and choose a conversion mode that maps full range [0,255]<-->[0,255] in both directions. If the conversion is only an intermediate step, this should be the better deal.

[Spyn]

you must use avisynth 2.56 and add matrix="pc.601" to the convert line to keep [0-255] luminance values.

In v2.56, matrix="pc.601" (and matrix="pc.709") enables you to do the RGB <-> YUV conversion while keeping the luma range, thus RGB [0,255] <-> YUV [0,255] (instead of the usual/default RGB [0,255] <-> YUV [16,235]).

http://www.avisynth.org/Convert

[redfordxx]

Because of some of your posts I looked again at these colors...

1. Still think MSUDeblocker the best one.
2. For using it I need RGB32.
3. The best picture has *.vob opened directly in VDMod. It seems to me, that VDMod opens the vob directly in RGB (hence I suppose vob is RGB---I nowhere found that info). I can't see the 2x2 YV12 matrix, which i see on avs files in VDM.
4. By combining ColorMatrix and ConvertToX's I obtain many variations of colours;-) Hard to tell which is the "real" one or "original" ... It would be best to open the vob directly in VDM and compress it. But I could probably miss some filters present in AVS...

[Spyn]

Originally posted by redfordxx
Because of some of your posts I looked again at these colors...

1. Still think MSUDeblocker the best one.
2. For using it I need RGB32.
3. The best picture has *.vob opened directly in VDMod. It seems to me, that VDMod opens the vob directly in RGB (hence I suppose vob is RGB---I nowhere found that info). I can't see the 2x2 YV12 matrix, which i see on avs files in VDM.
4. By combining ColorMatrix and ConvertToX's I obtain many variations of colours;-) Hard to tell which is the "real" one or "original" ... It would be best to open the vob directly in VDM and compress it. But I could probably miss some filters present in AVS...

DVDs (.vobs) are 99% (100% ?) YV12, virtualdubmod convert to RGB only for display.

use fast-recompress if you want the colorspace stay YV12, full processing mode will convert to RGB32.

[Sharktooth]

... and the codec will usually reconvert to yv12... so you loose data 2 times...

[Spyn]

so conversions are :
YV12 -> RGB32 -> YUY2 -> YV12

think this is a bit too much :D

[Japhsoncross]

i've got a question here.
is there any differences between the "fast re-compress","normal re-compress" and "full processing mode" if the source is simply YV12?

[Sharktooth]

Yes, the same color conversion applies.

[Japhsoncross]

so, if i want to achieve the most original color as source, which processing mode should i use(source is yv12)?

[Sharktooth]

Always Fast Recompress.

[Japhsoncross]

i get it. :) thx

[redfordxx]

Originally posted by Spyn
DVDs (.vobs) are 99% (100% ?) YV12, virtualdubmod convert to RGB only for display.
use fast-recompress if you want the colorspace stay YV12, full processing mode will convert to RGB32.
Thanx, useful info.


Originally posted by Spyn
so conversions are :
YV12 -> RGB32 -> YUY2 -> YV12

think this is a bit too much :D
It's just once going to RGB32 --- nothing more. Going back thru YUY2 is for having benefit from function ConvertBackToYUY2, because ConvertBackToYV12 doesn't exist. It has better result.



Originally posted by Japhsoncross
i've got a question here.
is there any differences between the "fast re-compress","normal re-compress" and "full processing mode" if the source is simply YV12?

As Spyn wrote. Fast recompress is to avoid default VDB to-RGB conversion. However U cant use filters.

I think most similar to source is original-native-YV12-->avs-->VDB-fast-recompress-->XviD

I compared it on FFDShow(even for *.vob) capture of one frame (full of fire) in BSPlayer. No ColorMatrix (it was worse) or other things like that. Then, again, can't see the benefit of ColorMatrix.

[Didée]

Originally posted by redfordxx
Then, again, can't see the benefit of ColorMatrix.
Then I strongly suggest to have a closer look at ColorMatrix' documentation, and its thread. Wildly poking around makes little sense. The topic is more complex.

[Spyn]

Originally posted by redfordxx

As Spyn wrote. Fast recompress is to avoid default VDB to-RGB conversion. However U cant use filters.




there is many filters working with YV12, see http://www.avisynth.org/warpenterprises/

Originally posted by redfordxx

I think most similar to source is original-native-YV12-->avs-->VDB-fast-recompress-->XviD



yes, no colorconversion = better quality.

[Japhsoncross]

i've just made a test, i encode a clip with xvid using both fast re-compress and full processing mode. then i compare the two with the source by capturing the same frame. the one using the full processing mode does have chroma loss, it looks a bit darker. using the full processing mode if the source is yv12 makes noticeable loss.

so the loss of YV12->RGB32->YV12 can be noticed.

[Spyn]

maybe vdubmod don't use the same algorithm than Avisynth "ConvertToXX"

this could be a good test.

[Japhsoncross]

another test:
"ConvertToRGB24()
ConvertToYV12()" for 7 times in my avs script.
the result seems that the chroma blurs and moves a lot.

[Sharktooth]

Everytime you do a color conversion you're loosing data.

[redfordxx]

Originally posted by Didée
Then I strongly suggest to have a closer look at ColorMatrix'
documentation, and its thread. Wildly poking around makes little sense. The
topic is more complex.

Of course I poked before... saw many expressions of gratitude etc... that it
helps to repair colors...

But, still I see what I see (No metrics, Didée!).
The capture frame from xvid.avi w/o ColorMatrix is much more similar to
capture frame from vob, than capture frame from xvid.avi with ColorMatrix. I
made same test as Japhsoncross before, moreover with ColorMatrix. (XviD, Q1,
no Bframes) And, as Intervideo makes some postprocessing already, I played
vob with FFDShow too.

I have GKnot 0.35 so I suppose I have DGDecode 1.2.1.
When I look in d2v, first line I see is:
c00 1 0 2048 1 1 b2 b2 92 b2 b2 a2 b2 b2 a2 b2 b2 a2 b2 b2 a2
so I suppose it's ITU-R BT.709. Mpeg2source(...., info=1) confirms it.
So it should be ColorMatrix w/o param. However, I tried ColorMatrix(d2v="D:\record\rip\lotr tt\1\tt1.d2v") too and result the same:

XviD FFDShow capture with ColorMatrix is significantly "brighter" than both Intervideo and FFDShow captures of vob. Conclusion - one of following:
1. FFDShow and Intervideo capture MPEG2.VOB incorrectly
2. FFDShow captures XviD.avi incorrectly
3. ColorMatrix does not do the job I suppose.
4. ???
Which one is it? Suggestions?

[redfordxx]

Originally posted by Japhsoncross
another test:
"ConvertToRGB24()
ConvertToYV12()" for 7 times in my avs script.
the result seems that the chroma blurs and moves a lot.
When U really need to go to RGB(32?) (as I do at the moment and as always when U need Virtualdubplugin in avs) use ConvertBackToYUY2 for going back and then ConvertToYV12. It's much better.

[Sharktooth]

Virtualdub plugins?!? omg...
Ok, get rid of any virtualdub plugins and any yuv->rgb->yuv conversion.
Always keep it YUV! It's faster, wont loose quality and filters are faster too!

[redfordxx]

Originally posted by Sharktooth
Virtualdub plugins?!? omg...
Ok, get rid of any virtualdub plugins and any yuv->rgb->yuv conversion.
Always keep it YUV! It's faster, wont loose quality and filters are faster too!
Fully agree
I would do it immediately provided someone shows me better deblocker than that in VDM by MSU.

[Spyn]

what msudeblock do ?

denoising, reduce dct blocks ... ?

[redfordxx]

Originally posted by Spyn
what msudeblock do ?

denoising, reduce dct blocks ... ?

Not sure what is DCT, but it nicely removes blocks visible in e.g. MPEG2 (8x8pix in this case...) Then both the picture and compressibility are better.

But even when I deblock anyhow in YV12, I still cannot figure out my last question regarding ColorMatrix

[Spyn]

please post screenshots before / after MsuDeblock without any other filters.

i think this is a type of denoiser.

DCT blocks are ugly moving blocks in dark areas.

[redfordxx]

Originally posted by Spyn
please post screenshots
how?
U know, I'm Junior member;)

[Spyn]

Originally posted by redfordxx
how?
U know, I'm Junior member;)

open your script in vdubmmod, press the printscreen touch, open photoshop or other image editor, make a new document, paste the image (ctrl+v), save image as png24 or bmp then use : http://imageshack.us/

[redfordxx]

Originally posted by Spyn
please post screenshots before / after MsuDeblock without any other filters.

i think this is a type of denoiser.

DCT blocks are ugly moving blocks in dark areas.

I did avs-->bsp-->capture
Double size it nin ACDSee and easily find difference

yv12
http://img175.exs.cx/img175/5687/orig3jm.th.png (http://img175.exs.cx/my.php?loc=img175&image=orig3jm.png)
yv12-->rgb32-->yuy2-->yv12
http://img175.exs.cx/img175/1779/origrgb32yv123au.th.png (http://img175.exs.cx/my.php?loc=img175&image=origrgb32yv123au.png)
yv12-->rgb32-->dblck-->yuy2-->yv12
http://img154.exs.cx/img154/7503/origrgb32dblckyv122ic.th.png (http://img154.exs.cx/my.php?loc=img154&image=origrgb32dblckyv122ic.png)

My avs:
LoadPlugin("C:\PROGRA~1\MULTIM~1\GORDIA~1\AviSynthPlugins\dgdecode.dll")
LoadVirtualdubPlugin("C:\Program Files\Multimedia\GordianKnot\VirtualDubMod\plugins\deblock.vdf", "MSUDeBlock")

mpeg2source("D:\record\rip\lotr tt\1\tt1.d2v")
trim(4992,5041)
ConvertToRGB32(matrix="pc.709")
MSUDeBlock(1,1,1)
crop(16,80,688,416)
ConvertBackToYUY2(matrix="pc.709")
ConvertToYV12()


If there would be ConvertBackToYUY2(matrix="pc.601") instead, I get the effect of Colormatrix also... But then it is brighter...

[Spyn]

i don't think this is a good frame to see the effect, maybe a bit of sharpness...

[redfordxx]

Originally posted by Spyn
i don't think this is a good frame to see the effect, maybe a bit of sharpness...
Then I am sorry.
With all respect, I won't be repeating it until I match your taste.
I must say, during the day I can't find the difference that easily on my LCD, but when it's a little dark, it is visible on many spots (with fast switching the pictures).

[redfordxx]

I entered first graph.
I'll let my comp finish comparison and then I plan to pick few best candidades for further testing (=changing filters, setting, matrices) where I appreciate your tips.
Maybe some DivX5 fan can provide me with some info on DivX5.0 codec "best settings" to be applied for this "competition".

[Boulder]

You must specify the appropriate mode for ColorMatrix.

If you use CCE, it would be ColorMatrix(mode="rec.601->rec.709",d2v="path\clip.d2v")

By default the mode is rec.709->rec.601 which is incorrect for CCE since it expects rec.709 coefficients have been used.

[Spyn]

i don't think you will prove anything.

for best result :
- stay at YV12 during all the encode process
- even if nobody says it clearly to keep the free will, xvid is better than divx
- if source is clean no filters are needed or maybe very light denoiser like convolution3d + very light sharpen filter

[redfordxx]

Originally posted by Spyn
DCT blocks are ugly moving blocks in dark areas.
I saw somwhere scripts with
MPEG2Source(...,idct=2)...

I have in my d2v file
iDCT_Algorithm=2 (1:MMX 2:SSEMMX 3:FPU 4:REF 5:SSE2MMX)

Is that the same and I can use MPEG2Source w/o idct=2?