[New patch] Improved multi-hexagon search

[akupenguin]

4..32 in steps of 4, and also tested 6 for ESA.

[Atak_Snajpera]

Does r680 contain IMH and PREPASS?

[akupenguin]

See for yourself. The changelog is public...

[Atak_Snajpera]

Any particular reason why IMH is not included?

[Dark Shikari]

Any particular reason why IMH is not included?I will guess because IMH was only particularly useful because, unlike ESA, it could be multithreaded. Now that ESA has multithreading as an option, IMH isn't nearly as useful.

[Sagittaire]

Any particular reason why IMH is not included?

Certainely because there are not exhaustive test for these patchs. In my test (HPII trailer) the improvement is not really high (0.1 dB) with dramatic speed loss. I think that now it will be really difficult to obtain metric improvement for x264. The futur for x264 is certainely HVS improvement:
- Better grain/noise preservation
- HVS Adaptative Quantisation (complexity and dark masking)
- Perhaps usefull internal filter like dark noise filtering

[Terranigma]

I liked imh. I don't care if the quality gain is minimal, the speed and quality ratio is what I preferred. I'll be sticking to the previous builds with imh then. esa, for those with slower pc's is a no no, even if multi-threaded.

How about changing umh's algorithm with imh then?

[akupenguin]

imh won't replace umh, because imh is an extension to umh. It doesn't cost any code to support both. They might, however, be merged into one commandline option which selects between umh and imh depending on merange.

[Terranigma]

They might, however, be merged into one commandline option which selects between umh and imh depending on merange.
Please, i'd really appreciate it. :)
I personally use merange 24+ depending on my source's resolution (so maybe imh can be activated starting from merange 20 or so). :D

[foxyshadis]

Cef's builds will be supporting IMH until it's merged into svn in some form, so there's no need to hold out on updating.

[Terranigma]

Cef's builds will be supporting IMH until it's merged into svn in some form, so there's no need to hold out on updating.
Actually, before I posted my response, I tested out Cef's latest build and got the following:
http://img411.imageshack.us/img411/7536/imherrorhn3.png
:p

[Sharktooth]

there are several builds on cef's site... get the correct one.
however IMHO IMH is quite useless too...

[Cef]

The regular builds I keep up to date just have AQ and thread pool patches.
Should I add anything else ?

[Terranigma]

there are several builds on cef's site... get the correct one.
however IMHO IMH is quite useless too...

Those are older builds, i'd like to be able to use imh with the latest svn. According to the graphs made by aku, you're correct, but it's still an improvment over the standard umh (even if it's by a small margin. Some of us would like to be able to use it :D)


The regular builds I keep up to date just have AQ and thread pool patches.
Should I add anything else ?

Well for now, please add the imh search algorithm until aku does his magic with umh. :D

[Dark Shikari]

Those are older builds, i'd like to be able to use imh with the latest svn. According to the graphs made by aku, you're correct, but it's still an improvment over the standard umh (even if it's by a small margin. Some of us would like to be able to use it :D)
Why not just use ESA then if you don't care that much about speed? Its multithreaded now, too.

[Terranigma]

Why not just use ESA then if you don't care that much about speed? Its multithreaded now, too.

I never said I did'nt care about speed. I usually use the exact same settings for both passes, so i'm curious as to how much the quality will differ if I chosed to use umh for the first pass and esa for the 2nd/final pass vs. esa for both passes. Any idea? :D

[Dark Shikari]

I never said I did'nt care about speed. I usually use the exact same settings for both passes, so i'm curious as to how much the quality will differ if I chosed to use umh for the first pass and esa for the 2nd/final pass vs. esa for both passes. Any idea? :DProbably meaningless--I've found that using higher settings for the first pass sometimes actually hurts quality by a miniscule amount, pointing out that beyond a certain point it goes past the margin of error.

I wouldn't use beyond --me hex and --subme 5 for the first pass, personally.

[Terranigma]

Thanks for the sage advice. So I guess the total eta for 2 passes should be equaled to or possibly less than 2 passes imh (subme7) if I used those settings for the first pass and esa for the second (with subme 7)?

[le_canz]

I did some tests with 2 pass encoding, with various sources (lossless with Elephant's Dream, 3 samples ripped from DVDs and 4 others from DV camcorder)

Using --partitions none --me dia and --subme 7 for the first pass produced the best results I could achieve :)

[Terranigma]

Using --partitions none --me dia and --subme 7 for the first pass produced the best results I could achieve :)
That's just insane. I always thought using the exact same settings will yield the optimum result. Thanks so much guys :D

[fields_g]

Yea, IMH has 2 small windows where it is better than the other methods, but I think they are small enough that you might as well just use something a little more or less cpu intensive.

[le_canz]

That's just insane. I always thought using the exact same settings will yield the optimum result. Thanks so much guys :D

That's what I thought too... However the quality gain is very small.

But it's worth to know this, as it helps saving encoding time.

[Terranigma]

Cef, Could you add the me-prepass then? I just noticed that command doesn't work either. :D

