[New patch] Hadamard motion estimation

[Dark Shikari]

This patch adds the --hadamard option, which uses a a Hadamard-transform-based motion search instead of SAD (Sum of Absolute Differences). Basically what this option does is use SATD everywhere that SAD is currently used. Depending on the motion search and reference frame settings, this has a varying effect on quality and speed. Its probably equivalent to the Microsoft VC-1 codec "Hadamard" option.

On --me hex with few reference frames, the slowdown could be very small, while on --me umh with a whole bunch of reference frames the slowdown can be well over 50%. I would recommend using this option particularly when you find yourself using very large numbers of reference frames; it is probably a lot better to use --hadamard and --ref 6 than --ref 16.

In terms of code, since I couldn't quickly think up a simple way of dynamically swapping the metric functions in the motion estimation functions themselves without using tons of if statements (which would cause a speed decrease even with --hadamard off!), I took the hackish approach of directly messing with pixel.c. This technically means that any function calling SAD is actually calling SATD. Fortunately, this doesn't seem to cause a problem, and works as far as I can tell.

It raises quality a small amount. Bitrate is sometimes raised, sometimes lowered; it depends on the sound. If --hadamard is compared with a normal encode at the same bitrate, by using ABR instead of CRF mode, the quality (SSIM) boost ranges from very little to as high as 2.5% depending on the source and the settings. PSNR usually, though not always, increases.

