Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
|
|
Thread Tools | Search this Thread | Display Modes |
1st October 2007, 01:05 | #21 | Link | |
*Space Reserved*
Join Date: May 2006
Posts: 953
|
Quote:
Cef, you think you could update the exp build for now and include AQ, Thread Pool, and the new ME-Prepass patch, then for future references, include me-prepass in your regular builds? |
|
1st October 2007, 01:12 | #22 | Link |
x264 developer
Join Date: Sep 2005
Posts: 8,666
|
Also add the --subme 7 patch, since its been proven quite thoroughly to increase quality in basically all cases at minimal speed cost.
Faster DIA, IMH, and SATD shouldn't be applied yet. One thought I did have was to instead of making SATD an option for all ME search methods, instead add a 5th ME search method: DIA HEX UMH ESA HES (Hadamard Exhaustive Search: Better than all the above methods, but correspondingly slower) The reason for this is simply that Aku's testing showed that SATD slowed down all the other methods so much that it was better to use SAD ESA than SATD anything else. However, SATD ESA is so heavily optimized that its still useful, and not too much slower than regular ESA. |
1st October 2007, 01:18 | #23 | Link | ||
*Space Reserved*
Join Date: May 2006
Posts: 953
|
Quote:
I agree with you on imh and dia (At first I was all for imh, but suddenly I changed my mind ). Quote:
I like this idea. Only allowing SATD to be used with the motion search algorithm it gains any real benefit from. I'm all for the new --hes |
||
1st October 2007, 02:07 | #24 | Link |
x264 developer
Join Date: Sep 2004
Posts: 2,392
|
Not sure I like HES, too similar to HEX. Maybe TES (same "T"ransform as in SATD). Or ESH.
But I'm not sure that SATD is only useful in ESA: There are good reasons that integral-based successive elimination for SAD can only be efficient in ESA, but it's possible that SAD-based successive elimination for SATD could work in other search patterns. The cost of a SAD or a SATD is high enough that the overhead of random access needn't be fatal. Last edited by akupenguin; 1st October 2007 at 02:16. |
1st October 2007, 02:42 | #26 | Link | |
x264... Brilliant!
Join Date: Mar 2005
Location: Rockville, MD
Posts: 167
|
Quote:
Let SAD IMH be the (speed) middle ground between SAD UMH and SATD ESA? akupenguin, could you update your chart here with Dark Shikari's new ME-prepass found here? Depending on the results, I might even suggest regular ESA to be prepass SATD ESA. I see it like this... If you are mad enough to do ESA, you are quite likely going to do SATD and prepass also. |
|
1st October 2007, 02:43 | #27 | Link | |
x264 developer
Join Date: Sep 2005
Posts: 8,666
|
Quote:
|
|
1st October 2007, 02:51 | #28 | Link | |
x264... Brilliant!
Join Date: Mar 2005
Location: Rockville, MD
Posts: 167
|
Quote:
How about normal default esa be SATD and with a switch it can SAD and ditch the new me-type. All choices still remain. |
|
1st October 2007, 02:54 | #29 | Link | |
x264 developer
Join Date: Sep 2005
Posts: 8,666
|
Quote:
Also note that if TES/whatever its called uses SATD, the --fpel-cmp satd option will be removed. |
|
1st October 2007, 03:32 | #31 | Link | |
x264... Brilliant!
Join Date: Mar 2005
Location: Rockville, MD
Posts: 167
|
Quote:
SAD - UMH - ME32 has the same quality as SAD - ESA - ME7 and SATD - ESA - ME4 However the FPS is 47 vs. 42 vs. 39 respectively. SATD is slowest, by not by too much. Even though SATD is 7-8% slower, the magic is that SATD, with computation (me-range increments), SATD gains quality much quicker and peaks much higher. Additionally, SATD ESA-me6 beats the quality of SAD ESA-me12 at the same FPS! Therefore, SAD ESA only has a place for me range less than 12. So instead of telling people that ESA is only has benefits from me-7 through me-12, over other ME-types, you could tell them ESA picks up quality-wise where UMH stops. It seems a little more clean to me. I just hope the explanation is understandable. Maybe I'm a little my willing to throw computation at it than others, but I think the average person ESA would usually do this anyway. |
|
1st October 2007, 03:44 | #32 | Link | |
x264 developer
Join Date: Sep 2005
Posts: 8,666
|
Quote:
Anime in particular seems to suffer from this, in my experience. |
|
1st October 2007, 03:55 | #33 | Link | |
x264... Brilliant!
Join Date: Mar 2005
Location: Rockville, MD
Posts: 167
|
Quote:
Last edited by fields_g; 1st October 2007 at 04:08. |
|
1st October 2007, 11:00 | #34 | Link | |
Registered User
Join Date: Mar 2007
Posts: 25
|
Quote:
I completly agree this is confusing, my organization is terrible on this, but I don't have much time to dedicate to it, and I usually spend it fixing conflicts with new rev's or between patches. If you have any suggestion it's welcome. |
|
1st October 2007, 16:57 | #35 | Link | |
masktools2 (ab)user
Join Date: Oct 2006
Location: PAL-I :(
Posts: 235
|
Quote:
But I can say at this point that it's the "old" one. And thanks Cef for explaining. I'm not sure whether I'd have any good suggestions, but perhaps just a small txt in the directory where your builds are located (on x264.nl) which would state which patch(es) was/were applied to which build(s). Or maybe if morph would be so kind to interpret this into the introductory post in this thread... Whatever works really. |
|
1st October 2007, 17:46 | #36 | Link |
*Space Reserved*
Join Date: May 2006
Posts: 953
|
martino, do you know how to complile x264? It doesn't look like noone's too eager to compile an experimental build with aq, thread pool, new subme7, new pre-pass, and keep --fpel-cmp sad/satd like it is as suggested by akupenguin, and if you must implement the new aq, add it as an optional command. Maybe something like aq2-strength. You can find the latest aq2 algortihm by Dark Shikari here. I'm not sure if that's the latest, so he's the only one that can confirm or deny this.
|
1st October 2007, 18:14 | #37 | Link | |
x264 developer
Join Date: Sep 2005
Posts: 8,666
|
Quote:
Don't add it yet. Its way too experimental. |
|
2nd October 2007, 00:10 | #38 | Link |
<The VFW Sheep of Death>
Join Date: Dec 2004
Location: Deathly pasture of VFW
Posts: 1,149
|
I think the reason why most people don't have a go at compiling these patches is that the patches themselves are quite troublesome to apply.
I did it with a lot of manual patching, so it's definitely possible. But of course I also messed with a lot of other stuff in the code and then finally deleted the folder. I think it's best at this point to wait it out until more stability/commits/developments occur. Else just use the older build Cef (?) made, there shouldn't be much difference.
__________________
Recommended all-in-one stop for x264/GCC needs on Windows: Komisar x264 builds! |
2nd October 2007, 00:35 | #39 | Link | ||
*Space Reserved*
Join Date: May 2006
Posts: 953
|
Quote:
Quote:
Last edited by Terranigma; 2nd October 2007 at 00:38. |
||
Tags |
h.264, x264, x264 builds, x264 patches, x264 unofficial builds |
Thread Tools | Search this Thread |
Display Modes | |
|
|