[Dark Shikari]

Cef, Could you add the me-prepass then? I just noticed that command doesn't work either. :DYes, that is much more useful as unlike --me imh it helps with all ME search modes, even with ESA, and so has nothing that can be used in its place.

[fields_g]

Yes, that is much more useful as unlike --me imh it helps with all ME search modes, even with ESA, and so has nothing that can be used in its place.

Hey, I like what I hear. I was about to make the same suggestion!

[Terranigma]

Just got finished examining my x264 esa encode with fpel satd and prepass (and a high merange). Looks amazing! Thanks Dark Shikari and le_canz for tips on using a sorta fast first pass followed by an almost 2x slower second pass. Hopefully Cef will add in prepass, as like you said Shikari, is very useful. :D

[burfadel]

He had prepass in his x264_x86_exp.7z build from the 15th, maybe a patch was missed for this build? it is a great feature!

[Terranigma]

He had prepass in his x264_x86_exp.7z build from the 15th, maybe a patch was missed for this build? it is a great feature!

He said earlier that all he includes in his normal builds was the pthreads and aq-patch, and then went on to ask us what else should be added. Prepass is the only useful patch I can think of, I mean, just look at the graph made by aku. :eek:

[burfadel]

He said earlier that all he includes in his normal builds was the pthreads and aq-patch, and then went on to ask us what else should be added. Prepass is the only useful patch I can think of, I mean, just look at the graph made by aku. :eek:

ah ok! I missed that :eek: lol, well I guess he has his answer now :D, it definately makes an impressive difference, and is a worthwhile inclusion!

[akupenguin]

Ideas for prepass:
Eliminate duplicate predicted mvs. I didn't do it before because it's not worthwhile when the cost of a duplicate is just 1 SAD, but if you run a whole subpel search then even saving an occasional duplicate should be worth the check. Also try eliminating near-duplicates within a fraction of a pixel of eachother.
Does it need to be qpel? hpel would be faster not only because it's fewer mv checks, but also because generating hpel samples is just pointer manipulation while generating qpel samples requires a dsp function.
CHECK_MVRANGE takes fullpel values, so your use of it in prepass limits the range to 1/4 of what it should be.

[Dark Shikari]

Ideas for prepass:
Eliminate duplicate predicted mvs. I didn't do it before because it's not worthwhile when the cost of a duplicate is just 1 SAD, but if you runa whole subpel search then even saving an occasional duplicate should be worth the check. Also try eliminating near-duplicates within a fraction of a pixel of eachother.
Does it need to be qpel? hpel would be faster not only because it's fewer mv checks, but also because generating hpel samples is just pointer manipulation while generating qpel samples requires a dsp function.
CHECK_MVRANGE takes fullpel values, so your use of it in prepass limits the range to 1/4 of what it should be.Ah, interesting.

The search could definitely be converted to fullpel; I doubt that would affect the results much; it might even improve the results.

I didn't realize that the subpel samples had to be generated in real-time.

[DeathTheSheep]

Any progress on the fullpel conversion? :p

[tetsuo55]

Dark Shikari, any updates on this? is it still even relevant?

[Dark Shikari]

Dark Shikari, any updates on this? is it still even relevant?Not relevent. It was only useful because ESA wasn't threaded, and now it is obselete.

With the recent ESA optimizations, it has become even more useless :p

[DeathTheSheep]

Maybe he was talking about me-prepass (also a topic of this thread). That, IMHO, will always be relevant, but whether or not there is interest in updating it is another story entirely. :p

[Sagekilla]

Maybe he was talking about me-prepass (also a topic of this thread). That, IMHO, will always be relevant, but whether or not there is interest in updating it is another story entirely. :p

I'd be interested in seeing me prepass and the fpel-cmp being merged to svn, with a little more tweaking to make it faster I suppose.

[DeathTheSheep]

Perhaps fastref, too. Or at least keep all the [quality-boost] patches in one place and up to date. I'd be willing to collect, host, and update frequently once I get a decent web space established.

[Sagekilla]

Perhaps fastref, too. Or at least keep all the patches in one place and up to date. I'd be willing to collect, host, and update frequently once I get a decent web space established.


I'm sure you could set up a rudimentary webpage on one of those free hosting sites and use mediafire to provide the hosting for all the files.

[DeathTheSheep]

Haha, I already have more than that, at least. But if I'm going to take on a repository of patches into which a lot of hard work and labor are pumping, I'd like a little more professionalism than that, not to mention decent control, backup, and data loss prevention. But soon. Soon...

[Zanejin]

With the recent ESA optimizations, it has become even more useless :p

Do these recent optimizations make ESA faster or pretty much equivalent in speed to IMH on a single-core CPU? I still run one of those old gadgets (Didée does as well, if I remember correctly).

[Dark Shikari]

Do these recent optimizations make ESA faster or pretty much equivalent in speed to IMH on a single-core CPU? I still run one of those old gadgets (Didée does as well, if I remember correctly).No idea, probably close at least.