Get the patch here (http://tjhsst.edu/~jgarrett/hadamard.diff). Its for version 667b but should work for anything after (hopefully).

Update: Diff has been fixed so it can be run from the x264 source directory like it should be able to. Use patch -u -p1 <hadamard.diff

For those who can't get the patch to work, I patched the code myself and uploaded it here (http://tjhsst.edu/~jgarrett/x264_667b_AQ_Hadamard.7z). This is Cef's code so it includes all the other patches.

Update: we now have builds with the patch thanks to Wiz!

Uploaded the builds for everyone.
All builds are based off of Cef's 667b so they have all patches he uses (including AQ)
And since I aim to please, I've uploaded a few different versions although the speed difference should be minimal but you should download the appropriate build for your processor.
x264 generic (http://www.sendspace.com/file/2jl2w0) (generic build with mmx)
x264 P3 (http://www.sendspace.com/file/suxa6e) (generic build with mmx+sse)
x264 Pentium4 (http://www.sendspace.com/file/oq5jdy) (mmx, sse, sse2, tuned for pentium4)
x264 K8 (http://www.sendspace.com/file/v8idrx) (mmx, sse, sse2, tuned for k8)
Last but not least, experimental Core2 build (with -mssse3), built with GCC 4.3
x264 Core2 (experimental) (http://www.sendspace.com/file/pyi74g) (mmx, sse, sse2, sse3, ssse3, tuned for core2)

Built with GCC 4.2.1 (latest stable version) with avis input, mp4 output and pthreads (i.e. the only options that really matter to most end users... :))

Only had to add one more CFLAG to it. I built it with the -march=pentium2 to enable MMX support (since I think all the CPUs everyone uses here have MMX and the difference between MMX and the additional SSE+ ones are like 1% since most of it (the important stuff) is written in ASM anyway.

From Sharktooth:

I built it with most of those, march=pentium2 with -mmmx is redundent.
finline functions I believe is activated with -O3 so also redundent.
-funroll-loops I didn't add since I really don't know if it makes it faster or not. Most of the time this can bloat code. However in certain circumstances it can make code faster. I wanted to keep it simple so I didn't add it and it can vary from computer to computer.
ffast-math and -fomit-frame-pointer were also added (already there).

Also, all builds have two additional LDFLAGS to the default x264 ones. -Wl,-O1 and -Wl,--sort-common.

Enjoy.
Another update: a build with a fixed ESA algorithm, which works with --hadamard (--hadamard off it is unchanged) has been compiled by wiz. --me esa --hadamard is very very slow but will blow away any other motion estimation.
Do I need to recompile it again?

Edit:
Here:
x264 Hadamard fixed ESA build 667b x86 (32 bit) Generic (http://www.sendspace.com/file/h36ua8) (mmx support needed)

Too lazy right now to do like 5 builds. And I can't get the stupid 64bit compiler to work.
Another update: ESA with --hadamard is now about 2.27 times faster. It isn't 100% equivalent to the actual ESA algorithm, but all differences in terms of quality/bitrate are within an absolutely miniscule margin of error.

[akupenguin]

Its probably equivalent to the Microsoft VC-1 codec "Hadamard" option.
I care about matching ffmpeg much more than matching VC-1, so call it "--cmp satd" (the default of course being "--cmp sad").

In terms of code, since I couldn't quickly think up a simple way of dynamically swapping the metric functions in the motion estimation functions themselves without using tons of if statements (which would cause a speed decrease even with --hadamard off!)

You had almost the right idea, see pixf.mbcmp[]. Just give it a new set of variables and don't overwrite sad.


cosmetics:
The accepted diff format everywhere I code is -u, not -c.
No hard tabs.

[Dark Shikari]

You had almost the right idea, see pixf.mbcmp[]. Just give it a new set of variables and don't overwrite sad.

Explain--how do I, in me.c, dynamically tell the program to use satd instead of sad? Wouldn't I still need if statements? I.e.:


int cost;
if(p->analyse.hadamard) cost = h->pixf.satd[i_pixel]( m->p_fenc[0], FENC_STRIDE, &p_fref[(my)*m->i_stride[0]+(mx)], m->i_stride[0] ) + BITS_MVD(mx,my);
else
cost = h->pixf.sad[i_pixel]( m->p_fenc[0], FENC_STRIDE, &p_fref[(my)*m->i_stride[0]+(mx)], m->i_stride[0] ) + BITS_MVD(mx,my);
instead of
int cost = h->pixf.sad[i_pixel]( m->p_fenc[0], FENC_STRIDE, &p_fref[(my)*m->i_stride[0]+(mx)], m->i_stride[0] ) + BITS_MVD(mx,my);
?

cosmetics:
The accepted diff format everywhere I code is -u, not -c.
No hard tabs.Well the hard tabbing is easy to fix, as is the diff. A search and replace should resolve that.

[akupenguin]

int cost = h->pixf.fpelcmp[i_pixel]( m->p_fenc[0], FENC_STRIDE, &p_fref[(my)*m->i_stride[0]+(mx)], m->i_stride[0] ) + BITS_MVD(mx,my);

where pixf.fpelcmp is initialized either to pixf.sad or pixf.satd, in mbcmp_init().

[Dark Shikari]

int cost = h->pixf.fpelcmp[i_pixel]( m->p_fenc[0], FENC_STRIDE, &p_fref[(my)*m->i_stride[0]+(mx)], m->i_stride[0] ) + BITS_MVD(mx,my);

where pixf.fpelcmp is initialized either to pixf.sad or pixf.satd, in mbcmp_init().
Fixed, fixed, and fixed. Try it now, I totally rewrote the patch using your better method.

[Terranigma]

This is interesting. Last night while playing with the mainconcept h.264 avc encoder, I noticed this option; so I read the .pdf document to get a better understanding and it said:
This is an optimized cosine transformation. Activating the option, the clip will be encoded in better quality, and it will have a smaller file size So today, I was going to ask that this be implemented, but there's no need for me to do that now. Hopefully this'll make it in the next revision. :D

[Dark Shikari]

This is interesting. Last night while playing with the mainconcept h.264 avc encoder, I noticed this option; so I read the .pdf document to get a better understanding and it said:
So today, I was going to ask that this be implemented, but there's no need for me to do that now. Hopefully this'll make it in the next revision. :D
x264 already uses the Hadamard transformation as part of the subpixel refinement process. The reason it doesn't normally use it for the fullpel search is because its quite a bit slower, and if you're trying to optimize speed with quality (--subme 6, --me hex, etc) rather than trying to squeeze out every last bit of quality (--subme 7, --me umh, etc), using the Hadamard transform on the fullpel search would be a comparative waste of time.

One possibility would be to come up with some adaptive method of switching between them, as exists in VC-1. This would require a bit more code but could offer a nice compromise between --hadamard and the normal mode.

My tests do suggest that --hadamard with --ref 3 or 4, --subme 7, --no-fast-pskip, and --me umh might stay above 1 FPS on the MSU test system, so this patch could be used on the upcoming codec competition.

It would be nice to get a good make fprofiled, AQ-patched build with --hadamard if anyone here is up to the task.

[Sharktooth]

A fast generic build can be obtained using:

- GCC ver. 3.4.x

- pthreadw32

- cflags: -march=pentium2 -mmmx -O3 -finline-functions -funroll-loops -ffast-math -fomit-frame-pointer (some of them may be redundant)

- make fprofiled

Note: i also used to compile pthread AND gpac libs with -O3 -march=pentium2 -fomit-frame-pointer etc...

[TheRyuu]

common/pixel.c: In function 'x264_pixel_init':
common/pixel.c:643: error: expected ';' before 'pixf'
make: *** [common/pixel.o] Error 1

Compile error.

[Dark Shikari]

Oops, I accidentally deleted a single semicolon while editing the diff. C'mon you can fix that :p

pixf->satd_x3[PIXEL_8x8] = x264_pixel_satd_x3_8x8_ssse3;

is the correct line instead of

pixf->satd_x3[PIXEL_8x8] = x264_pixel_satd_x3_8x8_ssse3


The one-byte-differing diff has been re-uploaded ;)

[ChronoCross]

it's been awhile since I did patching so forgive me if this is stupid.

Here's the errors I got



$ patch -u -p1 <hadamard.diff
patching file `common/common.c'
Hunk #2 succeeded at 432 with fuzz 1 (offset -10 lines).
Hunk #3 succeeded at 889 (offset -13 lines).
patching file `common/pixel.c'
Hunk #1 succeeded at 322 (offset -8 lines).
Hunk #3 succeeded at 546 (offset -10 lines).
Hunk #4 FAILED at 579.
1 out of 5 hunks FAILED -- saving rejects to common/pixel.c.rej
patching file `common/pixel.h'
patching file `encoder/encoder.c'
Hunk #1 succeeded at 552 (offset -8 lines).
patching file `encoder/me.c'
patching file `x264.c'
Hunk #2 succeeded at 393 (offset -7 lines).
patching file `x264.h'
Hunk #1 succeeded at 214 (offset -1 lines).



***************
*** 511,520 ****
pixf->satd[PIXEL_16x16]= x264_pixel_satd_16x16_sse2;
pixf->satd[PIXEL_16x8] = x264_pixel_satd_16x8_sse2;
pixf->satd[PIXEL_8x16] = x264_pixel_satd_8x16_sse2;
pixf->satd[PIXEL_8x8] = x264_pixel_satd_8x8_sse2;
pixf->satd[PIXEL_8x4] = x264_pixel_satd_8x4_sse2;

//#ifdef ARCH_X86
pixf->sad_x3[PIXEL_16x16] = x264_pixel_sad_x3_16x16_sse2;
pixf->sad_x3[PIXEL_16x8 ] = x264_pixel_sad_x3_16x8_sse2;

--- 579,600 ----
pixf->satd[PIXEL_16x16]= x264_pixel_satd_16x16_sse2;
pixf->satd[PIXEL_16x8] = x264_pixel_satd_16x8_sse2;
pixf->satd[PIXEL_8x16] = x264_pixel_satd_8x16_sse2;
pixf->satd[PIXEL_8x8] = x264_pixel_satd_8x8_sse2;
pixf->satd[PIXEL_8x4] = x264_pixel_satd_8x4_sse2;
+
+ pixf->satd_x3[PIXEL_16x16]= x264_pixel_satd_x3_16x16_sse2;
+ pixf->satd_x3[PIXEL_16x8] = x264_pixel_satd_x3_16x8_sse2;
+ pixf->satd_x3[PIXEL_8x16] = x264_pixel_satd_x3_8x16_sse2;
+ pixf->satd_x3[PIXEL_8x8] = x264_pixel_satd_x3_8x8_sse2;
+ pixf->satd_x3[PIXEL_8x4] = x264_pixel_satd_x3_8x4_sse2;
+
+ pixf->satd_x4[PIXEL_16x16]= x264_pixel_satd_x4_16x16_sse2;
+ pixf->satd_x4[PIXEL_16x8] = x264_pixel_satd_x4_16x8_sse2;
+ pixf->satd_x4[PIXEL_8x16] = x264_pixel_satd_x4_8x16_sse2;
+ pixf->satd_x4[PIXEL_8x8] = x264_pixel_satd_x4_8x8_sse2;
+ pixf->satd_x4[PIXEL_8x4] = x264_pixel_satd_x4_8x4_sse2;

//#ifdef ARCH_X86
pixf->sad_x3[PIXEL_16x16] = x264_pixel_sad_x3_16x16_sse2;
pixf->sad_x3[PIXEL_16x8 ] = x264_pixel_sad_x3_16x8_sse2;

[Dark Shikari]

Can't think of anything that would cause that--it could be that your source isn't the same as my source, since the source I used is patched, for Cef's build.

It should be obvious what the patch is changing though in that case, hopefully. You can always download my 7z'd source.

[ChronoCross]

Can't think of anything that would cause that--it could be that your source isn't the same as my source, since the source I used is patched, for Cef's build.

It should be obvious what the patch is changing though in that case, hopefully. You can always download my 7z'd source.

ah......then it's not svn compatible. I must have misread. Thanks

[Dark Shikari]

ah......then it's not svn compatible. I must have misread. ThanksCef's source does include the SVN metadata, but you'll probably have to slightly modify the patch to fit a totally unpatched source set.

It shouldn't be hard to get it to work on SVN though.

[TheRyuu]

Alright, finally got the dam thing built.
Luckily the missing ";" was the only problem.

Uploaded the builds for everyone.
All builds are based off of Cef's 667b so they have all patches he uses (including AQ)
And since I aim to please, I've uploaded a few different versions although the speed difference should be minimal but you should download the appropriate build for your processor.
x264 generic (http://www.sendspace.com/file/2jl2w0) (generic build with mmx)
x264 P3 (http://www.sendspace.com/file/suxa6e) (generic build with mmx+sse)
x264 Pentium4 (http://www.sendspace.com/file/oq5jdy) (mmx, sse, sse2, tuned for pentium4)
x264 K8 (http://www.sendspace.com/file/v8idrx) (mmx, sse, sse2, tuned for k8)
Last but not least, experimental Core2 build (with -mssse3), built with GCC 4.3
x264 Core2 (experimental) (http://www.sendspace.com/file/pyi74g) (mmx, sse, sse2, sse3, ssse3, tuned for core2)

Built with GCC 4.2.1 (latest stable version) with avis input, mp4 output and pthreads (i.e. the only options that really matter to most end users... :))

Only had to add one more CFLAG to it. I built it with the -march=pentium2 to enable MMX support (since I think all the CPUs everyone uses here have MMX and the difference between MMX and the additional SSE+ ones are like 1% since most of it (the important stuff) is written in ASM anyway.

From Sharktooth:
- cflags: -march=pentium2 -mmmx -O3 -finline-functions -funroll-loops -ffast-math -fomit-frame-pointer (some of them may be redundant)

I built it with most of those, march=pentium2 with -mmmx is redundent.
finline functions I believe is activated with -O3 so also redundent.
-funroll-loops I didn't add since I really don't know if it makes it faster or not. Most of the time this can bloat code. However in certain circumstances it can make code faster. I wanted to keep it simple so I didn't add it and it can vary from computer to computer.
ffast-math and -fomit-frame-pointer were also added (already there).

Also, all builds have two additional LDFLAGS to the default x264 ones. -Wl,-O1 and -Wl,--sort-common.

Enjoy.

[Dark Shikari]

Sweet, thanks a lot :cool:

I have to try these builds now :)

[LoRd_MuldeR]

The "x264 Core2 (experimental)" build seems to work fine on my Core 2 Quad (WindowsXP x64)

[TheRyuu]

The "x264 Core2 (experimental)" build seems to work fine on my Core 2 Quad (WindowsXP x64)

Well, it should for the most part work. Only reason I marked it as experimental is it was built using a "Stage 1" GCC 4.3 which may not be the most stable compiler in the world.
I only put the different CPU builds out to help "please" everyone but the only real difference should be like 1-2% between the different builds.

[Cef]

I made a 64 bit (http://mirror05.x264.nl/Cef/force.php?file=./x264_x64_hadamard.7z) one, in case anyone needs.

[Kurth]

Well I have an AMD Athlon X2 4000+ Brisbane and I tried two builds with the same config the only diference is the --hadamard command.

The video is Japanese Anime.

x264 build 671 from http://x264.nl/

encoder commandline:
--crf 18 --keyint 300 --min-keyint 30 --ref 4 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --b-rdo --bime --weightb --subme 6 --trellis 1 --analyse all --8x8dct --me umh --threads auto --thread-input --progress --no-dct-decimate --output "E:\Video.mkv" "E:\Video.avs"

avis [info]: 704x400 @ 30.00 fps (3038 frames)
x264 [info]: using cpu capabilities: MMX MMXEXT SSE SSE2 3DNow!
x264 [info]: slice I:77 Avg QP:15.79 size: 17806 PSNR Mean Y:70.93 U:77.83 V:76.52 Avg:71.33 Global:53.77
x264 [info]: slice P:2307 Avg QP:15.96 size: 10602 PSNR Mean Y:51.21 U:54.28 V:53.11 Avg:51.71 Global:49.54
x264 [info]: slice B:654 Avg QP:19.61 size: 4581 PSNR Mean Y:49.92 U:53.83 V:52.39 Avg:50.55 Global:46.65
x264 [info]: mb I I16..4: 57.0% 40.7% 2.3%
x264 [info]: mb P I16..4: 8.6% 17.0% 0.7% P16..4: 41.3% 11.1% 5.2% 0.2% 0.1% skip:15.8%
x264 [info]: mb B I16..4: 0.1% 0.5% 0.1% B16..8: 30.6% 1.8% 6.3% direct: 6.2% skip:54.4%
x264 [info]: 8x8 transform intra:62.0% inter:72.2%
x264 [info]: ref P 89.5% 7.1% 2.3% 1.1%
x264 [info]: ref B 83.4% 12.1% 2.8% 1.8%
x264 [info]: SSIM Mean Y:0.9938007
x264 [info]: PSNR Mean Y:51.435 U:54.782 V:53.548 Avg:51.955 Global:48.794 kb/s:2277.12
encoded 3038 frames, 12.84 fps, 2277.28 kb/s
desired video bitrate of this job: 18 kbit/s - obtained video bitrate (approximate): 2280 kbit/s

AVInaptic DRF analysis Average DRF 16.742922

x264 hadamard K8 build

encoder commandline:
--crf 18 --keyint 300 --min-keyint 30 --ref 4 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --b-rdo --bime --weightb --subme 6 --trellis 1 --analyse all --8x8dct --me umh --threads auto --thread-input --progress --no-dct-decimate --output "E:\Video1.mkv" "E:\Video.avs" --hadamard

avis [info]: 704x400 @ 30.00 fps (3038 frames)
x264 [info]: using cpu capabilities: MMX MMXEXT SSE SSE2 3DNow!
x264 [info]: slice I:83 Avg QP:15.58 size: 16745 PSNR Mean Y:70.38 U:78.42 V:77.06 Avg:70.92 Global:54.16
x264 [info]: slice P:2310 Avg QP:15.84 size: 10417 PSNR Mean Y:51.33 U:54.36 V:53.12 Avg:51.80 Global:49.63
x264 [info]: slice B:645 Avg QP:19.79 size: 4741 PSNR Mean Y:49.73 U:53.50 V:52.12 Avg:50.27 Global:46.60
x264 [info]: mb I I16..4: 57.9% 39.9% 2.1%
x264 [info]: mb P I16..4: 8.4% 15.9% 0.6% P16..4: 41.2% 12.2% 5.0% 0.2% 0.1% skip:16.4%
x264 [info]: mb B I16..4: 0.1% 0.6% 0.1% B16..8: 30.9% 1.9% 6.3% direct: 6.4% skip:53.6%
x264 [info]: 8x8 transform intra:61.0% inter:73.0%
x264 [info]: ref P 90.2% 6.7% 2.1% 1.0%
x264 [info]: ref B 83.6% 12.0% 2.7% 1.7%
x264 [info]: SSIM Mean Y:0.9938760
x264 [info]: PSNR Mean Y:51.509 U:54.834 V:53.562 Avg:52.000 Global:48.848 kb/s:2252.37
encoded 3038 frames, 6.22 fps, 2252.53 kb/s
desired video bitrate of this job: 18 kbit/s - obtained video bitrate (approximate): 2255 kbit/s

AVInaptic DRF analysis Average DRF 16.675444

File encoded with build 671 from http://x264.nl/
Size: 28.193 KB

File encoded with hadamard K8 build
Size: 27.888 KB

The hadamard option is really slow but it got better quality and used less bitrate.

[gigah72]

i have a core duo t2300 and use the core2 build, but sse3 is not listed in the cpu capabilities info.
is this normal?

[slavickas]

i have a core duo t2300 and use the core2 build, but sse3 is not listed in the cpu capabilities info.
is this normal?

coz its core duo, not core 2 duo

[DeathTheSheep]

Size and quality increases are reversed when using an exhaustive search. This was the case with x264-satd-opt in the past, as well.

The real question is, why is this the case? You mentioned SATD being non-optimal for centering an exhaustive search around.
I'll venture to guess the reason: SAD-Opt is not always the best way of picking what block to center a short-range, high-precision search around. I'm guessing that an exhaustive search has a tendency to find blocks that otherwise wouldn't be looked at but just happen to have a decent SSIM, resulting in a bad high-precision search.

Oh the irony!

To check my theory, try comparing a SAD-Opt ESA and SAD-Opt UMH encode... see which is better! If the UMH is actually better, that would be quite interesting.
Here SSIM isn't factored into the equation, but the results still exhibit that strange pattern. (Recall ESA is intended to be the best method, and that akupenguin uses it to measure how much worse the other algorithms are from it.) Are there any other theories?

[Dark Shikari]

Size and quality increases are reversed when using an exhaustive search. This was the case with x264-satd-opt in the past, as well.

The real question is, why is this the case? You mentioned SATD being non-optimal for centering an exhaustive search around.Yeah, that has always been strange, especially as SATD itself is a very tried-and-true method, unlike my whole SSIM bit.

Here's my explanation. The encoder, when doing a hex search, for example, looks around in a hexagon pattern for the best block, then diamond-refines it, and then does subpixel refinement. This means that a metric that accurately says "this block is within a few pixels of what RD thinks is the best block" is the best metric, because the hex search is looking for the best point at which to further refine the search, not the best point period.

However, for ESA, you want a metric that says "this block is within 1/2 pixel of the best block, RD-wise," because it literally checks every block on a fullpel basis.

I would make a guess that SATD is better at finding blocks near the best, while SAD is better for finding blocks that are basically right on top of the best. It isn't that SAD is good at finding such blocks; its just that SATD is probably bad at it.

One thought--which gives better results, --me umh --hadamard or --me esa?

[gigah72]

coz its core duo, not core 2 duo

i agree, but does it check for core 2 duo or sse3 capablity?

http://img174.imageshack.us/img174/538/sse3pa2.png (http://imageshack.us)

[DeathTheSheep]

Ah, that does make some sense!
But why would a metric that finds the best block (or "right on top of the best")--SAD--produce worse results with the exhaustive search than a metric that finds blocks near the best--SATD--with a patterned search?

Unless that is to say SATD's 'near'-prediction beats SAD's 'best'-prediction.

If this is the case, is there such an optimal metric as you defined that can be implemented into x264 for exhaustive search?

[Dark Shikari]

Ah, that does make some sense!
But why would a metric that finds the best block (or "right on top of the best")--SAD--produce worse results with the exhaustive search than a metric that finds blocks near the best--SATD--with a patterned search?

Unless that is to say SATD's 'near'-prediction beats SAD's 'best'-prediction.

If this is the case, is there such an optimal metric as you defined that can be implemented into x264 for exhaustive search?
I'm going to try varying the metrics used for different parts of the search and seeing if I can figure out what exactly is going on.
i agree, but does it check for core 2 duo or sse3 capablity?

http://img174.imageshack.us/img174/538/sse3pa2.png (http://imageshack.us)
SSSE3, not SSE3. Big difference. x264 doesn't use SSE3.

[foxyshadis]

x264 doesn't have or need sse3. It's ssse3 that's useful, and even if gcc uses it, it won't show up (because that list only shows what x264 optimizations are used, not what compiler optimizations, and x264 only uses ssse3 in 64-bit mode).

So far it looks pretty unequivocally better for cartoons & cg, but by a pretty small amount. Live action is less conclusive and I'm getting sick of this graphing. :p

[Terranigma]

x264 doesn't have or need sse3. It's ssse3 that's useful, and even if gcc uses it, it won't show up (because that list only shows what x264 optimizations are used, not what compiler optimizations, and x264 only uses ssse3 in 64-bit mode).

How much of a speed difference, in terms of percentage, would you say there is between sse2 & ssse3? Also, does x264 reap any benefit from the new sse4 instruction? Could you also give a value, in terms of prcoessing speed between ssse3 and sse4 as well? Thanks in advance. :)

[Dark Shikari]

How much of a speed difference, in terms of percentage, would you say there is between sse2 & ssse3? Also, does x264 reap any benefit from the new sse4 instruction? Could you also give a value, in terms of prcoessing speed between ssse3 and sse4 as well? Thanks in advance. :)
The new SSEs and such are only useful in terms of the instructions they add; and if they don't add any instructions that are useful and faster than older instructions, they're not going to be used.

SSE4 isn't even out yet on any consumer chips, but I believe it includes a Sum of Absolute Difference operation, which should speed up encoding a lot. Unfortunately it won't help at all with the --hadamard option :p

[Terranigma]

Unfortunately it won't help at all with the --hadamard option :p

Ok, thanks for the info; this was the main reason of my asking. Would it be okay to only use hadamard for the final pass? :devil:

[akupenguin]

Size and quality increases are reversed when using an exhaustive search. This was the case with x264-satd-opt in the past, as well.

SATD should work in ESA. It should not work in SEA. This means you need to uncomment

#if 0
/* plain old exhaustive search */
for( my = min_y; my <= max_y; my++ )
for( mx = min_x; mx <= max_x; mx++ )
COST_MV( mx, my );
#else

SEA (the complicated alternative to that code) losslessly rules out most of the mvs, and thus produces results identical to ESA much faster. But it can only work for SAD and (with some changes) SSD.

SSE4 isn't even out yet on any consumer chips, but I believe it includes a Sum of Absolute Difference operation, which should speed up encoding a lot. Unfortunately it won't help at all with the --hadamard option :p
A SAD instruction has existed since MMX2. SSE4 adds an ESA instruction. But I'm unsure of whether it will be faster than SSE2 SEA, since the benchmarks I've seen claim only about a factor of 2 speedup over SSE2 ESA.

It's ssse3 that's useful, and even if gcc uses it, it won't show up (because that list only shows what x264 optimizations are used, not what compiler optimizations, and x264 only uses ssse3 in 64-bit mode).
x264 uses SSSE3 in 32-bit mode too.
btw, the instructions provided in SSSE3 should be very useful for SATD, but Core2's implementation of PHADD* is so much slower than PADD* that I can't actually use PHADD*. Penryns's improved permutation engine might increase the speed of this instruction until it's useful.

[Dark Shikari]

satd should work in ESA. It should not work in SEA. This means you need to uncomment

#if 0
/* plain old exhaustive search */
for( my = min_y; my <= max_y; my++ )
for( mx = min_x; mx <= max_x; mx++ )
COST_MV( mx, my );
#else

SEA (the complicated alternative to that code) losslessly rules out most of the mvs, and thus produces results identical to ESA much faster. But it can only work for SAD and (with some changes) SSD.Should I modify the patch to use the old ESA algorithm when --hadamard is used?
Ok, thanks for the info; this was the main reason of my asking. Would it be okay to only use hadamard for the final pass? :devil:Of course, I don't think it changes the bitstream decisions enough to effect a first pass at all.

[CruNcher]

does it only work @ high submes ? above 1 or 2 i see no effect their it even makes the filesize bigger ?
the improvement i see is in the last 3 digits of SSIM and for the speed loss not really good, especialy as i can't see any visual difference :P
@ aku
someone has to make deadzones adaptive (modes based on MV,QP and Bitrate) i see a real quality gain their correctly used in terms of bitrate and scenes for example credits are fine with 32-32 the current 11-21 just wastes to much bits :) the overblurring has also a nice effect on scenes where banding is visible for example Dark Shikaris night scenes would look less visible with 32-32 trough the overbluring sure it takes also details but in some situations as camera pans or non conversation scenes i think it's a nice thing to make use off (especialy for ultra low bitrate encodes) and you can still use lower settings saving fewer bits :)

[akupenguin]

Deadzones only go up to 32.
Credits are fine with higher QP too, if you used deadzones just to save bits.
I don't see how deadzones could have any effect on banding, but please prove me wrong.

[CruNcher]

it doesn't but the overblurring makes it less noticeable in the background then a very clear deadzone setting especialy from some metters away of the display device

[DeathTheSheep]

Should I modify the patch to use the old ESA algorithm when --hadamard is used?


There's no harm in trying; it looks like it might work fine. :)

[Sagittaire]

- For the first time I have 44.00 dB for my HPII trailer at 900 Kbps.
- For the first time I have 41.42 dB for my HPII trailer at 450 Kbps.

[Dark Shikari]

There's no harm in trying; it looks like it might work fine. :)
Done, and here's the results.

Not surprisingly the old ESA method is incredibly slow, so in a sense it is telling us "please don't use --hadamard and --me esa for any normal usage!" However I would think that using the SEA method with --hadamard would be somewhat disingenuous considering that it simply makes no sense to do so mathematically.

Settings used: --bframe 16 --b-pyramid --subme 7 --b-pyramid --ref 3 --progress --mixed-refs --bime --weightb --partitions all --direct auto --deblock 0:0 --no-fast-pskip --crf 25

Source: 1000 frames of Elephant's Dream: the running scene in the room full of wires. Singlethreaded.

SATD = --hadamard used, SAD = --hadamard not used.

SEA ME algorithm means the current x264 ESA algorithm, and ESA means the pure bruteforce algorithm, which is the only real option for use with --hadamard.

http://i10.tinypic.com/5yiklqe.png

Notice a few things:

1. --me umh --hadamard is about the same same speed as --me esa and basically equals its quality per bitrate. I haven't tried other --meranges but I assume UMH-Hadamard would be superior at higher meranges due to the faster speed.

2. --me esa --hadamard with the ESA modification is very slow but blows away everything else with the lowest bitrate and best quality without a doubt.

3. --me esa --hadamard without the ESA modification is useless.

4. --hadamard is basically pointless below --me umh.

[akupenguin]

Next experiment: full RDO of all 16641 qpel positions in the search range (assuming merange=16) ;) Just to give an upper bound on the improvements possible.
Note that the optimal subpel position is not necessarily next to the optimal fullpel position, since the subpel filter alters the pixels.

[Dark Shikari]

Next experiment: full RDO of all 16641 qpel positions in the search range (assuming merange=16) ;) Just to give an upper bound on the improvements possible.That would be absolutely insane.

But possible :devil:

Heck, you could actually use that as a way to tune our current motion search methods; do a massive RD-Qpel ESA search and then see how the current methods could be changed to better fit that search.
Note that the optimal subpel position is not necessarily next to the optimal fullpel position, since the subpel filter alters the pixels.Of course.

[ChronoCross]

I did the patching for svn but IDK how to create the patch in the correct format.

Anyway what I wanted to say was thank you for this thread as I've picked up a few things about the inner working behind everything. Threads like this are always thought provoking.

[Sagittaire]

Next experiment: full RDO of all 16641 qpel positions in the search range (assuming merange=16) ;) Just to give an upper bound on the improvements possible.
Note that the optimal subpel position is not necessarily next to the optimal fullpel position, since the subpel filter alters the pixels.


Well for ED (and I know very well Elephant Dream movie), IMO the best possible improvement way is RDO for bframes placement. Here a little example with the first 50 frame of ED (fade scene):

- 3 adaptative bframe with pure q25 encoding:
2048 Kbps and 48.73 dB

- 0 no adaptative bframe with pure q25 encoding:
2048 Kbps and 48.73 dB

- 1 no adaptative bframe with pure q25 encoding:
1482 Kbps and 48.83 dB

- 2 no adaptative bframe with pure q25 encoding:
1282 Kbps and 48.93 dB

- 3 no adaptative bframe with pure q25 encoding:
1249 Kbps and 48.61 dB

- 3 no adaptative pyramidal bframe with pure q25 encoding:
1180 Kbps and 48.43 dB


For fade scene the most important function is wpred. Anyway x264 use only wpred for bframe and x264 RC don't use bframe in fade scene (???).


D:\Mes dossiers\Codec\x264>x264.exe --qp 25 --threads 1 --thread-input --keyint 250 --min-keyint 1 -
-mvrange 511 --level 4.1 --bframe 3 --b-pyramid --b-rdo --bime --weightb --ref 5 --mixed-refs --dire
ct auto --deblock -1:-1 --ipratio 1.00 --pbratio 1.00 --partitions "all" --8x8dct --me "umh" --subm
e 7 --no-fast-pskip --no-dct-decimate --trellis 2 --progress -o NUL test.avs
avis [info]: 1920x1080 @ 23.98 fps (50 frames)
x264 [warning]: DPB size (25067520) > level limit (12582912)
x264 [info]: using cpu capabilities: MMX MMXEXT SSE SSE2
x264 [info]: slice I:1 Avg QP:25.00 size: 306 PSNR Mean Y:100.00 U:100.00 V:100.00 Avg:100.0
0 Global:100.00
x264 [info]: slice P:43 Avg QP:25.00 size: 12406 PSNR Mean Y:50.93 U:53.53 V:55.68 Avg:51.79 Gl
obal:48.10
x264 [info]: slice B:6 Avg QP:25.00 size: 51 PSNR Mean Y:100.00 U:100.00 V:100.00 Avg:100.0
0 Global:100.00
x264 [info]: mb I I16..4: 100.0% 0.0% 0.0%
x264 [info]: mb P I16..4: 36.1% 7.9% 0.1% P16..4: 28.9% 2.3% 0.3% 0.0% 0.0% skip:24.5%
x264 [info]: mb B I16..4: 0.0% 0.0% 0.0% B16..8: 0.0% 0.0% 0.0% direct: 0.0% skip:100.0%
x264 [info]: 8x8 transform intra:17.0% inter:97.5%
x264 [info]: direct mvs spatial:0.0% temporal:100.0%
x264 [info]: ref P 96.7% 2.4% 0.7% 0.1% 0.1%
x264 [info]: SSIM Mean Y:0.9892583
x264 [info]: PSNR Mean Y:57.796 U:60.033 V:61.884 Avg:58.536 Global:48.753 kb/s:2048.72

encoded 50 frames, 1.09 fps, 2051.81 kb/s

D:\Mes dossiers\Codec\x264>x264.exe --qp 25 --threads 1 --thread-input --keyint 250 --min-keyint 1 -
-mvrange 511 --level 4.1 --bframe 0 --no-b-adapt --b-rdo --bime --weightb --ref 5 --mixed-refs --dir
ect auto --deblock -1:-1 --ipratio 1.00 --pbratio 1.00 --partitions "all" --8x8dct --me "umh" --sub
me 7 --no-fast-pskip --no-dct-decimate --trellis 2 --progress -o NUL test.avs
avis [info]: 1920x1080 @ 23.98 fps (50 frames)
x264 [warning]: DPB size (15667200) > level limit (12582912)
x264 [info]: using cpu capabilities: MMX MMXEXT SSE SSE2
x264 [info]: slice I:1 Avg QP:25.00 size: 306 PSNR Mean Y:100.00 U:100.00 V:100.00 Avg:100.0
0 Global:100.00
x264 [info]: slice P:49 Avg QP:25.00 size: 10893 PSNR Mean Y:56.93 U:59.22 V:61.11 Avg:57.69 Gl
obal:48.67
x264 [info]: mb I I16..4: 100.0% 0.0% 0.0%
x264 [info]: mb P I16..4: 31.6% 6.9% 0.1% P16..4: 25.3% 2.0% 0.2% 0.0% 0.0% skip:33.7%
x264 [info]: 8x8 transform intra:17.0% inter:97.5%
x264 [info]: ref P 96.7% 2.4% 0.7% 0.1% 0.1%
x264 [info]: SSIM Mean Y:0.9892583
x264 [info]: PSNR Mean Y:57.796 U:60.033 V:61.884 Avg:58.536 Global:48.753 kb/s:2048.67

encoded 50 frames, 1.11 fps, 2051.52 kb/s

D:\Mes dossiers\Codec\x264>x264.exe --qp 25 --threads 1 --thread-input --keyint 250 --min-keyint 1 -
-mvrange 511 --level 4.1 --bframe 1 --no-b-adapt --b-rdo --bime --weightb --ref 5 --mixed-refs --dir
ect auto --deblock -1:-1 --ipratio 1.00 --pbratio 1.00 --partitions "all" --8x8dct --me "umh" --sub
me 7 --no-fast-pskip --no-dct-decimate --trellis 2 --progress -o NUL test.avs
avis [info]: 1920x1080 @ 23.98 fps (50 frames)
x264 [warning]: DPB size (18800640) > level limit (12582912)
x264 [info]: using cpu capabilities: MMX MMXEXT SSE SSE2
x264 [info]: slice I:1 Avg QP:25.00 size: 306 PSNR Mean Y:100.00 U:100.00 V:100.00 Avg:100.0
0 Global:100.00
x264 [info]: slice P:25 Avg QP:25.00 size: 14375 PSNR Mean Y:55.84 U:58.18 V:60.21 Avg:56.62 Gl
obal:48.66
x264 [info]: slice B:24 Avg QP:25.00 size: 1121 PSNR Mean Y:56.85 U:59.84 V:61.85 Avg:57.51 Gl
obal:48.83
x264 [info]: mb I I16..4: 100.0% 0.0% 0.0%
x264 [info]: mb P I16..4: 40.3% 13.8% 0.4% P16..4: 16.0% 2.5% 0.1% 0.0% 0.0% skip:26.9%
x264 [info]: mb B I16..4: 0.1% 0.0% 0.0% B16..8: 3.4% 0.0% 0.0% direct: 0.2% skip:96.3%
x264 [info]: 8x8 transform intra:23.5% inter:92.3%
x264 [info]: direct mvs spatial:70.8% temporal:29.2%
x264 [info]: ref P 96.6% 2.5% 0.7% 0.2% 0.1%
x264 [info]: ref B 99.5% 0.4% 0.0% 0.1%
x264 [info]: SSIM Mean Y:0.9895206
x264 [info]: PSNR Mean Y:57.211 U:59.811 V:61.790 Avg:57.914 Global:48.833 kb/s:1482.98

encoded 50 frames, 1.65 fps, 1486.20 kb/s

D:\Mes dossiers\Codec\x264>x264.exe --qp 25 --threads 1 --thread-input --keyint 250 --min-keyint 1 -
-mvrange 511 --level 4.1 --bframe 2 --no-b-adapt --b-rdo --bime --weightb --ref 5 --mixed-refs --dir
ect auto --deblock -1:-1 --ipratio 1.00 --pbratio 1.00 --partitions "all" --8x8dct --me "umh" --sub
me 7 --no-fast-pskip --no-dct-decimate --trellis 2 --progress -o NUL test.avs
avis [info]: 1920x1080 @ 23.98 fps (50 frames)
x264 [warning]: DPB size (18800640) > level limit (12582912)
x264 [info]: using cpu capabilities: MMX MMXEXT SSE SSE2
x264 [info]: slice I:1 Avg QP:25.00 size: 306 PSNR Mean Y:100.00 U:100.00 V:100.00 Avg:100.0
0 Global:100.00
x264 [info]: slice P:17 Avg QP:25.00 size: 16724 PSNR Mean Y:56.67 U:58.92 V:60.65 Avg:57.41 Gl
obal:48.70
x264 [info]: slice B:32 Avg QP:25.00 size: 1557 PSNR Mean Y:57.50 U:59.68 V:61.26 Avg:58.19 Gl
obal:48.93
x264 [info]: mb I I16..4: 100.0% 0.0% 0.0%
x264 [info]: mb P I16..4: 43.9% 17.8% 0.9% P16..4: 11.2% 2.2% 0.2% 0.0% 0.0% skip:23.7%
x264 [info]: mb B I16..4: 0.1% 0.1% 0.0% B16..8: 4.4% 0.1% 0.1% direct: 0.3% skip:95.0%
x264 [info]: 8x8 transform intra:26.1% inter:87.6%
x264 [info]: direct mvs spatial:71.9% temporal:28.1%
x264 [info]: ref P 96.8% 2.4% 0.6% 0.1% 0.0%
x264 [info]: ref B 99.7% 0.2% 0.1% 0.0% 0.0%
x264 [info]: SSIM Mean Y:0.9894938
x264 [info]: PSNR Mean Y:58.068 U:60.229 V:61.825 Avg:58.765 Global:48.936 kb/s:1282.96

encoded 50 frames, 2.05 fps, 1286.22 kb/s

D:\Mes dossiers\Codec\x264>x264.exe --qp 25 --threads 1 --thread-input --keyint 250 --min-keyint 1 -
-mvrange 511 --level 4.1 --bframe 3 --no-b-adapt --b-rdo --bime --weightb --ref 5 --mixed-refs --dir
ect auto --deblock -1:-1 --ipratio 1.00 --pbratio 1.00 --partitions "all" --8x8dct --me "umh" --sub
me 7 --no-fast-pskip --no-dct-decimate --trellis 2 --progress -o NUL test.avs
avis [info]: 1920x1080 @ 23.98 fps (50 frames)
x264 [warning]: DPB size (18800640) > level limit (12582912)
x264 [info]: using cpu capabilities: MMX MMXEXT SSE SSE2
x264 [info]: slice I:1 Avg QP:25.00 size: 306 PSNR Mean Y:100.00 U:100.00 V:100.00 Avg:100.0
0 Global:100.00
x264 [info]: slice P:13 Avg QP:25.00 size: 18693 PSNR Mean Y:55.53 U:57.84 V:59.61 Avg:56.29 Gl
obal:48.67
x264 [info]: slice B:36 Avg QP:25.00 size: 2287 PSNR Mean Y:55.90 U:58.72 V:61.06 Avg:56.67 Gl
obal:48.47
x264 [info]: mb I I16..4: 100.0% 0.0% 0.0%
x264 [info]: mb P I16..4: 47.2% 21.3% 1.6% P16..4: 6.9% 1.8% 0.1% 0.0% 0.0% skip:21.0%
x264 [info]: mb B I16..4: 0.3% 0.3% 0.0% B16..8: 5.6% 0.1% 0.2% direct: 0.5% skip:93.0%
x264 [info]: 8x8 transform intra:27.8% inter:86.7%
x264 [info]: direct mvs spatial:69.4% temporal:30.6%
x264 [info]: ref P 96.7% 2.7% 0.5% 0.1% 0.1%
x264 [info]: ref B 99.8% 0.2% 0.0% 0.0% 0.0%
x264 [info]: SSIM Mean Y:0.9892318
x264 [info]: PSNR Mean Y:56.689 U:59.318 V:61.461 Avg:57.436 Global:48.611 kb/s:1249.17

encoded 50 frames, 2.10 fps, 1252.35 kb/s

D:\Mes dossiers\Codec\x264>x264.exe --qp 25 --threads 1 --thread-input --keyint 250 --min-keyint 1 -
-mvrange 511 --level 4.1 --bframe 3 --b-pyramid --no-b-adapt --b-rdo --bime --weightb --ref 5 --mixe
d-refs --direct auto --deblock -1:-1 --ipratio 1.00 --pbratio 1.00 --partitions "all" --8x8dct --me
"umh" --subme 7 --no-fast-pskip --no-dct-decimate --trellis 2 --progress -o NUL test.avs
avis [info]: 1920x1080 @ 23.98 fps (50 frames)
x264 [warning]: DPB size (25067520) > level limit (12582912)
x264 [info]: using cpu capabilities: MMX MMXEXT SSE SSE2
x264 [info]: slice I:1 Avg QP:25.00 size: 306 PSNR Mean Y:100.00 U:100.00 V:100.00 Avg:100.0
0 Global:100.00
x264 [info]: slice P:13 Avg QP:25.00 size: 18696 PSNR Mean Y:55.53 U:57.85 V:59.62 Avg:56.30 Gl
obal:48.68
x264 [info]: slice B:36 Avg QP:25.00 size: 1787 PSNR Mean Y:55.75 U:59.01 V:59.27 Avg:56.42 Gl
obal:48.24
x264 [info]: mb I I16..4: 100.0% 0.0% 0.0%
x264 [info]: mb P I16..4: 47.0% 21.1% 1.5% P16..4: 7.2% 1.8% 0.1% 0.0% 0.0% skip:21.2%
x264 [info]: mb B I16..4: 0.2% 0.2% 0.0% B16..8: 4.9% 0.1% 0.1% direct: 0.4% skip:94.2%
x264 [info]: 8x8 transform intra:27.6% inter:85.9%
x264 [info]: direct mvs spatial:75.0% temporal:25.0%
x264 [info]: ref P 91.8% 5.6% 1.8% 0.5% 0.2%
x264 [info]: ref B 98.8% 0.9% 0.2% 0.0% 0.1%
x264 [info]: SSIM Mean Y:0.9893261
x264 [info]: PSNR Mean Y:56.577 U:59.531 V:60.178 Avg:57.260 Global:48.438 kb/s:1180.27

encoded 50 frames, 1.55 fps, 1183.41 kb/s

[DeathTheSheep]

Assuming I can't compile it myself, where could I get ahold of that "fixed" ESA build? :)

[Terranigma]

Hmm, I thought p4x4 was only useable on an unrestricted level, yet you have partitions all with a level of 4.1

[Dark Shikari]

Assuming I can't compile it myself, where could I get ahold of that "fixed" ESA build? :)The patch linked in my original post has now been updated with the ESA change. The linked .7z with the source code has also been updated.

[Dark Shikari]

Well for ED (and I know very well Elephant Dream movie), IMO the best possible improvement way is RDO for bframes placement. Here a little example with the first 50 frame of ED (fade scene):

- 3 adaptative bframe with pure q25 encoding:
2048 Kbps and 48.73 dB

- 0 no adaptative bframe with pure q25 encoding:
2048 Kbps and 48.73 dB

- 1 no adaptative bframe with pure q25 encoding:
1482 Kbps and 48.83 dB

- 2 no adaptative bframe with pure q25 encoding:
1282 Kbps and 48.93 dB

- 3 no adaptative bframe with pure q25 encoding:
1249 Kbps and 48.61 dB

- 3 no adaptative pyramidal bframe with pure q25 encoding:
1180 Kbps and 48.43 dB


For fade scene the most important function is wpred. Anyway x264 use only wpred for bframe and x264 RC don't use bframe in fade scene (???).
I actually have an idea for a stopgap measure before B-frame decision RDO is implemented. Here's the pseudocode.
float averageLuma(frame,width,height)
{
int linetotal = 0
double total = 0
for line in frame
{
for pixel in line
{
linetotal += pixel.luma
}
total += linetotal
linetotal = 0
}
return (float)total/(width*height)
}

FrameDecision(args)
{
//normal stuff goes here
float avgLuma[MaxBFrames];
avgLuma[0]=averageLuma(getFrame(currentFrame))
int totalBias = 0
for(n = 1, n < MaxBframes, n++)
{
avgLuma[n]=averageLuma(getFrame(currentFrame+n))
if(avgLuma[n] < avgLuma[n-1]) totalBias++
else break
}
int C = 3 //Arbitrary constant, would have to be tuned through experimentation
for(n = 1, n < totalBias, n++)
{
getFrame(n).b_bias += C * n * n
}
//Final frame decision goes here
}

Basically what I'm doing is, when the luma is decreasing consistently from each frame to the next and to the next, I am biasing these frames in favor of being B-frames. If the luma decreases just a couple times in a row, it biases it very little (notice the n^2). If it decreases 16 times in a row, you get a C*256 b-bias for each of those frames.

To a developer: what would be the best way to:

a) Make a function that counts up the luma and averages it
b) set the b-bias for multiple frames in the future

Not algorithmically how would I do it, but technically (dealing with the x264 codebase).

[TheRyuu]

The patch linked in my original post has now been updated with the ESA change. The linked .7z with the source code has also been updated.

Do I need to recompile it again?

Edit:
Here:
x264 Hadamard fixed ESA build 667b x86 (32 bit) Generic (http://www.sendspace.com/file/h36ua8) (mmx support needed)

Too lazy right now to do like 5 builds. And I can't get the stupid 64bit compiler to work.

[jethro]

- For the first time I have 44.00 dB for my HPII trailer at 900 Kbps.
- For the first time I have 41.42 dB for my HPII trailer at 450 Kbps.

I just got Global PSNR 42.933 @ 450kbps with your HPII trailer. It was only 2nd try so this can't be best result.

x264h.exe --pass 2 --
bitrate 450 --stats ".stats" -b 8 -m 7 -f -1:-1 --b-rdo -t2 --hadamard --me umh
--bime -8 -w -r 5 --mixed-refs --pbratio 1.2 --b-pyramid --threads auto --thread-input --progress --direct auto --output output.mp4 "input.avs"
avis [info]: 720x576 @ 25.00 fps (3212 frames)
x264 [info]: using cpu capabilities: MMX MMXEXT SSE SSE2 SSSE3
mp4 [info]: initial delay 2 (scale 25)
x264 [info]: slice I:54 Avg QP:26.15 size: 9026 PSNR Mean Y:46.56 U:49.07
V:49.77 Avg:47.27 Global:45.29
x264 [info]: slice P:1329 Avg QP:28.83 size: 3593 PSNR Mean Y:43.52 U:46.74
V:47.46 Avg:44.33 Global:42.72
x264 [info]: slice B:1829 Avg QP:28.28 size: 1068 PSNR Mean Y:46.02 U:49.17
V:49.92 Avg:46.77 Global:43.04
x264 [info]: mb I I16..4: 46.9% 48.4% 4.7%
x264 [info]: mb P I16..4: 12.7% 11.1% 0.7% P16..4: 21.9% 4.6% 0.6% 0.0% 0
.0% skip:48.4%
x264 [info]: mb B I16..4: 0.5% 0.7% 0.1% B16..8: 24.8% 0.4% 0.6% direct:
0.4% skip:72.5%
x264 [info]: 8x8 transform intra:46.4% inter:89.9%
x264 [info]: direct mvs spatial:0.0% temporal:100.0%
x264 [info]: ref P 76.5% 11.5% 6.9% 2.7% 2.5%
x264 [info]: ref B 83.2% 9.0% 4.3% 2.1% 1.4%
x264 [info]: SSIM Mean Y:0.9746582
x264 [info]: PSNR Mean Y:44.993 U:48.164 V:48.904 Avg:45.768 Global:42.933 kb/s:
449.33

encoded 3212 frames, 8.62 fps, 449.53 kb/s
Press any key to continue . . .

[Sagittaire]

I just got Global PSNR 42.933 @ 450kbps with your HPII trailer. It was only 2nd try so this can't be best result.

I crop/trim all the black part. I use this script:

source=Mpeg2Source("D:\Mes dossiers\B.A\Harry Potter\azerty.d2v",idct=2)
source=Trim(source,70,3145)
source=Crop(source,0,76,-0,-76)
source=LanczosResize(source,720,304)
Return(source)