Comparison : 2 / 3 pass & --me umh / esa

[le_canz]

I was wondering how useful were the 3 pass method over most common 2 pass, and the insane option --me esa over --me umh when used for 2 and 3 pass encoding.

For info :

Core 2 E6600 @ 3.36 GHz
2 GB DDR2

I used 8 different samples :

Elephant's Dream sample, lossless source
640x360 with borders added so final resolution is 640x368

Fight Club sample, PAL DVD rip source
Deinterlaced, then Lanczos resized (virtualDub) to 1024x432 as the DVD is anamorphic

Pink Floyd - Live in Pompeii, PAL DVD rip source
Deinterlaced, then Lanczos resized (virtualDub) to 1024x576 as the DVD is anamorphic

Tool - Stinkfist, PAL DVD rip source
Deinterlaced 720x576

Plus 4 differents samples from my DV cam, all 720x576 and deinterlaced.

All samples have 3 000 frames, and all were deinterlaced with VirtualDub's Smart Deinterlace 2.8 filter. No smoother nor sharper filter used, except Motion Map Denoising from the deinterlace filter itself.

I used the following command lines for 2 pass :


x264.exe --progress --pass 1 --bitrate 1024 --keyint 250 --min-keyint 25 --vbv-maxrate 4096 --vbv-bufsize 14745 --aud --sar 1:1 --mixed-refs --direct auto --qcomp 0.65 --fps 25 --b-pyramid --ref 5 --bframes 16 --weightb --bime --no-fast-pskip --no-dct-decimate --me dia --merange 20 --subme 7 --b-rdo --trellis 0 --partitions none --stats x264_stat.log --thread-input --threads 1 --output NUL script.avs

x264.exe --progress --pass 2 --bitrate 1024 --keyint 250 --min-keyint 25 --vbv-maxrate 4096 --vbv-bufsize 14745 --aud --sar 1:1 --mixed-refs --direct auto --qcomp 0.65 --fps 25 --b-pyramid --ref 5 --bframes 16 --weightb --bime --no-fast-pskip --no-dct-decimate --me [esa or umh] --merange 20 --subme 7 --b-rdo --trellis 2 --partitions all --8x8dct --stats x264_stat.log --thread-input --threads 1 --output result.264 script.avs


And for 3 pass :


x264.exe --progress --pass 1 --bitrate 1024 --keyint 250 --min-keyint 25 --vbv-maxrate 4096 --vbv-bufsize 14745 --aud --sar 1:1 --mixed-refs --direct auto --qcomp 0.65 --fps 25 --b-pyramid --ref 5 --bframes 16 --weightb --bime --no-fast-pskip --no-dct-decimate --me dia --merange 20 --subme 7 --b-rdo --trellis 0 --partitions none --stats x264_stat.log --thread-input --threads 1 --output NUL script.avs

x264.exe --progress --pass 3 --bitrate 1024 --keyint 250 --min-keyint 25 --vbv-maxrate 4096 --vbv-bufsize 14745 --aud --sar 1:1 --mixed-refs --direct auto --qcomp 0.65 --fps 25 --b-pyramid --ref 5 --bframes 16 --weightb --bime --no-fast-pskip --no-dct-decimate --me [esa or umh] --merange 20 --subme 7 --b-rdo --trellis 2 --partitions all --8x8dct --stats x264_stat.log --thread-input --threads 1 --output result.264 script.avs

x264.exe --progress --pass 2 --bitrate 1024 --keyint 250 --min-keyint 25 --vbv-maxrate 4096 --vbv-bufsize 14745 --aud --sar 1:1 --mixed-refs --direct auto --qcomp 0.65 --fps 25 --b-pyramid --ref 5 --bframes 16 --weightb --bime --no-fast-pskip --no-dct-decimate --me [esa or umh] --merange 20 --subme 7 --b-rdo --trellis 2 --partitions all --8x8dct --stats x264_stat.log --thread-input --threads 1 --output result.264 script.avs


Results for the average of all :

2 pass --me umh is the reference quality, with 100 %

http://img241.imageshack.us/img241/9722/resultscropiq8.png

So as you see, using more aggressive settings than --me umh / 2 pass is quite useless :-p

Results for each samples are quite close, so I think posting them is not worth.

Edit : added logs :

http://rapidshare.com/files/58885200/logs.7z.html

[Dark Shikari]

Depends on the source... some sources hardly benefit at all from ESA, others moreso.

And same with 3-pass; some sources benefit a lot from 3-pass, others less so.

Overall benefits are pretty small though.

[Manao]

PSNRs should never be divided by one another. Only PSNR differences have a sense. The same applies to SSIM.

[le_canz]

Depends on the source... some sources hardly benefit at all from ESA, others moreso.

The highest increase is for Elephant's Dream. For all others, that makes almost no difference. I'll post details later.

PSNRs should never be divided by one another. Only PSNR differences have a sense. The same applies to SSIM.

Could you explain a bit more please ?

[CruNcher]

The highest increase is for Elephant's Dream. For all others, that makes almost no difference. I'll post details later.

Doesn't suprise me @ all as the others are allready compressed

[akupenguin]

The same applies to SSIM.
Except that for SSIM neither ratios nor differences are meaningful, you need a more complex formula.

[Dark Shikari]

Except that for SSIM neither ratios nor differences are meaningful, you need a more complex formula.Correct. Here's a good formula:

Ratio = (1 / (1-NewSSIM)) / (1 / (1-OldSSIM))

[nm]

(1 / (1-NewSSIM)) / (1 / (1-OldSSIM)) = (1-OldSSIM) / (1-NewSSIM)

Isn't that almost the same thing as using a straight ratio? Is there a theoretical basis for this formula?

[Manao]

Yes, OldSSIM / NewSSIM wasn't given usable results :p

[Dark Shikari]

(1 / (1-NewSSIM)) / (1 / (1-OldSSIM)) = (1-OldSSIM) / (1-NewSSIM)

Isn't that almost the same thing as using a straight ratio? Is there a theoretical basis for this formula?Its because 0.98 = twice as good as 0.96.

By a straight ratio, 1.0 would be twice as good as 0.5.

[le_canz]

Ratio = (1 / (1-NewSSIM)) / (1 / (1-OldSSIM))

Why is this formula better, please ? :confused:

Edit : Ok, I should have hit F5 before posting :p

[Manao]

Its because 0.98 = twice as good as 0.96.No. It's because you decided that 0.98 was twice as good as 0.96.

[Dark Shikari]

No. It's because you decided that 0.98 was twice as good as 0.96.But that's the point of the SSIM scale, isn't it? Its an inverse scale, where 1.0 is perfect correlation with the source and 0 is no correlation, and by definition since its an inverse scale, 0.98 has to be half the error of 0.96.

You could choose to interpret it differently, but mathematically you'd probably be wrong.

Now of course one could question whether "half the error" = "twice as good." However in my experience it requires roughly twice the bitrate to achieve half the error, which puts it on a roughly linear curve. Note this is not exact or guaranteed in all cases, and the curve is slightly nonlinear if you go from very low to very high bitrate.