Current Patches, Where to get them, How they affect speed/output

[morph166955]

Something I've noticed is that while we have Cef's repository of patches that he uses on his builds at http://mirror05.x264.nl/Cef/?dir=./patches there is no central place to explain what they do, what their effect on both the speed of the encode as well as Creator/Maintainer: Dark Shikari
Description: the output is, who wrote it/where it originated, and if they aren't on Cef's site where to get them (or where they originally came from in case they are updated and not updated on Cef's site). I have included below a list of the ones currently on Cef's as well as an explanation of the one that I know. I would appreciate if people could fill in for some others, I'll update this post with the explanations as people make posts. Please try to use the format that I use below for the thread pool patch so that I don't have to parse through it for the info. Thanks in advance for all who contribute!

Thread Pool Patch:
Current: http://www.benswebs.com/public/x264/patches/x264_thread_pool.04c.r680.diff
Other Current: http://mirror05.x264.nl/Cef/force.php?file=./patches/x264_thread_pool.r680.diff
Origin: http://forum.doom9.org/showthread.php?t=124557
Creator: akupenguin
Maintainer: morph166955/Cef
Description: Forces x264 to use the same threads over and over again instead of creating and destroying threads as needed. Speed benefits seen on Quad-Core and Octa-Core machines (as much as a 20% speed boost seen on my Octa-Core), either little or negative speed change seen on single and dual core systems. The current revision on Cef's site was modified by him to work with r680, the one on my site is basically the same.

Faster DIA patch:
Current:http://mirror05.x264.nl/Cef/force.php?file=./patches/x264_faster-dia.diff
Current:http://www.benswebs.com/public/x264/patches/x264_faster-dia.r680.diff
Creator/Maintainer: Dark Shikari
Description: Tiny patch, 3.5% faster DIA for better first pass.

Subme 7 Improvement
Current:http://mirror05.x264.nl/Cef/force.php?file=./patches/x264_subme7_vc8.diff
Creator/Maintainer: Dark Shikari
Description: Improved subme 7. Basically no speed impact, small quality boost.

SATD ESA Fullpel Comparison Patch:
Current: http://mirror05.x264.nl/Cef/force.php?file=./patches/x264_satd_fpel.11.diff
Creator/Maintainer: Dark Shikari
Description: Allows SATD to be used as a fullpel comparison metric. Totally useless with any search other than ESA, since the SATD ESA has been optimized so well by Akupenguin.

ME Prepass Patch:
Current: http://www.benswebs.com/public/x264/patches/x264_me-prepass_ham.diff (use with hadamard patch)
Current: http://www.benswebs.com/public/x264/patches/x264_me-prepass_noham.diff (use without hadamard patch)
Current: http://mirror05.x264.nl/Cef/force.php?file=./patches/x264_me-prepass.diff
Creator/Maintainer: Dark Shikari
Description: Runs an ME prepass on the predictors before actually doing the motion search. Somewhat bugged--it can probably be a lot better than it currently is.

IMH Motion Estimation Patch:
Current: http://mirror05.x264.nl/Cef/force.php?file=./patches/x264_IMH.diff
Creator/Maintainer: Dark Shikari
Description: A motion search slower than UMH but faster than ESA. Not that worthwhile since ESA is now threaded.

HD HRD/Pulldown Patch:
Current: http://mirror05.x264.nl/Cef/force.php?file=./patches/x264_hrd_pulldown.diff
Creator: Ian Caulfield/Trahald
Description: HRD and pulldown for HD compatibility.

http://mirror05.x264.nl/Cef/force.php?file=./patches/x264_bssd.diff

http://mirror05.x264.nl/Cef/force.php?file=./patches/x264_bchanges.diff

AQ/BRDO Patch:
Current: http://mirror05.x264.nl/Cef/force.php?file=./patches/x264_aq-brdo.diff
Description: This was added to the source a while ago, fixing a bug with AQ and BRDO.


http://mirror05.x264.nl/Cef/force.php?file=./patches/x264_2pass_vbv.diff

Second Pass ETA Patch:
Current: http://www.benswebs.com/public/x264/patches/x264_fp-eta.01.r680.diff
Creator/Maintainer: morph166955
Description: Forces x264 to use the frame count from the stats file on a second pass if the frame count can't be calculated for some reason (such as the use of a fifo pipe).

[Dark Shikari]

http://mirror05.x264.nl/Cef/force.php?file=./patches/x264_faster-dia.diff
Tiny patch, 3.5% faster DIA for better first pass.
http://mirror05.x264.nl/Cef/force.php?file=./patches/x264_subme7_vc8.diff
Improved subme 7. Basically no speed impact, small quality boost.
http://mirror05.x264.nl/Cef/force.php?file=./patches/x264_satd_fpel.11.diffAllows SATD to be used as a fullpel comparison metric. Totally useless with any search other than ESA, since the SATD ESA has been optimized so well by Akupenguin.

http://mirror05.x264.nl/Cef/force.php?file=./patches/x264_me-prepass.diff

Runs an ME prepass on the predictors before actually doing the motion search. Somewhat bugged--it can probably be a lot better than it currently is.

http://mirror05.x264.nl/Cef/force.php?file=./patches/x264_IMH.diff

A motion search slower than UMH but faster than ESA. Not that worthwhile since ESA is now threaded.

http://mirror05.x264.nl/Cef/force.php?file=./patches/x264_hrd_pulldown.diff

HRD and pulldown for HD compatibility.

http://mirror05.x264.nl/Cef/force.php?file=./patches/x264_aq-brdo.diff

This was added to the source a while ago, fixing a bug with AQ and BRDO.

[J_Darnley]

There is another patch, the clock/timing/progress one. I don't know if it still works, the diff I have is from rev. 614

http://users.telenet.be/darnley/x264_clock1-614.diff

It prints the total encoding time and prints process 10000 time per file instead of 1000

[Sharktooth]

moooo

[Dark Shikari]

Here's my fixed ME_Prepass patch.

Index: common/common.c
===================================================================
--- common/common.c (revision 675)
+++ common/common.c (working copy)
@@ -441,6 +441,8 @@
p->analyse.i_mv_range_thread = atoi(value);
OPT2("subme", "subq")
p->analyse.i_subpel_refine = atoi(value);
+ OPT2("me-prepass", "meprepass")
+ p->analyse.i_me_prepass = atobool(value);
OPT("bime")
p->analyse.b_bidir_me = atobool(value);
OPT("chroma-me")
@@ -879,6 +881,7 @@
s += sprintf( s, " analyse=%#x:%#x", p->analyse.intra, p->analyse.inter );
s += sprintf( s, " me=%s", x264_motion_est_names[ p->analyse.i_me_method ] );
s += sprintf( s, " subme=%d", p->analyse.i_subpel_refine );
+ s += sprintf( s, " me-prepass=%d", p->analyse.i_me_prepass );
s += sprintf( s, " brdo=%d", p->analyse.b_bframe_rdo );
s += sprintf( s, " mixed_ref=%d", p->analyse.b_mixed_references );
s += sprintf( s, " me_range=%d", p->analyse.i_me_range );
Index: encoder/me.c
===================================================================
--- encoder/me.c (revision 675)
+++ encoder/me.c (working copy)
@@ -61,6 +61,23 @@
COPY3_IF_LT( bpred_cost, cost, bpred_mx, mx, bpred_my, my ); \
}

+#define COST_MV_HPEL2( mx, my, cost ) \
+{ \
+ int stride = 16; \
+ uint8_t *src = h->mc.get_ref( m->p_fref, m->i_stride[0], pix, &stride, mx, my, bw, bh ); \
+ cost = h->pixf.fpelcmp[i_pixel]( m->p_fenc[0], FENC_STRIDE, src, stride ) \
+ + p_cost_mvx[ mx ] + p_cost_mvy[ my ]; \
+}
+
+#define COST_MV_HPEL3( mx, my) \
+{ \
+ int stride = 16; \
+ uint8_t *src = h->mc.get_ref( m->p_fref, m->i_stride[0], pix, &stride, mx, my, bw, bh ); \
+ int cost = h->pixf.fpelcmp[i_pixel]( m->p_fenc[0], FENC_STRIDE, src, stride ) \
+ + p_cost_mvx[ mx ] + p_cost_mvy[ my ]; \
+ COPY3_IF_LT( bestcost, cost, bestx, mx, besty, my ); \
+}
+
#define COST_MV_X3_DIR( m0x, m0y, m1x, m1y, m2x, m2y, costs )\
{\
uint8_t *pix_base = p_fref + bmx + bmy*m->i_stride[0];\
@@ -177,18 +194,85 @@
pmx = ( bmx + 2 ) >> 2;
pmy = ( bmy + 2 ) >> 2;
bcost = COST_MAX;
-
+
/* try extra predictors if provided */
if( h->mb.i_subpel_refine >= 3 )
{
COST_MV_HPEL( bmx, bmy );
- for( i = 0; i < i_mvc; i++ )
+ if(!h->param.analyse.i_me_prepass)
{
- const int mx = x264_clip3( mvc[i][0], mv_x_min*4, mv_x_max*4 );
- const int my = x264_clip3( mvc[i][1], mv_y_min*4, mv_y_max*4 );
- if( mx != bpred_mx || my != bpred_my )
- COST_MV_HPEL( mx, my );
+ for( i = 0; i < i_mvc; i++ )
+ {
+ const int mx = x264_clip3( mvc[i][0], mv_x_min*4, mv_x_max*4 );
+ const int my = x264_clip3( mvc[i][1], mv_y_min*4, mv_y_max*4 );
+ if( mx != bpred_mx || my != bpred_my )
+ COST_MV_HPEL( mx, my );
+ }
+ }
+ else
+ {
+ for( i = 0; i < i_mvc; i++ )
+ {
+ const int mx = x264_clip3( mvc[i][0], mv_x_min*4, mv_x_max*4 );
+ const int my = x264_clip3( mvc[i][1], mv_y_min*4, mv_y_max*4 );
+ int doSearch = 1;
+ int j;
+ for(j = 0; j < i; j++)
+ {
+ if(mvc[i][0] == mvc[j][0] && mvc[i][1] == mvc[j][1]) doSearch = 0;
+ }
+ if( ( mx != bpred_mx || my != bpred_my ) && doSearch)
+ {
+ int bestcost;
+ int bestx = mx;
+ int besty = my;
+ COST_MV_HPEL2( mx, my, bestcost );
+ COPY3_IF_LT( bpred_cost, bestcost, bpred_mx, bestx, bpred_my, besty );
+ if(bestcost < 2*bpred_cost)
+ {
+ int n;
+ int dir = -2;
+ COST_MV_HPEL2(bestx-4,besty,costs[0]);
+ COST_MV_HPEL2(bestx-2,besty+4,costs[1]);
+ COST_MV_HPEL2(bestx+2,besty+4,costs[2]);
+ COST_MV_HPEL2(bestx+4,besty,costs[3]);
+ COST_MV_HPEL2(bestx+2,besty-4,costs[4]);
+ COST_MV_HPEL2(bestx-2,besty-4,costs[5]);
+ COPY2_IF_LT( bestcost, costs[0], dir, 0 );
+ COPY2_IF_LT( bestcost, costs[1], dir, 1 );
+ COPY2_IF_LT( bestcost, costs[2], dir, 2 );
+ COPY2_IF_LT( bestcost, costs[3], dir, 3 );
+ COPY2_IF_LT( bestcost, costs[4], dir, 4 );
+ COPY2_IF_LT( bestcost, costs[5], dir, 5 );
+ if( dir != -2 )
+ {
+ static const int hex2[8][2] = {{-2,-4}, {-4,0}, {-2,4}, {2,4}, {4,0}, {2,-4}, {-2,-4}, {-4,0}};
+ bestx += hex2[dir+1][0];
+ besty += hex2[dir+1][1];
+ for( n = 1; n < i_me_range && CHECK_MVRANGE4(bestx, besty); n++ )
+ {
+ static const int mod6[8] = {5,0,1,2,3,4,5,0};
+ const int odir = mod6[dir+1];
+ COST_MV_HPEL2(hex2[odir+0][0]+bestx,hex2[odir+0][1]+besty,costs[0]);
+ COST_MV_HPEL2(hex2[odir+1][0]+bestx,hex2[odir+1][1]+besty,costs[1]);
+ COST_MV_HPEL2(hex2[odir+2][0]+bestx,hex2[odir+2][1]+besty,costs[2]);
+ dir = -2;
+ COPY2_IF_LT( bestcost, costs[0], dir, odir-1 );
+ COPY2_IF_LT( bestcost, costs[1], dir, odir );
+ COPY2_IF_LT( bestcost, costs[2], dir, odir+1 );
+ if( dir == -2 )
+ break;
+ bestx += hex2[dir+1][0];
+ besty += hex2[dir+1][1];
+ }
+ }
+ COST_MV_HPEL3(bestx+2,besty-2);
+ COST_MV_HPEL3(bestx+2,besty);
+ COST_MV_HPEL3(bestx+2,besty+2);
+ COST_MV_HPEL3(bestx,besty-2);
+ COST_MV_HPEL3(bestx,besty+2);
+ COST_MV_HPEL3(bestx-2,besty-2);
+ COST_MV_HPEL3(bestx-2,besty);
+ COST_MV_HPEL3(bestx-2,besty+2);
+ COPY3_IF_LT(bpred_cost,bestcost,bpred_mx,bestx,bpred_my,besty);
+ }
+ }
+ }
}
bmx = ( bpred_mx + 2 ) >> 2;
bmy = ( bpred_my + 2 ) >> 2;
COST_MV( bmx, bmy );
}
Index: x264.c
===================================================================
--- x264.c (revision 675)
+++ x264.c (working copy)
@@ -232,7 +232,8 @@
H1( " --mvrange-thread <int> Minimum buffer between threads [-1 (auto)]\n" );
H0( " -m, --subme <integer> Subpixel motion estimation and partition\n"
" decision quality: 1=fast, 7=best. [%d]\n", defaults->analyse.i_subpel_refine );
- H0( " --b-rdo RD based mode decision for B-frames. Requires subme 6.\n" );
+ H0( " --me-prepass Run an ME prepass on predictors. Requires subme 3 or higher.\n");
+ H0( " --b-rdo RD based mode decision for B-frames. Requires subme 6 or higher.\n" );
H0( " --mixed-refs Decide references on a per partition basis\n" );
H1( " --no-chroma-me Ignore chroma in motion estimation\n" );
H1( " --bime Jointly optimize both MVs in B-frames\n" );
@@ -398,6 +399,7 @@
{ "mvrange", required_argument, NULL, 0 },
{ "mvrange-thread", required_argument, NULL, 0 },
{ "subme", required_argument, NULL, 'm' },
+ { "me-prepass", no_argument, NULL, 0 },
{ "b-rdo", no_argument, NULL, 0 },
{ "mixed-refs", no_argument, NULL, 0 },
{ "no-chroma-me", no_argument, NULL, 0 },
Index: x264.h
===================================================================
--- x264.h (revision 675)
+++ x264.h (working copy)
@@ -220,6 +220,7 @@
int i_mv_range; /* maximum length of a mv (in pixels). -1 = auto, based on level */
int i_mv_range_thread; /* minimum space between threads. -1 = auto, based on number of threads. */
int i_subpel_refine; /* subpixel motion estimation quality */
+ int i_me_prepass; /* run an ME prepass on predictors */
int b_bidir_me; /* jointly optimize both MVs in B-frames */
int b_chroma_me; /* chroma ME for subpel and mode decision in P-frames */
int b_bframe_rdo; /* RD based mode decision for B-frames */

Speed: 25% faster (25% less impact on speed as compared to the old ME-prepass)
Quality: 42% better (42% more increase in quality as compared to the old ME-prepass)

Not surprisingly, eliminating the qpel aspect of the search gave a huge speed boost with an actual slight increase in quality.

[morph166955]

awesome! i'm heading off to bed but i'll update the first post in the morning.

One thing I noticed though was that the faster-dia patch came up saying unexpected end of file when I ran it (looked like it was missing a new line at the end). Just wanted to make sure it was just that and not a missing bit of code at the end or something.

[Dark Shikari]

awesome! i'm heading off to bed but i'll update the first post in the morning.

One thing I noticed though was that the faster-dia patch came up saying unexpected end of file when I ran it (looked like it was missing a new line at the end). Just wanted to make sure it was just that and not a missing bit of code at the end or something.
Nah, don't worry, just me being retarded I think.

[Terranigma]

Here's my fixed ME_Prepass patch.

Speed: 25% faster (25% less impact on speed as compared to the old ME-prepass)
Quality: 42% better (42% more increase in quality as compared to the old ME-prepass)

Not surprisingly, eliminating the qpel aspect of the search gave a huge speed boost with an actual slight increase in quality.

I would love to see a custom build with this a.s.a.p. :D

[morph166955]

Ok I just updated the first post a little, needs a few more tweaks. I also updated my site with a few of the patches and made some diffs that are clean against r680. Most notably, I made a diff on the new ME_Prepass that you posted the code for above as well as making a clean diff for the faster-dia patch. Both are on my site and the links are above. I'm going to try to keep my site updated with diff's as well as Cef's for people who want them.

[le_canz]

:thanks:

[morph166955]

Here's my fixed ME_Prepass patch.


Patch refuses to compile.
encoder/me.c: In function 'x264_me_search_ref':
encoder/me.c:229: error: 'x264_pixel_function_t' has no member named 'fpelcmp'
encoder/me.c:235: error: 'x264_pixel_function_t' has no member named 'fpelcmp'
encoder/me.c:236: error: 'x264_pixel_function_t' has no member named 'fpelcmp'
encoder/me.c:237: error: 'x264_pixel_function_t' has no member named 'fpelcmp'
encoder/me.c:238: error: 'x264_pixel_function_t' has no member named 'fpelcmp'
encoder/me.c:239: error: 'x264_pixel_function_t' has no member named 'fpelcmp'
encoder/me.c:240: error: 'x264_pixel_function_t' has no member named 'fpelcmp'
encoder/me.c:252: warning: implicit declaration of function 'CHECK_MVRANGE4'
encoder/me.c:256: error: 'x264_pixel_function_t' has no member named 'fpelcmp'
encoder/me.c:257: error: 'x264_pixel_function_t' has no member named 'fpelcmp'
encoder/me.c:258: error: 'x264_pixel_function_t' has no member named 'fpelcmp'
encoder/me.c:269: error: 'x264_pixel_function_t' has no member named 'fpelcmp'
encoder/me.c:270: error: 'x264_pixel_function_t' has no member named 'fpelcmp'
encoder/me.c:271: error: 'x264_pixel_function_t' has no member named 'fpelcmp'
encoder/me.c:272: error: 'x264_pixel_function_t' has no member named 'fpelcmp'
encoder/me.c:273: error: 'x264_pixel_function_t' has no member named 'fpelcmp'
encoder/me.c:274: error: 'x264_pixel_function_t' has no member named 'fpelcmp'
encoder/me.c:275: error: 'x264_pixel_function_t' has no member named 'fpelcmp'
encoder/me.c:276: error: 'x264_pixel_function_t' has no member named 'fpelcmp'
make: *** [encoder/me.o] Error 1

[Dark Shikari]

Patch refuses to compile.
encoder/me.c: In function 'x264_me_search_ref':
encoder/me.c:229: error: 'x264_pixel_function_t' has no member named 'fpelcmp'
encoder/me.c:235: error: 'x264_pixel_function_t' has no member named 'fpelcmp'
encoder/me.c:236: error: 'x264_pixel_function_t' has no member named 'fpelcmp'
encoder/me.c:237: error: 'x264_pixel_function_t' has no member named 'fpelcmp'
encoder/me.c:238: error: 'x264_pixel_function_t' has no member named 'fpelcmp'
encoder/me.c:239: error: 'x264_pixel_function_t' has no member named 'fpelcmp'
encoder/me.c:240: error: 'x264_pixel_function_t' has no member named 'fpelcmp'
encoder/me.c:252: warning: implicit declaration of function 'CHECK_MVRANGE4'
encoder/me.c:256: error: 'x264_pixel_function_t' has no member named 'fpelcmp'
encoder/me.c:257: error: 'x264_pixel_function_t' has no member named 'fpelcmp'
encoder/me.c:258repl: error: 'x264_pixel_function_t' has no member named 'fpelcmp'
encoder/me.c:269: error: 'x264_pixel_function_t' has no member named 'fpelcmp'
encoder/me.c:270: error: 'x264_pixel_function_t' has no member named 'fpelcmp'
encoder/me.c:271: error: 'x264_pixel_function_t' has no member named 'fpelcmp'
encoder/me.c:272: error: 'x264_pixel_function_t' has no member named 'fpelcmp'
encoder/me.c:273: error: 'x264_pixel_function_t' has no member named 'fpelcmp'
encoder/me.c:274: error: 'x264_pixel_function_t' has no member named 'fpelcmp'
encoder/me.c:275: error: 'x264_pixel_function_t' has no member named 'fpelcmp'
encoder/me.c:276: error: 'x264_pixel_function_t' has no member named 'fpelcmp'
make: *** [encoder/me.o] Error 1

That's because if you want to compile ME-prepass without the Hadamard patch (--fpelcmp), you must replace all instances of "fpelcmp" with "sad" in me.c. Find/replace. They modify some of the same lines so I can't create a generic patch for this reason.

And also, oops, another small mistake in the patch--should be easily fixable:

replace
int mv_x_min = h->mb.mv_min_fpel[0];
int mv_y_min = h->mb.mv_min_fpel[1];
int mv_x_max = h->mb.mv_max_fpel[0];
int mv_y_max = h->mb.mv_max_fpel[1];

#define CHECK_MVRANGE(mx,my) ( mx >= mv_x_min && mx <= mv_x_max && my >= mv_y_min && my <= mv_y_max )
with
int mv_x_min = h->mb.mv_min_fpel[0];
int mv_y_min = h->mb.mv_min_fpel[1];
int mv_x_max = h->mb.mv_max_fpel[0];
int mv_y_max = h->mb.mv_max_fpel[1];
int mv_x_min4 = h->mb.mv_min_fpel[0]<<2;
int mv_y_min4 = h->mb.mv_min_fpel[1]<<2;
int mv_x_max4 = h->mb.mv_max_fpel[0]<<2;
int mv_y_max4 = h->mb.mv_max_fpel[1]<<2;

#define CHECK_MVRANGE(mx,my) ( mx >= mv_x_min && mx <= mv_x_max && my >= mv_y_min && my <= mv_y_max )
#define CHECK_MVRANGE4(mx,my) ( mx >= mv_x_min4 && mx <= mv_x_max4 && my >= mv_y_min4 && my <= mv_y_max4 )

I forgot to include this in the diff.

Sorry I don't have a better diff, but my version control is nonexistent ;) I assume you can probably make a new diff once these are fixed.

[morph166955]

got it, new diff's creted, original post updated to have both options (w/ and w/o hadamard)

[Dark Shikari]

Some mistakes in your post... not all those that I explained were created or maintained by me ;)

AQ/BRDO isn't mine, HRD isn't mine.

[lexor]

I've asked this question in the multi-thread discussion, but answers were inconclusive, so I'll ask it here again.

Are these patches actually applied to Cef's builds? At first I was told that thread_pool patch is applied, but then someone said that it didn't work with 680 and had to be fixed (which it is now), so it couldn't have been applied before.

So perhaps we need another line for each patch stating if it is applied?

[morph166955]

fixed.

[Trahald]

the hrd in the patch was done by Ian Caulfield and the pulldown part I added.

[morph166955]

updated.

[martino]

I'd also like to know as to which patches are present in Cef's build. I don't mean the "dark" or "exp" version. It's just confusing, since there seem to be a few builds, more patches, and to me it looks like a hell of mess where trying to find an answer is rather hard...

Thanks

[Sagekilla]

Would be nice if there was a little scrollover icon that would tell you what patches (that haven't been merged in to the main build) are applied to it..

Edit: Also, I too would like to know what patches are in cef's latest build.

[Terranigma]

I'd also like to know as to which patches are present in Cef's build. I don't mean the "dark" or "exp" version. It's just confusing, since there seem to be a few builds, more patches, and to me it looks like a hell of mess where trying to find an answer is rather hard...

Thanks
I guess you didn't see This (http://forum.doom9.org/showpost.php?p=1048519&postcount=113) ?
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? :scared:

[Dark Shikari]

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.

[Terranigma]

Also add the --subme 7 patch, since its been proven quite thoroughly to increase quality in basically all cases at minimal speed cost.
Oh I thought the new subme-7 made it to the svn, seems I was wrong :p


Faster DIA, IMH, and SATD shouldn't be applied yet.

I agree with you on imh and dia (At first I was all for imh, but suddenly I changed my mind :D).

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.


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 :)

[akupenguin]

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.

[Dark Shikari]

Not sure I like HES, too similar to HEX. Maybe TES (same "T"ransform as in SATD). Or ESH.TES seems fine to me; it avoids starting with the same letter as any of the others.

[fields_g]

However, SATD ESA is so heavily optimized that its still useful, and not too much slower than regular ESA.

Here's another solution... set regular ESA to SATD ESA?

Let SAD IMH be the (speed) middle ground between SAD UMH and SATD ESA?

akupenguin, could you update your chart here (http://forum.doom9.org/showthread.php?p=1047085#post1047085) with Dark Shikari's new ME-prepass found here (http://forum.doom9.org/showthread.php?p=1050161#post1050161)?

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.

[Dark Shikari]

Here's another solution... set regular ESA to SATD ESA?

Let SAD IMH be the (speed) middle ground between SAD UMH and SATD ESA?

akupenguin, could you update your chart here (http://forum.doom9.org/showthread.php?p=1047085#post1047085) with Dark Shikari's new ME-prepass found here (http://forum.doom9.org/showthread.php?p=1050161#post1050161)?

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.Shouldn't force users to use what they don't want to--better to give them the option.

[fields_g]

Shouldn't force users to use what they don't want to--better to give them the option.

I agree.. I am just looking for some other option to making another me-type that really isn't anything but a preset. Make the defaults best practices and allow switches to deviate.

How about normal default esa be SATD and with a switch it can SAD and ditch the new me-type. All choices still remain.

[Dark Shikari]

I agree.. I am just looking for some other option to making another me-type that really isn't anything but a preset. Make the defaults best practices and allow switches to deviate.

How about normal default esa be SATD and with a switch it can SAD and ditch the new me-type. All choices still remain.
How is using --fpel-cmp satd on ESA a "best practice"? Its even slower than regular ESA, and so only useful for those who have even more time to waste.

Also note that if TES/whatever its called uses SATD, the --fpel-cmp satd option will be removed.

[akupenguin]

How about normal default esa be SATD and with a switch it can SAD and ditch the new me-type. All choices still remain.
A new value for --me is simpler interface-wise than a new top-level option.

[fields_g]

How is using --fpel-cmp satd on ESA a "best practice"? Its even slower than regular ESA, and so only useful for those who have even more time to waste.

Also note that if TES/whatever its called uses SATD, the --fpel-cmp satd option will be removed.

Using the chart (http://forum.doom9.org/showthread.php?p=1047085#post1047085) as an approximation roughly:
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.

[Dark Shikari]

Using the chart (http://forum.doom9.org/showthread.php?p=1047085#post1047085) as an approximation roughly:
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.Except that on some sources, SATD is inferior to SAD as a metric ;)

Anime in particular seems to suffer from this, in my experience.

[fields_g]

Except that on some sources, SATD is inferior to SAD as a metric ;)

Anime in particular seems to suffer from this, in my experience.

I was just about to state that I might be overusing this single chart (source) a bit! I'll be downloading one of these fancy "bundle-o-patches" builds and start going at it! Quite honestly, I'll be able to follow either scheme and will be happy as long as I have prepass SATD ESA around in some form, especially with the improvements listed here (http://forum.doom9.org/showthread.php?p=1050161#post1050161).

[Cef]

I'd also like to know as to which patches are present in Cef's build. I don't mean the "dark" or "exp" version. It's just confusing, since there seem to be a few builds, more patches, and to me it looks like a hell of mess where trying to find an answer is rather hard...

Thanks

As I already said, my builds have AQ and thread pool applied. x264_xxx_dark was including all Dark_shikari's patches at the time it was posted (except faster first pass iirc), and x264_xxx_exp was a build requested by Sagittaire with some Dark's patches and hrd.

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.

[martino]

I guess you didn't see This (http://forum.doom9.org/showpost.php?p=1048519&postcount=113) ?
I did in fact, and heck. At this point there are two AQ patches. ;_;

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.

[Terranigma]

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 (http://forum.doom9.org/showpost.php?p=1046740&postcount=41). I'm not sure if that's the latest, so he's the only one that can confirm or deny this.

[Dark Shikari]

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 (http://forum.doom9.org/showpost.php?p=1046740&postcount=41). I'm not sure if that's the latest, so he's the only one that can confirm or deny this.New AQ is definitely not ready, and that is quite old IIRC.

Don't add it yet. Its way too experimental.

[DeathTheSheep]

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.

[Terranigma]

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.


Speed: 25% faster (25% less impact on speed as compared to the old ME-prepass)
Quality: 42% better (42% more increase in quality as compared to the old ME-prepass)

Not surprisingly, eliminating the qpel aspect of the search gave a huge speed boost with an actual slight increase in quality.

42% is a huge difference, or so I would think :scared:

[Dark Shikari]

42% is a huge difference, or so I would think :scared:

Let's say the original gave a 2% quality boost.

42% better quality over the original ME Prepass = 2.84% quality boost.

[Terranigma]

Let's say the original gave a 2% quality boost.

42% better quality over the original ME Prepass = 2.84% quality boost.

good enough for me, and it's faster to boot. :)

[DeathTheSheep]

They behave identically on my system. Bit-for-bit identical outputs, and no speed boost to boot!

I'm using the 9.29KB me-prepass diff from the first post. It's a bit bigger than the one I used before, so I assume it's new.
Started from fresh r680 source and applied (in order) satd, subme7, me-prepass.

Yep.

[edit] Ah, wait, finally at merange 4 I notice a teensy weensy bit of difference (<.1%). Probably compiler differences, though, since I updated GCC. :p But anyone who uses merange 4 is truly insane, and for a different reason. :D

[Dark Shikari]

They behave identically on my system. Bit-for-bit identical outputs, and no speed boost to boot!

I'm using the 9.29KB me-prepass diff from the first post. It's a bit bigger than the one I used before, so I assume it's new.
Started from fresh r680 source and applied (in order) satd, subme7, me-prepass.

Yep.

[edit] Ah, wait, finally at merange 4 I notice a teensy weensy bit of difference (<.1%). Probably compiler differences, though, since I updated GCC. :p But anyone who uses merange 4 is truly insane, and for a different reason. :DThat would be because the one in the original post is the old ME patch, which still hasn't been updated ;)

[DeathTheSheep]

Ok I just updated the first post a little, needs a few more tweaks. I also updated my site with a few of the patches and made some diffs that are clean against r680. Most notably, I made a diff on the new ME_Prepass that you posted the code for above as well as making a clean diff for the faster-dia patch. Both are on my site and the links are above. I'm going to try to keep my site updated with diff's as well as Cef's for people who want them.

Really? He seems to indicate otherwise. So does the difference in filesize... But I'll actually have a look at the code now... :D

[Dark Shikari]

Really? He seems to indicate otherwise. So does the difference in filesize... But I'll actually have a look at the code now... :D
The numbers in the patch look quite different from those in the diff I posted :p

[fields_g]

Would it be possible to have a reversion number line commented into the diff file, or is that against file syntax? I'd love to be able to say "compare version xxx with yyy"!

[Dark Shikari]

Would it be possible to have a reversion number line commented into the diff file, or is that against file syntax? I'd love to be able to say "compare version xxx with yyy"!SVN diff does this.

[fields_g]

SVN diff does this.

Great! Trying to identify a patch revision as "the one found in post xxx" or for example "the original AQ" vs. "Dark Shikari's old AQ" vs. "Dark Shikari's new AQ" is a bit complicated/limited if there is more than a couple variations. (Don't you love that we have bright people here developing new things to try?)

This will help people who are making builds explicitly describe what is in their builds also!

[burfadel]

I still think --me-prepass should be added as a default option. It should be enabled on principle for subme modes 6 and definately 7, and optional on 3,4,5. Realistically, if people choose subme mode 7 they're aiming for quality/filesize, it hardly would seem logical to select subme 7 but refuse to use the --me-prepass command!

[fields_g]

I still think --me-prepass should be added as a default option. It should be enabled on principle for subme modes 6 and definately 7, and optional on 3,4,5. Realistically, if people choose subme mode 7 they're aiming for quality/filesize, it hardly would seem logical to select subme 7 but refuse to use the --me-prepass command!

Interesting... I'm not sure, but either you are suggesting a new approach or are mixing two different (though related) things together.

1) There is a ME type: Dia, Hex, UMH, ESA
2) There is a subpixel refinement of 1-7

Discussion before as questioned making prepass dependent on ME type (if ESA then ON, else OFF), not subpixel refinement. I'll let someone else comment on how wise it would be to connect prepass to subpixel refinement.

[burfadel]

I didn't mean to connect it in that sense :) it could be also suggested to have --me-prepass enabled when UMH mode is selected (no point for ESA I believe?...), just as a matter of principle, since mode 7 or UMH are usually selected for quality.

[Terranigma]

I still think --me-prepass should be added as a default option.
Yes, I agree. Aku, any chance we'll ever see this in the svn? I could care less now about imh, but prepass, otoh, is pretty useful with esa as you've shown from your graphical comparisons. :)

[DeathTheSheep]

How the heck do you apply this diff to the source? What program?!

I always get crap like this every time I apply these patches:

$ patch -u -p1 < subme7.diff
can't find file to patch at input line 5
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: encoder/me.c
|===================================================================
|--- encoder/me.c (revision 676)
|+++ encoder/me.c (working copy)
--------------------------
File to patch: encoder/me.c
patching file `encoder/me.c'
Hunk #1 succeeded at 28 (offset 1 line).
Hunk #2 succeeded at 853 (offset 51 lines).
patch unexpectedly ends in middle of line
Hunk #3 FAILED at 912.
1 out of 3 hunks FAILED -- saving rejects to encoder/me.c.rej

Then I manually patch. And that's just for subme.. Take a look at prepass:

$ patch -u -p1 < me-prepass.diff
can't find file to patch at input line 5
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: common/common.c
|===================================================================
|--- common/common.c (revision 675)
|+++ common/common.c (working copy)
--------------------------
File to patch: common/common.c
patching file `common/common.c'
Hunk #1 succeeded at 444 (offset 3 lines).
Hunk #2 succeeded at 882 with fuzz 2 (offset 1 line).
can't find file to patch at input line 26
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: encoder/me.c
|===================================================================
|--- encoder/me.c (revision 675)
|+++ encoder/me.c (working copy)
--------------------------
File to patch: encoder/me.c
patching file `encoder/me.c'
Hunk #1 succeeded at 65 (offset 4 lines).
patch: **** malformed patch at line 142: + }

And nothing happens at all. No .rej is created to manually patch off of like for subme, so I have to go through line by line and type it all in by hand.

I think I'm going to memorize this algorithm by heart by the time I'm through with these darn patch problems!

Again, how do you guys do it?! I'm in msys 1.0 using the standard $ patch program... the settings I used are shown above...

[DeathTheSheep]

And what exactly happened to cost_mv_hpel? You go right from cost_mv to cost_mv_hpel2... It's still used, but its define is gone? :p

Maybe you just have some odd organization and moved it somewhere else in the code so the patch's context is off. I'm glad I caught that, though--I just wonder what other crucial instructions I've unwittingly overwritten as I blindly followed the patch?! :D

[Dark Shikari]

And what exactly happened to cost_mv_hpel? You go right from cost_mv to cost_mv_hpel2... It's still used, but its define is gone? :p

Maybe you just have some odd organization and moved it somewhere else in the code so the patch's context is off. I'm glad I caught that, though--I just wonder what other crucial instructions I've unwittingly overwritten as I blindly followed the patch?! :D
Hpel is in the original code, so it doesn't need to be defined again :p

[DeathTheSheep]

True, but in the context of your patch, it jumps right from cost_mv (which is already defined) to cost_mv_hpel2. Meaning when I insert it over the context (first and last lines in your patch), it is no longer in the original source!

Meaning, of course, when I Ctrl+A to select all the code for each code block in the patch and paste that block into the .c, I simply start from the first context line and overwrite everything in the original until the last context line, meaning everything in between is overwritten with the lines of the patch.

I then go in and delete all the little "+" signs next to the added lines and manually remove all the lines marked with "-." I know hpel is not "removed" as in marked with the "-", but if you look at your patch's context lines...
So you can understand why the patch threw me off :).

Index: encoder/me.c
===================================================================
--- encoder/me.c (revision 675)
+++ encoder/me.c (working copy)
@@ -61,6 +61,23 @@
COPY3_IF_LT( bpred_cost, cost, bpred_mx, mx, bpred_my, my ); \ (this is the first line I overwrote, extending to the end...)
}

<but hpel was in here, so it disappeared when I overwrote it with this patch, since it's obviously not here now!>

+#define COST_MV_HPEL2( mx, my, cost ) \
+{ \
+ int stride = 16; \
+ uint8_t *src = h->mc.get_ref( m->p_fref, m->i_stride[0], pix, &stride, mx, my, bw, bh ); \
+ cost = h->pixf.fpelcmp[i_pixel]( m->p_fenc[0], FENC_STRIDE, src, stride ) \
+ + p_cost_mvx[ mx ] + p_cost_mvy[ my ]; \
+}

:p

[Dark Shikari]

Sorry if my diffing skills are nonexistent :p

[DeathTheSheep]

Lol, no problem. But next time could you put up the whole function (or source code?) instead of the diff? Much easier to manually apply that way. :D

Oh, I noticed the new prepass beefs up the filesize along with the SSIM at constant quantization. Is this normal, or is something b0rked for me?

And quality remains constant (and filesize increases!) as merange is increased... FtW? :p Tested with esa, of course... Satd.

[edit]Yes, as I suspected there is something hideously wrong here. Without any prepass at all, differs drastically from an old build without it. Yeah, some patched sources would help like crazy. XD

[Dark Shikari]

Lol, no problem. But next time could you put up the whole function (or source code?) instead of the diff? Much easier to manually apply that way. :D

Oh, I noticed the new prepass beefs up the filesize along with the SSIM at constant quantization. Is this normal, or is something b0rked for me?

And quality remains constant (and filesize increases!) as merange is increased... FtW? :p Tested with esa, of course... Satd.

[edit]Yes, as I suspected there is something hideously wrong here. Without any prepass at all, differs drastically from an old build without it. Yeah, some patched sources would help like crazy. XD
Here is the beginning of my source up to the start of ME-DIA and such:

/*****************************************************************************
* me.c: h264 encoder library (Motion Estimation)
*****************************************************************************
* Copyright (C) 2003 Laurent Aimar
* $Id: me.c,v 1.1 2004/06/03 19:27:08 fenrir Exp $
*
* Authors: Laurent Aimar <fenrir@via.ecp.fr>
* Loren Merritt <lorenm@u.washington.edu>
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111, USA.
*****************************************************************************/

#include "common/common.h"
#include "me.h"
#include <limits.h>

/* presets selected from good points on the speed-vs-quality curve of several test videos
* subpel_iters[i_subpel_refine] = { refine_hpel, refine_qpel, me_hpel, me_qpel }
* where me_* are the number of EPZS iterations run on all candidate block types,
* and refine_* are run only on the winner. */
//The --subme 7 values are much higher because since they get the motion search
//closer to the optimal value, they actually tend to save time in the more intensive
//RD search that follows.
static const int subpel_iterations[][4] =
{{1,0,0,0},
{1,1,0,0},
{0,1,1,0},
{0,2,1,0},
{0,2,1,1},
{0,2,1,2},
{0,0,2,2},
{0,0,4,10}};

static void refine_subpel( x264_t *h, x264_me_t *m, int hpel_iters, int qpel_iters, int *p_halfpel_thresh, int b_refine_qpel );

#define BITS_MVD( mx, my )\
(p_cost_mvx[(mx)<<2] + p_cost_mvy[(my)<<2])

#define COST_MV( mx, my )\
{\
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);\
COPY3_IF_LT( bcost, cost, bmx, mx, bmy, my );\
}

#define COST_MV_HPEL( mx, my ) \
{ \
int stride = 16; \
uint8_t *src = h->mc.get_ref( m->p_fref, m->i_stride[0], pix, &stride, mx, my, bw, bh ); \
int cost = h->pixf.fpelcmp[i_pixel]( m->p_fenc[0], FENC_STRIDE, src, stride ) \
+ p_cost_mvx[ mx ] + p_cost_mvy[ my ]; \
COPY3_IF_LT( bpred_cost, cost, bpred_mx, mx, bpred_my, my ); \
}

#define COST_MV_HPEL2( mx, my, cost ) \
{ \
int stride = 16; \
uint8_t *src = h->mc.get_ref( m->p_fref, m->i_stride[0], pix, &stride, mx, my, bw, bh ); \
cost = h->pixf.fpelcmp[i_pixel]( m->p_fenc[0], FENC_STRIDE, src, stride ) \
+ p_cost_mvx[ mx ] + p_cost_mvy[ my ]; \
}

#define COST_MV_HPEL3( mx, my) \
{ \
int stride = 16; \
uint8_t *src = h->mc.get_ref( m->p_fref, m->i_stride[0], pix, &stride, mx, my, bw, bh ); \
int cost = h->pixf.fpelcmp[i_pixel]( m->p_fenc[0], FENC_STRIDE, src, stride ) \
+ p_cost_mvx[ mx ] + p_cost_mvy[ my ]; \
COPY3_IF_LT( bestcost, cost, bestx, mx, besty, my ); \
}

#define COST_MV_X3_DIR( m0x, m0y, m1x, m1y, m2x, m2y, costs )\
{\
uint8_t *pix_base = p_fref + bmx + bmy*m->i_stride[0];\
h->pixf.fpelcmp_x3[i_pixel]( m->p_fenc[0],\
pix_base + (m0x) + (m0y)*m->i_stride[0],\
pix_base + (m1x) + (m1y)*m->i_stride[0],\
pix_base + (m2x) + (m2y)*m->i_stride[0],\
m->i_stride[0], costs );\
(costs)[0] += BITS_MVD( bmx+(m0x), bmy+(m0y) );\
(costs)[1] += BITS_MVD( bmx+(m1x), bmy+(m1y) );\
(costs)[2] += BITS_MVD( bmx+(m2x), bmy+(m2y) );\
}

#define COST_MV_X4( m0x, m0y, m1x, m1y, m2x, m2y, m3x, m3y )\
{\
uint8_t *pix_base = p_fref + omx + omy*m->i_stride[0];\
h->pixf.fpelcmp_x4[i_pixel]( m->p_fenc[0],\
pix_base + (m0x) + (m0y)*m->i_stride[0],\
pix_base + (m1x) + (m1y)*m->i_stride[0],\
pix_base + (m2x) + (m2y)*m->i_stride[0],\
pix_base + (m3x) + (m3y)*m->i_stride[0],\
m->i_stride[0], costs );\
costs[0] += BITS_MVD( omx+(m0x), omy+(m0y) );\
costs[1] += BITS_MVD( omx+(m1x), omy+(m1y) );\
costs[2] += BITS_MVD( omx+(m2x), omy+(m2y) );\
costs[3] += BITS_MVD( omx+(m3x), omy+(m3y) );\
COPY3_IF_LT( bcost, costs[0], bmx, omx+(m0x), bmy, omy+(m0y) );\
COPY3_IF_LT( bcost, costs[1], bmx, omx+(m1x), bmy, omy+(m1y) );\
COPY3_IF_LT( bcost, costs[2], bmx, omx+(m2x), bmy, omy+(m2y) );\
COPY3_IF_LT( bcost, costs[3], bmx, omx+(m3x), bmy, omy+(m3y) );\
}

#define COST_MV_X4_ABS( m0x, m0y, m1x, m1y, m2x, m2y, m3x, m3y )\
{\
h->pixf.fpelcmp_x4[i_pixel]( m->p_fenc[0],\
p_fref + (m0x) + (m0y)*m->i_stride[0],\
p_fref + (m1x) + (m1y)*m->i_stride[0],\
p_fref + (m2x) + (m2y)*m->i_stride[0],\
p_fref + (m3x) + (m3y)*m->i_stride[0],\
m->i_stride[0], costs );\
costs[0] += p_cost_mvx[m0x<<2]; /* no cost_mvy */\
costs[1] += p_cost_mvx[m1x<<2];\
costs[2] += p_cost_mvx[m2x<<2];\
costs[3] += p_cost_mvx[m3x<<2];\
COPY3_IF_LT( bcost, costs[0], bmx, m0x, bmy, m0y );\
COPY3_IF_LT( bcost, costs[1], bmx, m1x, bmy, m1y );\
COPY3_IF_LT( bcost, costs[2], bmx, m2x, bmy, m2y );\
COPY3_IF_LT( bcost, costs[3], bmx, m3x, bmy, m3y );\
}

/* 1 */
/* 101 */
/* 1 */
#define DIA1_ITER( mx, my )\
{\
omx = mx; omy = my;\
COST_MV_X4( 0,-1, 0,1, -1,0, 1,0 );\
}

#define DIA2_ITER( mx, my )\
{\
omx = mx; omy = my;\
COST_MV_X4( 0,-2, 0,2, -2,0, 2,0 );\
}

#define CROSS( start, x_max, y_max )\
{\
i = start;\
if( x_max <= X264_MIN(mv_x_max-omx, omx-mv_x_min) )\
for( ; i < x_max-2; i+=4 )\
COST_MV_X4( i,0, -i,0, i+2,0, -i-2,0 );\
for( ; i < x_max; i+=2 )\
{\
if( omx+i <= mv_x_max )\
COST_MV( omx+i, omy );\
if( omx-i >= mv_x_min )\
COST_MV( omx-i, omy );\
}\
i = start;\
if( y_max <= X264_MIN(mv_y_max-omy, omy-mv_y_min) )\
for( ; i < y_max-2; i+=4 )\
COST_MV_X4( 0,i, 0,-i, 0,i+2, 0,-i-2 );\
for( ; i < y_max; i+=2 )\
{\
if( omy+i <= mv_y_max )\
COST_MV( omx, omy+i );\
if( omy-i >= mv_y_min )\
COST_MV( omx, omy-i );\
}\
}

#define ME_HEX(X,Y,range)\
{\
static const int mod6[8] = {5,0,1,2,3,4,5,0};\
bmx = X;\
bmy = Y;\
dir = -2;\
COST_MV_X3_DIR( -2,0, -1, 2, 1, 2, costs );\
COST_MV_X3_DIR( 2,0, 1,-2, -1,-2, costs+3 );\
COPY2_IF_LT( bcost, costs[0], dir, 0 );\
COPY2_IF_LT( bcost, costs[1], dir, 1 );\
COPY2_IF_LT( bcost, costs[2], dir, 2 );\
COPY2_IF_LT( bcost, costs[3], dir, 3 );\
COPY2_IF_LT( bcost, costs[4], dir, 4 );\
COPY2_IF_LT( bcost, costs[5], dir, 5 );\
if( dir != -2 ) {\
static const int hex2[8][2] = {{-1,-2}, {-2,0}, {-1,2}, {1,2}, {2,0}, {1,-2}, {-1,-2}, {-2,0}};\
bmx += hex2[dir+1][0];\
bmy += hex2[dir+1][1];\
for( i = 1; i < range && CHECK_MVRANGE(bmx, bmy); i++ )\
{\
const int odir = mod6[dir+1];\
COST_MV_X3_DIR( hex2[odir+0][0], hex2[odir+0][1],\
hex2[odir+1][0], hex2[odir+1][1],\
hex2[odir+2][0], hex2[odir+2][1],\
costs );\
dir = -2;\
COPY2_IF_LT( bcost, costs[0], dir, odir-1 );\
COPY2_IF_LT( bcost, costs[1], dir, odir );\
COPY2_IF_LT( bcost, costs[2], dir, odir+1 );\
if( dir == -2 ) break;\
bmx += hex2[dir+1][0];\
bmy += hex2[dir+1][1];}\
if(dir == -2 || bcost > bestCost) {}\
else{\
for( i = 1; i < range && CHECK_MVRANGE(bmx, bmy); i++ )\
{\
const int odir = mod6[dir+1];\
COST_MV_X3_DIR( hex2[odir+0][0], hex2[odir+0][1],\
hex2[odir+1][0], hex2[odir+1][1],\
hex2[odir+2][0], hex2[odir+2][1],\
costs );\
dir = -2;\
COPY2_IF_LT( bcost, costs[0], dir, odir-1 );\
COPY2_IF_LT( bcost, costs[1], dir, odir );\
COPY2_IF_LT( bcost, costs[2], dir, odir+1 );\
if( dir == -2 ) break;\
bmx += hex2[dir+1][0];\
bmy += hex2[dir+1][1];}}}\
omx = bmx; omy = bmy;\
COST_MV_X4( 0,-1, 0,1, -1,0, 1,0 );\
COST_MV_X4( -1,-1, -1,1, 1,-1, 1,1 );\
}\

void x264_me_search_ref( x264_t *h, x264_me_t *m, int (*mvc)[2], int i_mvc, int *p_halfpel_thresh )
{
int cost;
const int bw = x264_pixel_size[m->i_pixel].w;
const int bh = x264_pixel_size[m->i_pixel].h;
const int i_pixel = m->i_pixel;
int i_me_range = h->param.analyse.i_me_range;
int bmx, bmy, bcost;
int bpred_mx = 0, bpred_my = 0, bpred_cost = COST_MAX;
int omx, omy, pmx, pmy;
uint8_t *p_fref = m->p_fref[0];
DECLARE_ALIGNED( uint8_t, pix[16*16], 16 );

int i, j;
int dir;
int costs[6];

int mv_x_min = h->mb.mv_min_fpel[0];
int mv_y_min = h->mb.mv_min_fpel[1];
int mv_x_max = h->mb.mv_max_fpel[0];
int mv_y_max = h->mb.mv_max_fpel[1];
int mv_x_min4 = h->mb.mv_min_fpel[0]<<2;
int mv_y_min4 = h->mb.mv_min_fpel[1]<<2;
int mv_x_max4 = h->mb.mv_max_fpel[0]<<2;
int mv_y_max4 = h->mb.mv_max_fpel[1]<<2;

#define CHECK_MVRANGE(mx,my) ( mx >= mv_x_min && mx <= mv_x_max && my >= mv_y_min && my <= mv_y_max )
#define CHECK_MVRANGE4(mx,my) ( mx >= mv_x_min4 && mx <= mv_x_max4 && my >= mv_y_min4 && my <= mv_y_max4 )

const int16_t *p_cost_mvx = m->p_cost_mv - m->mvp[0];
const int16_t *p_cost_mvy = m->p_cost_mv - m->mvp[1];

bmx = x264_clip3( m->mvp[0], mv_x_min*4, mv_x_max*4 );
bmy = x264_clip3( m->mvp[1], mv_y_min*4, mv_y_max*4 );
pmx = ( bmx + 2 ) >> 2;
pmy = ( bmy + 2 ) >> 2;
bcost = COST_MAX;

/* try extra predictors if provided */
if( h->mb.i_subpel_refine >= 3 )
{
COST_MV_HPEL( bmx, bmy );
if(!h->param.analyse.i_me_prepass)
{
for( i = 0; i < i_mvc; i++ )
{
const int mx = x264_clip3( mvc[i][0], mv_x_min*4, mv_x_max*4 );
const int my = x264_clip3( mvc[i][1], mv_y_min*4, mv_y_max*4 );
if( mx != bpred_mx || my != bpred_my )
COST_MV_HPEL( mx, my );
}
}
else
{
for( i = 0; i < i_mvc; i++ )
{
const int mx = x264_clip3( mvc[i][0], mv_x_min*4, mv_x_max*4 );
const int my = x264_clip3( mvc[i][1], mv_y_min*4, mv_y_max*4 );
int doSearch = 1;
int j;
for(j = 0; j < i; j++)
{
if(mvc[i][0] == mvc[j][0] && mvc[i][1] == mvc[j][1]) doSearch = 0;
}
if( ( mx != bpred_mx || my != bpred_my ) && doSearch)
{
int bestcost;
int bestx = mx;
int besty = my;
COST_MV_HPEL2( mx, my, bestcost );
COPY3_IF_LT( bpred_cost, bestcost, bpred_mx, bestx, bpred_my, besty );
if(bestcost < 2*bpred_cost)
{
int n;
int dir = -2;
COST_MV_HPEL2(bestx-4,besty,costs[0]);
COST_MV_HPEL2(bestx-2,besty+4,costs[1]);
COST_MV_HPEL2(bestx+2,besty+4,costs[2]);
COST_MV_HPEL2(bestx+4,besty,costs[3]);
COST_MV_HPEL2(bestx+2,besty-4,costs[4]);
COST_MV_HPEL2(bestx-2,besty-4,costs[5]);
COPY2_IF_LT( bestcost, costs[0], dir, 0 );
COPY2_IF_LT( bestcost, costs[1], dir, 1 );
COPY2_IF_LT( bestcost, costs[2], dir, 2 );
COPY2_IF_LT( bestcost, costs[3], dir, 3 );
COPY2_IF_LT( bestcost, costs[4], dir, 4 );
COPY2_IF_LT( bestcost, costs[5], dir, 5 );
if( dir != -2 )
{
static const int hex2[8][2] = {{-2,-4}, {-4,0}, {-2,4}, {2,4}, {4,0}, {2,-4}, {-2,-4}, {-4,0}};
bestx += hex2[dir+1][0];
besty += hex2[dir+1][1];
for( n = 1; n < i_me_range && CHECK_MVRANGE4(bestx, besty); n++ )
{
static const int mod6[8] = {5,0,1,2,3,4,5,0};
const int odir = mod6[dir+1];
COST_MV_HPEL2(hex2[odir+0][0]+bestx,hex2[odir+0][1]+besty,costs[0]);
COST_MV_HPEL2(hex2[odir+1][0]+bestx,hex2[odir+1][1]+besty,costs[1]);
COST_MV_HPEL2(hex2[odir+2][0]+bestx,hex2[odir+2][1]+besty,costs[2]);
dir = -2;
COPY2_IF_LT( bestcost, costs[0], dir, odir-1 );
COPY2_IF_LT( bestcost, costs[1], dir, odir );
COPY2_IF_LT( bestcost, costs[2], dir, odir+1 );
if( dir == -2 )
break;
bestx += hex2[dir+1][0];
besty += hex2[dir+1][1];
}
}
COST_MV_HPEL3(bestx+2,besty-2);
COST_MV_HPEL3(bestx+2,besty);
COST_MV_HPEL3(bestx+2,besty+2);
COST_MV_HPEL3(bestx,besty-2);
COST_MV_HPEL3(bestx,besty+2);
COST_MV_HPEL3(bestx-2,besty-2);
COST_MV_HPEL3(bestx-2,besty);
COST_MV_HPEL3(bestx-2,besty+2);
COPY3_IF_LT(bpred_cost,bestcost,bpred_mx,bestx,bpred_my,besty);
}
}
}
}
bmx = ( bpred_mx + 2 ) >> 2;
bmy = ( bpred_my + 2 ) >> 2;
COST_MV( bmx, bmy );
}
else
{
/* check the MVP */
COST_MV( pmx, pmy );
/* I don't know why this helps */
bcost -= BITS_MVD(bmx,bmy);

for( i = 0; i < i_mvc; i++ )
{
const int mx = x264_clip3( ( mvc[i][0] + 2 ) >> 2, mv_x_min, mv_x_max );
const int my = x264_clip3( ( mvc[i][1] + 2 ) >> 2, mv_y_min, mv_y_max );
if( mx != bmx || my != bmy )
COST_MV( mx, my );
}
}

COST_MV( 0, 0 );

[DeathTheSheep]

This is with subme7 patch and satd, obviously, which is good. Any other patches in here that would cause conflicts? And I assume this is r680?

If this is all clear, this is ready and rearin' to go!! :)

[Dark Shikari]

This is with subme7 patch and satd, obviously, which is good. Any other patches in here that would cause conflicts? And I assume this is r680?

If this is all clear, this is ready and rearin' to go!! :)
r676, but I don't think anything since then has changed this part of the file.

[DeathTheSheep]

Nice.

PS: Only 3 more posts to go, Dark Shikari... :)

[morph166955]

easiest way to create a diff:

1) make distclean (if needed)
2) svn diff > mydiff.diff

DONE! Thats how I build my patches. To apply I use "patch -Np0 -i mydiff.diff"

[Inventive Software]

F***. I have no internet for a few days, and this happens! So many patches, so little time to investigate all their merits and caveats and speed boosts and quality improvements and I'm exhausted typing this sentence already!

Back to simplicity for now! F***! :D

Good work morph166955 on compiling the list so it's at least more readable. Good work Dark Shikari on firstly explaining the patches well, and on getting 1000 posts. :)

Suggestion to the mods: STICKY!!! ;)

And I hit 1000 posts a while ago and I didn't notice! :D

[akupenguin]

1) make distclean (if needed)
Superfluous. None of the generated files is in the repository, so svn diff knows to ignore them.

[morph166955]

fair enough...wasnt sure and i figured it couldnt really hurt matters to do a distclean before generating the diff.

[dirio49]

No idea if it is the right thread.
but can anybody tell what do i need to cross compile x264 for win
i have gcc-minge32 4.2.1 installed (on gentoo)
thanks
what command(2) to i need to run

later

P.S. if it is in the wrong thread please move it.

[TheRyuu]

How would one go about updating the Subme 7 patch to be compatible with rev. 680?

or, would someone please do it? :)
I want to try it out but it's not patching correctly with rev 680.

Thanks.

[foxyshadis]

No idea if it is the right thread.
but can anybody tell what do i need to cross compile x264 for win
i have gcc-minge32 4.2.1 installed (on gentoo)
thanks
what command(2) to i need to run

later

P.S. if it is in the wrong thread please move it.

Check this thread: https://forum.doom9.org/showthread.php?t=92726

[TheRyuu]

Ok, did some fiddling around and built it with the subme7 patch, faster dai patch, thread pool patch, and aq patch.

Those 4 patches I think are probably the 4 most use full patches that there are right now.

http://www.sendspace.com/file/oo3j2l

Thats the build. It's generic (cpu needs mmx support though, which should basically be all of us).
Has build options of enable avis input, pthread, and mp4 output.

I have no idea if it works, all the patches were applied successfully except for the subme7 patch, which I had to manually copy and paste over (and delete lines), but it built, so I assume I did it correctly.

If you want me to try and build any other combination of patches, ask me and I might have free time to do it.

[Raere]

Ok, did some fiddling around and built it with the subme7 patch, faster dai patch, thread pool patch, and aq patch.

Those 4 patches I think are probably the 4 most use full patches that there are right now.

http://www.sendspace.com/file/oo3j2l

Thats the build. It's generic (cpu needs mmx support though, which should basically be all of us).
Has build options of enable avis input, pthread, and mp4 output.

I have no idea if it works, all the patches were applied successfully except for the subme7 patch, which I had to manually copy and paste over (and delete lines), but it built, so I assume I did it correctly.

If you want me to try and build any other combination of patches, ask me and I might have free time to do it.

Are you using r680?

Maybe you could make another build with imh and me-prepass? I use those, so they're useful for me. If they're not hard to implement, why not? Also, I don't know what they're calling hadamard these days, but can that be implemented too? As far as I know that's still somewhat useful. And maybe an SSE2 build, as I think most everyone who's encoding x264 at least has SSE2. I dunno, just a thought if you have time. Thanks!

[Terranigma]

Are you using r680?
Also, I don't know what they're calling hadamard these days, but can that be implemented too?
--hadamard has been renamed to --fpel-cmp followed by satd (Sum of Absolute Hadamard Transformed Differences)
(Default, it uses Sum of Absolute Differences/SAD).
so, an e.g. would be
--fpel-cmp satd
satd is hadamard, and iirc, it made it in the svn.

[Sharktooth]

--fpel-cmp is not in the svn.

[Terranigma]

--fpel-cmp is not in the svn.
You're right, I just tested using rev. 680 from x264.nl:
http://i24.tinypic.com/f4henl.png

:p

[TheRyuu]

Are you using r680?

Maybe you could make another build with imh and me-prepass? I use those, so they're useful for me. If they're not hard to implement, why not? Also, I don't know what they're calling hadamard these days, but can that be implemented too? As far as I know that's still somewhat useful. And maybe an SSE2 build, as I think most everyone who's encoding x264 at least has SSE2. I dunno, just a thought if you have time. Thanks!

x264's main stuff is written in asm so using a build that used sse2 in it would pretty much be useless in terms of speed increase (considering only 1 part of x264 uses code that the compiler generates that way).

http://www.sendspace.com/file/ei6xlw

That is x264 with the following patches:
-thread pool
-AQ
-IMH
-Faster dai
-Subme7
-me-prepass
-fpel (hadamard, or however you spell it)

Causes x264.exe to weigh in it a hefty 1.03mb :p
I have absolutely no idea if it'll work. It built fine without errors, so it should work. Have fun trying it out :)
All the patches together might in some way screw something up. I have no idea, but all the patches applied, applied without errors, those that did give errors were patched manually by hand.

[foxyshadis]

Seems to work okay for me. SATD halving the speed while raising quality the tiniest bit. :p The other patches seem to be working okay too.

[Raere]

x264's main stuff is written in asm so using a build that used sse2 in it would pretty much be useless in terms of speed increase (considering only 1 part of x264 uses code that the compiler generates that way).

http://www.sendspace.com/file/ei6xlw

That is x264 with the following patches:
-thread pool
-AQ
-IMH
-Faster dai
-Subme7
-me-prepass
-fpel (hadamard, or however you spell it)

Causes x264.exe to weigh in it a hefty 1.03mb :p
I have absolutely no idea if it'll work. It built fine without errors, so it should work. Have fun trying it out :)
All the patches together might in some way screw something up. I have no idea, but all the patches applied, applied without errors, those that did give errors were patched manually by hand.

Awesome, thanks! Works for me. I really have no idea about processor optimizations, so thanks for the info.

[TheRyuu]

SATD halving the speed while raising quality the tiniest bit. :p

Thats normal right? :)

[TheRyuu]

Another question:
What patches are worth while to actually use (like don't effect speed at all, or only effect speed a little, and obviously increase the quality).

So far I think that these are worthwhile:
-faster dia
-subme7 patch
-AQ
-thread pool (not really effecting quality but still a needed patch)

I'm curious about the following patches:
-fpel patch (heard this was really slow)
-me-prepass
-IMH (vs. exhaustive vs UMH)

btw, what do the bchanges and bssd patch do?

Thanks

[Dark Shikari]

-faster dia
Not worthwhile. Proven to give dubious benefits in only some cases.

-fpel patch (heard this was really slow)
The --fpel patch with ESA is not much slower than regular ESA and somewhat better, so its "worthwhile" as an insane option.
-me-prepassUseful as a higher-end option in place of using absurd numbers of refs. Can give a roughly 1-3% quality boost with the most recent version.
-IMH (vs. exhaustive vs UMH)Pretty much useless with ESA now threaded.

[Gabriel_Bouvigne]

btw, what do the bchanges and bssd patch do?


http://mailman.videolan.org/pipermail/x264-devel/2007-August/003559.html

bssd:
when using --direct auto in multipass mode, in case of tie between direct auto and direct temporal, use SSD as an extra criterion to choose direct mode

[Sagekilla]

Not worthwhile. Proven to give dubious benefits in only some cases.


The --fpel patch with ESA is not much slower than regular ESA and somewhat better, so its "worthwhile" as an insane option.
Useful as a higher-end option in place of using absurd numbers of refs. Can give a roughly 1-3% quality boost with the most recent version.
Pretty much useless with ESA now threaded.

But IMH would be better then ESA if you want a sort of middle ground with not too huge of a speed loss, correct?

[Sharktooth]

no... IMH is practically useless. the difference in speed is so small it isnt worthwhile.

[Terranigma]

no... IMH is practically useless. the difference in speed is so small it isnt worthwhile.

I agree with these guys here. Sharktooth and Shikari made me realize that it's virtually useless when you now have esa multithreaded. :D

[Sagekilla]

Wow good point.. I just tried out the threaded esa and I must say it's insanely fast!

[Raere]

Will esa's multithreading be useful on single-cores, or is it only good for multi-cores?

[Sharktooth]

Multicores as usual.

[Raere]

So, imh is still useful on single-cores then?

[Terranigma]

So, imh is still useful on single-cores then?

Sorta, but who has a single-core processor nowadays?

[lexor]

Sorta, but who has a single-core processor nowadays?

Aw, my pride...

Lots of people still use single core, I'd hazard a guess, majority is still on single core. (majority in the world, not just on these boards)

[Sharktooth]

single core ppl should not bother using ESA or IMH...
They should stick to saner settings unless they dont care about encoding speed at all...

[Unearthly]

So, imh is still useful on single-cores then?

Not really. The reason IMH was useful before was because it offered higher quality than UMH, but was multi-threaded. At the time, ESA was only single threaded, so the speed difference on a mutli-core systems was very large.

In other words, IMH was never really useful on single core machines. Just use ESA if you want more than UMH.

[SpAwN_gUy]

i'm sorry...
is there somebody who will update first-post, so all changes to the patches would be more "in one place" and i'd be happy to use them with 681 (as seen on x264.nl)

reason for this: i've noticed some chat about changing option names in Dark Shikari's patches..

[fields_g]

Another idea to add to the OP is limitations of the patch and/or an explanation of why it hasn't been added to SVN. Really help point out the maturity and support of each patch. This might need the help of akupenguin.

[Dark Shikari]

Another idea to add to the OP is limitations of the patch and/or an explanation of why it hasn't been added to SVN. Really help point out the maturity and support of each patch. This might need the help of akupenguin.Subme7 is ready to add to SVN, hopefully it'll be done soon.

ME-Prepass is next.

[Inventive Software]

From the x264 changelog:
use hex instead of dia for rdo mv refinement. ~0.5% lower bitrate at subme=7.
patch by Dark Shikari.

That the patch you're on about?

[Dark Shikari]

From the x264 changelog:
That the patch you're on about?Yup, that's it.

[morph166955]

i'm sorry...
is there somebody who will update first-post, so all changes to the patches would be more "in one place" and i'd be happy to use them with 681 (as seen on x264.nl)

reason for this: i've noticed some chat about changing option names in Dark Shikari's patches..

If someone gives me a list of them I'll be happy to update my post.

[bob0r]

x264.736.modified.01.exe (http://files.x264.nl/x264.736.modified.01.exe)

General thread:
http://forum.doom9.org/showthread.php?t=130364

x264_aq_var.48.diff
http://forum.doom9.org/showthread.php?t=132760
x264.gaussian.cplxblur.01.diff
Dark Shikari: - gaussian cplxblur: gives a tiny improvement in 2pass ratecontrol
x264_me-prepass_DeathTheSheep.01.diff
http://forum.doom9.org/showthread.php?p=1093523
x264_2pass_vbv.4.MatMaul.diff
http://mailman.videolan.org/pipermail/x264-devel/2008-January/004015.html
x264_hrd_pulldown.04.diff
- HRD and pulldown for HD compatibility

Edit:
Link to x264 patches collected: http://files.x264.nl/x264_patches/

[bob0r]

x264.736.modified.02.exe (http://files.x264.nl/x264.736.modified.02.exe)

General thread:
http://forum.doom9.org/showthread.php?t=130364

x264_aq_var.48.diff
http://forum.doom9.org/showthread.php?t=132760
x264.gaussian.cplxblur.01.diff
Dark Shikari: - gaussian cplxblur: gives a tiny improvement in 2pass ratecontrol
x264_me-prepass_DeathTheSheep.01.diff
http://forum.doom9.org/showthread.php?p=1093523
x264_2pass_vbv.4.MatMaul.diff
http://thread.gmane.org/gmane.comp.video.x264.devel/3093/focus=3521
x264_hrd_pulldown.04_interlace.diff
- HRD and pulldown for HD compatibility, updated patch for interlacing
http://forum.doom9.org/showthread.php?p=1047919#post1047919

Edit:
Link to x264 patches collected: http://files.x264.nl/x264_patches/

[survivant001]

thanks for thr build. always welcome

[leoenc]

x264_hrd_pulldown.04_interlace.diff
- HRD and pulldown for HD compatibility, updated patch for interlacing
http://forum.doom9.org/showthread.php?p=1047919#post1047919


bob0r, are you sure you applied the interlaced patch to 747? adding the --tff switch results in "uknown option --tff"

[bob0r]

bob0r, are you sure you applied the interlaced patch to 747? adding the --tff switch results in "uknown option --tff"

Any new version then?
Cus that patch was only to fix the patch with interlacing....

[ggab]

i hope version 748 will be less problematic, we have several bugs in version 745/746/747

maybe videolan team's official svn will help us with these (great of course) patche' releases we are having :)

[csy]

bob0r, are you sure you applied the interlaced patch to 747? adding the --tff switch results in "uknown option --tff"

I've also noticed the --tff switch is missing. Something must have gone wrong with the patch and this build.

[bob0r]

I added x264_hrd_pulldown.04.diff instead of x264_hrd_pulldown.04_interlace.diff
(because it has to be run outside the x264 dir.... my bad :p

Next x264 update ill put up a new build, since there is only a speed difference (not that much) use the previous if you really need interlacing <-- EVIL!

[burfadel]

Whats with version 748 I saw on techouse's site? I can't seem to access www.x264.tk or techouse.project357.com for the last day or so. Is there any major difference?

Looking on the track log there doesn't seem to be a difference, so I presume thats still 747?

For x264.nl, why not just check for a change in the timestamp thats listed on the log page? A change in the timestamp would mean a new version and thus can be compiled. As this won't have a revision number at the moment, you could list it on the website as a latest revision & date until the revision number for that build is known! You could even have a patched and non patched version done automatically?

Just an idea, I know its not perfect, but I presume it would be reasonably easy to implement for the time being until something else can be worked out. Or will the problem be rectified in the next week or so?...

[bob0r]

Thanks to akupenguin (pengvado) x264.nl is auto updating again!!

So here is 748 (based on GIT updates count) + fixed HRD interlacing patch

x264.748.modified.exe (http://files.x264.nl/x264.748.modified.exe)

General thread:
http://forum.doom9.org/showthread.php?t=130364

x264_aq_var.48.diff
http://forum.doom9.org/showthread.php?t=132760
x264.gaussian.cplxblur.01.diff
Dark Shikari: - gaussian cplxblur: gives a tiny improvement in 2pass ratecontrol
x264_me-prepass_DeathTheSheep.01.diff
http://forum.doom9.org/showthread.php?p=1093523
x264_2pass_vbv.6.diff
http://thread.gmane.org/gmane.comp.video.x264.devel/3093/focus=3550
x264_hrd_pulldown.04_interlace.diff
- HRD and pulldown for HD compatibility, updated patch for interlacing
http://forum.doom9.org/showthread.php?p=1047919#post1047919

Link to x264 patches collected: http://files.x264.nl/x264_patches/

[leoenc]

--tff is working fine now, thanks bob0r!

[burfadel]

Any chance of an AQ version of 757 (or later)?!

[bob0r]

x264.757.modified.exe (http://files.x264.nl/x264.757.modified.exe)

General thread:
http://forum.doom9.org/showthread.php?t=130364

x264_aq_var.48.diff
http://forum.doom9.org/showthread.php?t=132760
x264.gaussian.cplxblur.01.diff
Dark Shikari: - gaussian cplxblur: gives a tiny improvement in 2pass ratecontrol
x264_me-prepass_DeathTheSheep.01.diff
http://forum.doom9.org/showthread.php?p=1093523
x264_2pass_vbv.6.diff
http://thread.gmane.org/gmane.comp.video.x264.devel/3093/focus=3550
x264_hrd_pulldown.04_interlace.diff
- HRD and pulldown for HD compatibility, updated patch for interlacing
http://forum.doom9.org/showthread.php?p=1047919#post1047919

Link to x264 patches collected: http://files.x264.nl/x264_patches/

[burfadel]

Thanks :)

[bob0r]

x264.763.modified.exe (http://files.x264.nl/x264.763.modified.exe)

General thread:
http://forum.doom9.org/showthread.php?t=130364

x264_aq_var.48.diff
http://forum.doom9.org/showthread.php?t=132760
x264.gaussian.cplxblur.01.diff
Dark Shikari: - gaussian cplxblur: gives a tiny improvement in 2pass ratecontrol
x264_me-prepass_DeathTheSheep.01.diff
http://forum.doom9.org/showthread.php?p=1093523
x264_2pass_vbv.6.diff
http://thread.gmane.org/gmane.comp.video.x264.devel/3093/focus=3550
x264_hrd_pulldown.04_interlace.diff
- HRD and pulldown for HD compatibility, updated patch for interlacing
http://forum.doom9.org/showthread.php?p=1047919#post1047919

Link to x264 patches collected: http://files.x264.nl/x264_patches/

[Sharktooth]

thanks. r763.modified is on megui autoupdate server.

[burfadel]

764 AQ patched version? thanks :) I take it 764 may provide a fractional speed increase over 763?

[Dark Shikari]

764 AQ patched version? thanks :) I take it 764 may provide a fractional speed increase over 763?Probably a small speed boost (mostly on Intel CPUs). Might as well wait for when pengvado commits my SSSE3 4x4/4x8 SATD patch, along with my "skip intra encode" patch, both of which give speedups that don't affect the output. The latter is the biggest boost: in particular, it gives the following speed boosts:

1. Small speed increase with no RD and no trellis.
2. Slightly bigger speed increase with RD and trellis 0 or 1.
3. Large speed increase with RD and trellis 2.

[bob0r]

764 AQ patched version? thanks :) I take it 764 may provide a fractional speed increase over 763?

Tomorrow, tired now :)

[Dark Shikari]

Tomorrow, tired now :)And we're already up to 767... :p

[burfadel]

And we're already up to 767... :p

Its great to see these improvements, can't wait to try out 767+ with AQ! - got a whole lot of stuff to encode, lol

[bob0r]

x264.774.modified.exe (http://files.x264.nl/x264.774.modified.exe)

General thread:
http://forum.doom9.org/showthread.php?t=130364

x264_aq_var.48.diff
http://forum.doom9.org/showthread.php?t=132760
x264.gaussian.cplxblur.01.diff
Dark Shikari: - gaussian cplxblur: gives a tiny improvement in 2pass ratecontrol
x264_me-prepass_DeathTheSheep.01.diff
http://forum.doom9.org/showthread.php?p=1093523
x264_2pass_vbv.6.diff
http://thread.gmane.org/gmane.comp.video.x264.devel/3093/focus=3550
x264_hrd_pulldown.04_interlace.diff
- HRD and pulldown for HD compatibility, updated patch for interlacing
http://forum.doom9.org/showthread.php?p=1047919#post1047919

Link to x264 patches collected: http://files.x264.nl/x264_patches/

[TheRyuu]

Can you build one with the exact same patches as above only switch out the VAQ patch for the old haali aq patch? (for anime encoding)

[burfadel]

There 775 out now :) an Aq version of 775 would be nice, thankyou! I hope it sounds like I'm asking politely and not demanding! lol

[MuLTiTaSK]

wow it seems like everytime i check theres a new version and a patched mod follows blazing fast thanks alot bob0r i appreciate your dedication

the devz of this awesome encoder are making it better and much quicker with every update. making backups of my dvd's to H.264 look alot better then they did with XviD :thanks:

[bob0r]

Tomorrow i hope --me tesa and possible other options (only pengvado knows) will be added to the make fprofiled part of the code.

When i wake up ill check for another build.

No i will not create a build with Haali's AQ, if you truely got some issues disguss it with Dark Shikari. If he says it can't be or won't be done, too bad.

Else start making a way i can compile BOTH patches into one single .exe, but that's up to you.

[Dark Shikari]

No i will not create a build with Haali's AQ, if you truely got some issues disguss it with Dark Shikari. If he says it can't be or won't be done, too bad.Don't stick the burden on me, I don't care either way about it :p

[burfadel]

wow, 776 just shows up on x264.nl and already 777 is on git! thats some fast work, great to see!

[buzzqw]

thanks bob0r!

BHH

[MythCreator]

This is my first Modified edition:thanks::thanks::thanks:

Based on Rev.779, without mp4-output

x264_aq_var.48.diff
http://forum.doom9.org/showthread.php?t=132760
x264.gaussian.cplxblur.01.diff
Dark Shikari: - gaussian cplxblur: gives a tiny improvement in 2pass ratecontrol
x264_me-prepass_DeathTheSheep.01.diff
http://forum.doom9.org/showthread.php?p=1093523
x264_2pass_vbv.6.diff
http://thread.gmane.org/gmane.comp.v...093/focus=3550


Link to x264 patches collected: http://files.x264.nl/x264_patches/

[bob0r]

Try this AQ patch, its basically the same only GIT-optimized:
http://forum.doom9.org/showthread.php?p=1115494#post1115494

I am waiting for pengvado to finish the new fprofiled settings + AQ is part of GIT.

Then a new hddvd/bluray patched .exe will be created, but probably not so often as now..... the main reason now is: AQ

@MythCreator
Good job, you want it tested, compile more often or just for fun?

[MythCreator]

MythCreator
Good job, you want it tested, compile more often or just for fun?



I'll compile at least one per day if there is a new GIT version:)


BTW,where can I get the VAQ 2.0?

[Dark Shikari]

BTW,where can I get the VAQ 2.0?Its not released yet, still in early development ;)

1.0 will go into official GIT soon.

[MythCreator]

1.0 will go into official GIT soon.


It's so nice~

[bob0r]

I'll compile at least one per day if there is a new GIT version:)


BTW,where can I get the VAQ 2.0?


Oh my bad, i thought there was a link, just wait for it to be added to GIT, sorry :D

Btw do try to enable mp4 output, and have you used ptheads?
Guess we shall see when your builds are approved, but i dont think a mod is going to approve a new build each day :p

*zzzz :D

[MythCreator]

Oh my bad, i thought there was a link, just wait for it to be added to GIT, sorry :D

Btw do try to enable mp4 output, and have you used ptheads?
Guess we shall see when your builds are approved, but i dont think a mod is going to approve a new build each day :p

*zzzz :D


I used pthreads.But I got some problem
with gpac and I don't know how to solve it..

[bob0r]

I used pthreads.But I got some problem
with gpac and I don't know how to solve it..

To compile the needed gpac files i do:
- cvs -z3 -d:pserver:anonymous@gpac.cvs.sourceforge.net:/cvsroot/gpac co -P gpac
- cd gpac
- configure
- make clean
- make lib
- copy: gpac/include/gpac (COMPLETE dir) to /local/include/
- copy: gpac/bin/gcc/libgpac_static.a to /local/lib/

Note: My gcc system is installed to local, your include and lib may have other paths, likely just /include/ and /lib/.

Hope this helps...

[bob0r]

x264.785.modified.exe (http://files.x264.nl/x264.785.modified.exe)

General thread:
http://forum.doom9.org/showthread.php?t=130364

x264_aq_var.48.diff
http://forum.doom9.org/showthread.php?t=132760
x264.gaussian.cplxblur.01.diff
Dark Shikari: - gaussian cplxblur: gives a tiny improvement in 2pass ratecontrol
x264_me-prepass_DeathTheSheep.01.diff
http://forum.doom9.org/showthread.php?p=1093523
x264_2pass_vbv.6.diff
http://thread.gmane.org/gmane.comp.video.x264.devel/3093/focus=3550
x264_hrd_pulldown.04_interlace.diff
- HRD and pulldown for HD compatibility, updated patch for interlacing
http://forum.doom9.org/showthread.php?p=1047919#post1047919

Link to x264 patches collected: http://files.x264.nl/x264_patches/

[Inventive Software]

I very much appreciate people keeping the version number going, but does GIT not have one? Cos it would make things so much easier to read in the trunk! :D

[MythCreator]

To compile the needed gpac files i do:
- cvs -z3 -d:pserver:anonymous@gpac.cvs.sourceforge.net:/cvsroot/gpac co -P gpac
- cd gpac
- configure
- make clean
- make lib
- copy: gpac/include/gpac (COMPLETE dir) to /local/include/
- copy: gpac/bin/gcc/libgpac_static.a to /local/lib/

Note: My gcc system is installed to local, your include and lib may have other paths, likely just /include/ and /lib/.

Hope this helps...

Got it..Thanks a lot~

[MythCreator]

Based on Rev.786, without AQ..enable mp4 output

Download Address:
http://www.megaupload.com/?d=U19O3CM4

x264.gaussian.cplxblur.01.diff
Dark Shikari: - gaussian cplxblur: gives a tiny improvement in 2pass ratecontrol
x264_me-prepass_DeathTheSheep.01.diff
http://forum.doom9.org/showthread.php?p=1093523
x264_2pass_vbv.6.diff
http://thread.gmane.org/gmane.comp.v...093/focus=3550
x264_bssd.diff

Link to x264 patches collected: http://files.x264.nl/x264_patches/

[MeteorRain]

Based on Rev.786, without AQ..enable mp4 output

x264.gaussian.cplxblur.01.diff
Dark Shikari: - gaussian cplxblur: gives a tiny improvement in 2pass ratecontrol
x264_me-prepass_DeathTheSheep.01.diff
http://forum.doom9.org/showthread.php?p=1093523
x264_2pass_vbv.6.diff
http://thread.gmane.org/gmane.comp.v...093/focus=3550
x264_bssd.diff

Link to x264 patches collected: http://files.x264.nl/x264_patches/
Cool but i think you should post the file onto other free netdisk such as fs2you or so

[MuLTiTaSK]

bob0r would it be possible to add a rss feed to x264.nl for new builds?

[bob0r]

I have no clue how to, nor do i want to know how, but just check x264.nl before you start an encode?

Or have a script pick up latest version always :)

http://mirror01.x264.nl/x264/x264.exe always points to the latest version (on all mirrors)

[Zep]

both 785 and 786 crash hard and quick for me but

core:58 r763M 0949975 works great still from MeGui update a few days back (the march 19th release I think)

[bob0r]

How did it crash?
What commandline?
What source?
Can you put a reproducable package online?

We need details!!!

[MythCreator]

x264-rev.789 non patch edition
download link:
http://www.fs2you.com/files/80b45d40-f97d-11dc-b91b-0014221f4662/

there is no diffrence from GIT,but make fprofiled with GCC 4.2.1

[SpAwN_gUy]

any chance building latest GITs with MSVS? (Cef has some troubles.. and i've got fresh setUP .. so i can't test)

[bob0r]

x264.790.modified.exe (http://files.x264.nl/x264.790.modified.exe)

General thread:
http://forum.doom9.org/showthread.php?t=130364

x264_aq_var.48.786.fixed.diff
http://forum.doom9.org/showthread.php?t=132760
x264.gaussian.cplxblur.01.diff
Dark Shikari: - gaussian cplxblur: gives a tiny improvement in 2pass ratecontrol
x264_me-prepass_DeathTheSheep.01.diff
http://forum.doom9.org/showthread.php?p=1093523
x264_2pass_vbv.6.diff
http://thread.gmane.org/gmane.comp.video.x264.devel/3093/focus=3550
x264_hrd_pulldown.04_interlace.diff
- HRD and pulldown for HD compatibility, updated patch for interlacing
http://forum.doom9.org/showthread.php?p=1047919#post1047919

Link to x264 patches collected: http://files.x264.nl/x264_patches/

[MythCreator]

x264.791.modified

download link:
http://www.fs2you.com/files/d13ff451-fa06-11dc-ab82-0014221f4662/

x264_aq_var.48.786.fixed.diff
http://forum.doom9.org/showthread.php?t=132760
x264.gaussian.cplxblur.01.diff
Dark Shikari: - gaussian cplxblur: gives a tiny improvement in 2pass ratecontrol
x264_me-prepass_DeathTheSheep.01.diff
http://forum.doom9.org/showthread.php?p=1093523
x264_2pass_vbv.6.diff
http://thread.gmane.org/gmane.comp.v...093/focus=3550
x264_bssd.diff

Link to x264 patches collected: http://files.x264.nl/x264_patches/


make fprofiled by use GCC 4.2.1

[MythCreator]

x264.796.modified

download link:
http://www.fs2you.com/files/8f5859fa-fa68-11dc-a2ed-0014221f3995/


x264_aq_var.48.786.fixed.diff
http://forum.doom9.org/showthread.php?t=132760
x264.gaussian.cplxblur.01.diff
Dark Shikari: - gaussian cplxblur: gives a tiny improvement in 2pass ratecontrol
x264_me-prepass_DeathTheSheep.01.diff
http://forum.doom9.org/showthread.php?p=1093523
x264_2pass_vbv.6.diff
http://thread.gmane.org/gmane.comp.v...093/focus=3550
x264_hrd_pulldown.04_interlace.diff
- HRD and pulldown for HD compatibility, updated patch for interlacing
http://forum.doom9.org/showthread.ph...19#post1047919
x264_bssd.diff

Link to x264 patches collected: http://files.x264.nl/x264_patches/

[Zep]

How did it crash?
What commandline?
What source?
Can you put a reproducable package online?

We need details!!!

I would have but my encode took days (went back to older version) and by the time it was done so I could get some details, the new version was out and that one seems stable. :D

I'll just keep my mouth shut unless I can paste the crash log etc... lol

thanks

[bob0r]

....

I'll just keep my mouth shut unless I can paste the crash log etc... lol

thanks


Please don't, just next time report commandline + revision (version number) plus as many info as you can.

I am glad the new .exe files have been stable for you.

If you read the x264.nl notes, you can also read what versions may have been unstable (just scroll down)...

Thanks for your input!

[bob0r]

@Sharktooth and MythCreator

Please read:
http://forum.doom9.org/showthread.php?t=134391

I am not saying that your builds are crashing, but so far gcc 3.4.6 still seems the best gcc to build x264.exe.

Just a reminder if people start to report x264 related crashes which cannot be reproduced with my .exe files.

[bob0r]

x264.798.modified.exe (http://files.x264.nl/x264.798.modified.exe)

General thread:
http://forum.doom9.org/showthread.php?t=130364

x264_aq_var.48.786.fixed.diff
http://forum.doom9.org/showthread.php?t=132760
x264.gaussian.cplxblur.01.diff
Dark Shikari: - gaussian cplxblur: gives a tiny improvement in 2pass ratecontrol
x264_me-prepass_DeathTheSheep.01.diff
http://forum.doom9.org/showthread.php?p=1093523
x264_2pass_vbv.6.diff
http://thread.gmane.org/gmane.comp.video.x264.devel/3093/focus=3550
x264_hrd_pulldown.04_interlace.diff
- HRD and pulldown for HD compatibility, updated patch for interlacing
http://forum.doom9.org/showthread.php?p=1047919#post1047919

Link to x264 patches collected: http://files.x264.nl/x264_patches/

[Sharktooth]

ok, ill update ASAP.

[MythCreator]

x264.798.modified.beta.exe

Download Link:
http://www.fs2you.com/files/cde2a07d-fb0b-11dc-9640-00142218fc6e/

x264_aq_var.48.786.fixed.diff
http://forum.doom9.org/showthread.php?t=132760
x264.gaussian.cplxblur.01.diff
Dark Shikari: - gaussian cplxblur: gives a tiny improvement in 2pass ratecontrol
x264_me-prepass_DeathTheSheep.01.diff
http://forum.doom9.org/showthread.php?p=1093523
x264_2pass_vbv.6.diff
http://thread.gmane.org/gmane.comp.v...093/focus=3550
x264_hrd_pulldown.04_interlace.diff
- HRD and pulldown for HD compatibility, updated patch for interlacing
http://forum.doom9.org/showthread.ph...19#post1047919
x264_bssd.diff

Link to x264 patches collected: http://files.x264.nl/x264_patches/



PS:make fprofiled by GCC 4.3.0,may be someone wish to help me for doing some testing work? Thank's a lot

[burfadel]

On my C2D, your 798.modified GCC 4.3.0 versions is fractionally slower than bob0r's 798.modified version. By fractionally I mean around .05 - 0.1 fps! (consistently)

[MythCreator]

On my C2D, your 798.modified GCC 4.3.0 versions is fractionally slower than bob0r's 798.modified version. By fractionally I mean around .05 - 0.1 fps! (consistently)



no crash?

[burfadel]

No crash :) I only did just under a 1000 frames though, but different segments.

[bob0r]

@MythCreator

Did you compile gcc 4.3.0 or did you use some pre packages version?

[MythCreator]

@MythCreator

Did you compile gcc 4.3.0 or did you use some pre packages version?



pre package.I can't connect to SVN and I don't know why.

[burfadel]

Isn't SVN no longer used?

[LoRd_MuldeR]

Isn't SVN no longer used?

Nope. VideoLAN, which is also hosting x264, switched to git recently...

[burfadel]

Thats what I thought, and would explain the problem he's having!

[Wishbringer]

Thats what I thought, and would explain the problem he's having!

Thought he is talking about compiler svn repo...

@MythCreator

Did you compile gcc 4.3.0 or did you use some pre packages version?
...
pre package.I can't connect to SVN and I don't know why.

:rolleyes:

[akupenguin]

On my C2D, your 798.modified GCC 4.3.0 versions is fractionally slower than bob0r's 798.modified version. By fractionally I mean around .05 - 0.1 fps! (consistently)
I can think of 3 possible reasons:
* Bssd is slower than unpatched (applies only with direct=auto).
* Different video content for fprofile. Yes, I have said that the content doesn't matter much, but that doesn't mean I'd discount the possibility of .05 fps. (Well, maybe I would. .05 out of what, .2? Speed differences are meaningless. Please don't ever post one again. The meaningful measure is speed ratio, preferably accompanied by the standard deviation of N trials. The base fps that the ratio is relative to (or the amount of the difference, interderivable) is optional and is the least important datum.)
* Different compiler. No, I do not have faith in newer gcc being consistently faster than old versions. (Consider that in a program as small as x264, even a single pessimized instruction in the wrong place could have a significant effect on total speed.)

[Sharktooth]

gcc 4.x was always slower than 3.4.x in my tests...

[bob0r]

@MythCreator

Doom9 forum shortens URLs, so copying plain text isn't going to work.

Here to make it easy for you:
http://x264.nl/x264.modified.txt

Also note the updated x264_2pass_vbv.7.diff patch.
grab it from the collected patches dir, apply like this:
patch -p1 < x264_patches/x264_2pass_vbv.7.diff

[MythCreator]

@MythCreator

Doom9 forum shortens URLs, so copying plain text isn't going to work.

Here to make it easy for you:
http://x264.nl/x264.modified.txt

Also note the updated x264_2pass_vbv.7.diff patch.
grab it from the collected patches dir, apply like this:
patch -p1 < x264_patches/x264_2pass_vbv.7.diff




Thanks~~~~

[MythCreator]

x264.798.modified.beta2.exe (http://www.fs2you.com/files/5e08fb02-fbe9-11dc-bde1-0014221b798a/)

General thread:
http://forum.doom9.org/showthread.php?t=130364

x264_aq_var.48.786.fixed.diff
http://forum.doom9.org/showthread.php?t=132760
x264.gaussian.cplxblur.01.diff
Dark Shikari: - gaussian cplxblur: gives a tiny improvement in 2pass ratecontrol
x264_me-prepass_DeathTheSheep.01.diff
http://forum.doom9.org/showthread.php?p=1093523
x264_2pass_vbv.7.diff
http://thread.gmane.org/gmane.comp.video.x264.devel/3093/focus=3748
x264_hrd_pulldown.04_interlace.diff
- HRD and pulldown for HD compatibility, updated patch for interlacing
http://forum.doom9.org/showthread.php?p=1047919#post1047919

Link to x264 patches collected: http://files.x264.nl/x264_patches/



make fprofiled by GCC 4.3.0 , just for test

[Inventive Software]

@clsid: If you still read this thread, can you provide an install of MinGW with GCC 3.4.6 please?

@everybody: What's the difference between fprofiled and "normal" builds?

[survivant001]

@MythCreator. I obtain unknown option -- nal-hrd with your latest build

[Inventive Software]

x264_hrd_pulldown.04_interlace.diff
- HRD and pulldown for HD compatibility, updated patch for interlacing
http://forum.doom9.org/showthread.ph...19#post1047919

That patch adds the option. If you don't know what it is, don't use it. ;)

[survivant001]

That patch adds the option. If you don't know what it is, don't use it. ;)

I know that, and Yes I need it, but it's not include in the 798beta2

[MythCreator]

I know that, and Yes I need it, but it's not include in the 798beta2




It's just my fault...I forget to add it

[MythCreator]

x264.798.modified.beta2.fixed.exe (http://www.fs2you.com/files/930a6038-fc12-11dc-a915-0014221b798a/)

General thread:
http://forum.doom9.org/showthread.php?t=130364

x264_aq_var.48.786.fixed.diff
http://forum.doom9.org/showthread.php?t=132760
x264.gaussian.cplxblur.01.diff
Dark Shikari: - gaussian cplxblur: gives a tiny improvement in 2pass ratecontrol
x264_me-prepass_DeathTheSheep.01.diff
http://forum.doom9.org/showthread.php?p=1093523
x264_2pass_vbv.7.diff
http://thread.gmane.org/gmane.comp.video.x264.devel/3093/focus=3748
x264_hrd_pulldown.04_interlace.diff
- HRD and pulldown for HD compatibility, updated patch for interlacing
http://forum.doom9.org/showthread.php?p=1047919#post1047919

Link to x264 patches collected: http://files.x264.nl/x264_patches/



make fprofiled by GCC 4.3.0 , just for test

[MythCreator]

x264.798.modified.final.exe (http://www.fs2you.com/files/06ebf71c-fcb5-11dc-8543-0014221f3995/)

General thread:
http://forum.doom9.org/showthread.php?t=130364

x264_aq_var.48.786.fixed.diff
http://forum.doom9.org/showthread.php?t=132760
x264.gaussian.cplxblur.01.diff
Dark Shikari: - gaussian cplxblur: gives a tiny improvement in 2pass ratecontrol
x264_me-prepass_DeathTheSheep.01.diff
http://forum.doom9.org/showthread.php?p=1093523
x264_2pass_vbv.7.diff
http://thread.gmane.org/gmane.comp.video.x264.devel/3093/focus=3748
x264_hrd_pulldown.04_interlace.diff
- HRD and pulldown for HD compatibility, updated patch for interlacing
http://forum.doom9.org/showthread.php?p=1047919#post1047919
x264_bssd.diff

Link to x264 patches collected: http://files.x264.nl/x264_patches/

make fprofiled by GCC 4.3.0






BTW:Is thread pool still usefull?

[survivant001]

for me it is. I don't where else to get the latest build patched.

[buzzqw]

i agree with survivant

BHH

[MythCreator]

for me it is. I don't where else to get the latest build patched.




I mean, is the Thread Pool.diff still useful at this time?

[burfadel]

Well, the modified.final build of Mythcreator's is a fraction fractionally (...?!) slower than that of Bobor's modified 798. On a test I just did its was 99.998 percent (rounded up!) the performance of Bobor's modified build.

I'm just curious, if Mythcreator is willing to give it a try, purely as an experimental build whether he could try making a build with GCC 4.4.0. It is very much in testing stage, but snapshots can be downloaded by mirror sites. They're updated weekly according to the gcc site. One such site is:

http://gcc-ca.internet.bs/snapshots/

(of course then select the latest 4.4 folder at the bottom of the list)

Course could always build your own latest 4.4.0 snapshot from the GCC SVN
svn://gcc.gnu.org/svn/gcc/trunk
http://gcc.gnu.org/svn/gcc/trunk
^^ view contents

I realise you probably know all this already, I listed it in case anyone was wondering :)

GCC 4.4.0 supposedly has many optimisations that may finally allow it to be faster than GCC 3.4.6. Would be interesting to see anyway!

[MythCreator]

Well, the modified.final build of Mythcreator's is a fraction fractionally (...?!) slower than that of Bobor's modified 798. On a test I just did its was 99.998 percent (rounded up!) the performance of Bobor's modified build.

I'm just curious, if Mythcreator is willing to give it a try, purely as an experimental build whether he could try making a build with GCC 4.4.0. It is very much in testing stage, but snapshots can be downloaded by mirror sites. They're updated weekly according to the gcc site. One such site is:

http://gcc-ca.internet.bs/snapshots/

(of course then select the latest 4.4 folder at the bottom of the list)

Course could always build your own latest 4.4.0 snapshot from the GCC SVN
svn://gcc.gnu.org/svn/gcc/trunk
http://gcc.gnu.org/svn/gcc/trunk
^^ view contents

I realise you probably know all this already, I listed it in case anyone was wondering :)

GCC 4.4.0 supposedly has many optimisations that may finally allow it to be faster than GCC 3.4.6. Would be interesting to see anyway!



I know it,but 4.4.0 is still in develope, maybe have some serious bug in it

[burfadel]

I was actually taking that in to consideration! Like I said above, just as a purely experimental build just to see whether gcc 4.4.0 performs as well or outperforms the older 3.4.6. It may even be the case it, in terms of comparing it to 4.3.0 or 4.2.2, more stable for the use of x264 since due to the crashes and slowdowns somethings not quite right with those two revisions!

Just thought it would be interesting to see, and compare to your 4.3.0 build. Its ok if its too much trouble, just thought it may be interesting!

[morph166955]

I mean, is the Thread Pool.diff still useful at this time?

For those of us who have very fast octa-core machines it is. For those who don't have them, results have varied between minimal speed boost to nothing at all to even a slight decrease in speed. Unfortunately I haven't been able to find a diff for thread pool that will cleanly apply in a few months. The whole reason that it does still work for the higher speed machines is that our threads are completing and destroying themeslves faster then x264 is expecting them to so there is a lag time created. Its actually taking longer to create/destroy a thread then it is for the thread to do its job in some cases. Having the thread pool there makes it so that we don't have to wait. In tests I ran a while back, when I had the thread pool patch installed I was getting a pretty significant speed boost on SD content (HD content is large enough that it maxes the CPU out anyway).

If we could get a thread pool patch that applied cleanly to the current version that would be awesome. What would be even more awesome is just putting it into the git version in a way where under normal running it would do its normal process but where we could put like --threadpool on the cli and it would run in that mode. No idea how hard that would be to do but I think that would be optimal that way one can choose the threading method they want on the fly.

[MythCreator]

x264.798.modified.experimental.exe (http://www.fs2you.com/files/d366136e-fdb8-11dc-a5be-0014221f4662/)

General thread:
http://forum.doom9.org/showthread.php?t=130364

x264_aq_var.48.786.fixed.diff
http://forum.doom9.org/showthread.php?t=132760
x264.gaussian.cplxblur.01.diff
Dark Shikari: - gaussian cplxblur: gives a tiny improvement in 2pass ratecontrol
x264_me-prepass_DeathTheSheep.01.diff
http://forum.doom9.org/showthread.php?p=1093523
x264_2pass_vbv.7.diff
http://thread.gmane.org/gmane.comp.video.x264.devel/3093/focus=3748
x264_hrd_pulldown.04_interlace.diff
- HRD and pulldown for HD compatibility, updated patch for interlacing
http://forum.doom9.org/showthread.php?p=1047919#post1047919

Link to x264 patches collected: http://files.x264.nl/x264_patches/



make frofiled in GCC 4.4.0 20080328 experimental,totally for experiment & test



To test the speed change, Please use this build and my beta2.fixed , and bob0r's build

[burfadel]

The experimental version worked fine, no crashes or anything unexpected... with good results!
On the test clip I used, with 1000 frames (not much I know but good enough for this purpose), I did several runs of each and used the average of all the runs. I used each version after the other one, not do all the runs at the same time to ensure accurate results.

With 798.modified.final (GCC 4.3.0):
Speed: 37.11 fps

With Bobor's 798 modified (GCC 3.4.6):
Speed: 37.25 fps

With 798.experimental (GCC 4.4.0):
speed: 37.37 fps

Of course on each run the speeds were slightly different, but in each run the slowest of Bobor's build run was still faster than the fastest for 798.modified and the slowest run of 798.experimental was still faster than the fastest for Bobor's build.

GCC 4.4.0 looks promising to be faster and regain the speed lost so far with GCC 4.x.x! The final may even be slightly better again (although an assumption one would presume it will be optimised further).

Thanks for the trial, it looks good! Maybe others with different CPU's could also test, the results may be different with AMD's for example?...

[Dethis]

Burfadel, thanks for the test

But, as MythCreator suggested, you should use the "beta2.fixed" instead of the ".final". The ".final" one contains the bssd patch which probably inserts some more computation load which is absend for the "bobor" and "experimental" versions.

[MasterNobody]

For those of us who have very fast octa-core machines it is. For those who don't have them, results have varied between minimal speed boost to nothing at all to even a slight decrease in speed. Unfortunately I haven't been able to find a diff for thread pool that will cleanly apply in a few months. The whole reason that it does still work for the higher speed machines is that our threads are completing and destroying themeslves faster then x264 is expecting them to so there is a lag time created. Its actually taking longer to create/destroy a thread then it is for the thread to do its job in some cases. Having the thread pool there makes it so that we don't have to wait. In tests I ran a while back, when I had the thread pool patch installed I was getting a pretty significant speed boost on SD content (HD content is large enough that it maxes the CPU out anyway).

If we could get a thread pool patch that applied cleanly to the current version that would be awesome. What would be even more awesome is just putting it into the git version in a way where under normal running it would do its normal process but where we could put like --threadpool on the cli and it would run in that mode. No idea how hard that would be to do but I think that would be optimal that way one can choose the threading method they want on the fly.

Here is my variant of thread-pool patch which was made relatively to current git version: http://stashbox.org/96770/x264_thread_pool.r798.diff
As I know Dark Shikari's AQ patch slightly conflicts with thread-pool patch (in ratecontrol.c) so one of them need some modifications for compatibility.

[morph166955]

Here is my variant of thread-pool patch which was made relatively to current git version: http://stashbox.org/96770/x264_thread_pool.r798.diff
As I know Dark Shikari's AQ patch slightly conflicts with thread-pool patch (in ratecontrol.c) so one of them need some modifications for compatibility.

Sweet! Thanks! Can't wait to give it a shot.

[MythCreator]

x264.805.modified.experimental.exe (http://www.fs2you.com/files/0aed3c00-fedf-11dc-9380-0014221f3995/)

General thread:
http://forum.doom9.org/showthread.php?t=130364

x264.gaussian.cplxblur.01.diff
Dark Shikari: - gaussian cplxblur: gives a tiny improvement in 2pass ratecontrol
x264_me-prepass_DeathTheSheep.01.diff
http://forum.doom9.org/showthread.php?p=1093523
x264_2pass_vbv.7.diff
http://thread.gmane.org/gmane.comp.video.x264.devel/3093/focus=3748
x264_hrd_pulldown.04_interlace.diff
- HRD and pulldown for HD compatibility, updated patch for interlacing
http://forum.doom9.org/showthread.php?p=1047919#post1047919

Link to x264 patches collected: http://files.x264.nl/x264_patches/



make frofiled in GCC 4.4.0 20080328 experimental,totally for experiment & test

[bob0r]

x264.805.modified.exe (http://files.x264.nl/x264.805.modified.exe)

General thread:
http://forum.doom9.org/showthread.php?t=130364

x264.gaussian.cplxblur.01.diff
Dark Shikari: - gaussian cplxblur: gives a tiny improvement in 2pass ratecontrol
x264_me-prepass_DeathTheSheep.01.diff
http://forum.doom9.org/showthread.php?p=1093523
x264_2pass_vbv.7.diff
http://thread.gmane.org/gmane.comp.video.x264.devel/3093/focus=3748
x264_hrd_pulldown.04_interlace.diff
- HRD and pulldown for HD compatibility, updated patch for interlacing
http://forum.doom9.org/showthread.php?p=1047919#post1047919

Link to x264 patches collected: http://files.x264.nl/x264_patches/

[burfadel]

Another test with revision 805, the GCC 4.4.0 version was faster every time!

Bobor's normal and modified builds with GCC 3.4.6 for this test averaged 29.84 fps (they both averaged very close so I grouped them together, I believe the additional patches don't affect the settings I was using).

The GCC 4.4.0 build averaged 30.32fps, and again on each test the slowest run was still faster than the fastest run with the GCC 3.4.6 builds. I used the exact same settings for both, run from the command line.

It looks like GCC 4.4.0 will be a good option once finalised for Bobor's website, since its a significant improvement over 4.3.0 and lower!

[survivant001]

x264.805.modified.exe (http://files.x264.nl/x264.805.modified.exe)

General thread:
http://forum.doom9.org/showthread.php?t=130364

x264.gaussian.cplxblur.01.diff
Dark Shikari: - gaussian cplxblur: gives a tiny improvement in 2pass ratecontrol
x264_me-prepass_DeathTheSheep.01.diff
http://forum.doom9.org/showthread.php?p=1093523
x264_2pass_vbv.6.diff
http://thread.gmane.org/gmane.comp.video.x264.devel/3093/focus=3550
x264_hrd_pulldown.04_interlace.diff
- HRD and pulldown for HD compatibility, updated patch for interlacing
http://forum.doom9.org/showthread.php?p=1047919#post1047919

Link to x264 patches collected: http://files.x264.nl/x264_patches/


why did you include vbv patch 7 ?

[Wishbringer]

Tested x264 bob0r's gcc 3.4.6 build 805 vs. MythCreator's gcc 4.4.0 build 805:
System: EVGA 780i, QX6700 (at 3.2GHz - Multi=12), 8GB DDR2-800 RAM, Vista64 Ultimate

bob0r
-[Information] Log for job1 (video, Test.avs -> Test_video_bob0r.mp4)
--[Information] [31.03.2008 19:47:05] Started handling job
--[Information] [31.03.2008 19:47:05] Preprocessing
--[NoImage] Job commandline: "C:\Program Files (x86)\megui\tools\x264\x264.805.modified.exe" --crf 18 --level 4.1 --ref 8 --mixed-refs --no-fast-pskip

--bframes 16 --b-pyramid --b-rdo --bime --weightb --direct auto --subme 7 --trellis 2 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --vbv-bufsize 9000 --vbv-

maxrate 24000 --me umh --threads auto --thread-input --sar 4993:5000 --progress --no-dct-decimate --output "D:\Filme\Test_video_bob0r.mp4"

"D:\Filme\Test.avs" --aud --nal-hrd --me-prepass
--[Information] [31.03.2008 19:47:06] Encoding started
--[NoImage] Standard output stream:
--[NoImage] Standard error stream
---[NoImage] avis [info]: 1920x816 @ 25.00 fps (2977 frames)
---[NoImage] x264 [info]: using SAR=4993/5000
---[NoImage] x264 [warning]: DPB size (18800640) > level limit (12582912)
---[NoImage] x264 [info]: using cpu capabilities: MMX MMXEXT SSE SSE2 SSE3 SSSE3 Cache64
---[NoImage] mp4 [info]: initial delay 2 (scale 25)
---[NoImage] x264 [info]: slice I:44 Avg QP:17.87 size:181942 PSNR Mean Y:45.82 U:50.39 V:51.29 Avg:46.92 Global:44.63
---[NoImage] x264 [info]: slice P:1291 Avg QP:19.59 size:104266 PSNR Mean Y:43.02 U:48.19 V:49.09 Avg:44.21 Global:43.92
---[NoImage] x264 [info]: slice B:1642 Avg QP:21.21 size: 37879 PSNR Mean Y:42.19 U:48.12 V:48.98 Avg:43.46 Global:43.20
---[NoImage] x264 [info]: mb I I16..4: 16.9% 51.8% 31.3%
---[NoImage] x264 [info]: mb P I16..4: 3.3% 11.2% 5.1% P16..4: 49.2% 23.4% 6.2% 0.0% 0.0% skip: 1.6%
---[NoImage] x264 [info]: mb B I16..4: 0.7% 2.0% 1.0% B16..8: 44.8% 3.5% 5.0% direct: 9.8% skip:33.3%
---[NoImage] x264 [info]: 8x8 transform intra:56.1% inter:39.6%
---[NoImage] x264 [info]: direct mvs spatial:99.9% temporal:0.1%
---[NoImage] x264 [info]: ref P 80.0% 13.0% 2.8% 1.4% 0.8% 0.8% 0.6% 0.5%
---[NoImage] x264 [info]: ref B 83.7% 13.1% 1.5% 0.7% 0.4% 0.3% 0.2%
---[NoImage] x264 [info]: SSIM Mean Y:0.9805205
---[NoImage] x264 [info]: PSNR Mean Y:42.605 U:48.185 V:49.062 Avg:43.840 Global:43.514 kb/s:13759.53
---[NoImage] encoded 2977 frames, 2.41 fps, 13763.75 kb/s
--[Information] Final statistics
---[NoImage] Desired video bitrate: 18 kbit/s
---[NoImage] Obtained video bitrate (approximate: 13764 kbit/s
--[Information] [31.03.2008 20:07:45] Job completed
--[Information] [31.03.2008 20:07:45] Postprocessing
---[Information] Deleting intermediate files


MythCreator
-[Information] Log for job1 (video, Test.avs -> Test_video_MythCreator.mp4)
--[Information] [31.03.2008 19:15:23] Started handling job
--[Information] [31.03.2008 19:15:23] Preprocessing
--[NoImage] Job commandline: "C:\Program Files (x86)\megui\tools\x264\x264.805.modified.experimental.exe" --crf 18 --level 4.1 --ref 8 --mixed-refs --no-fast-pskip --bframes 16

--b-pyramid --b-rdo --bime --weightb --direct auto --subme 7 --trellis 2 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --vbv-bufsize 9000 --vbv-maxrate 24000

--me umh --threads auto --thread-input --sar 4993:5000 --progress --no-dct-decimate --output "D:\Filme\Test_video_MythCreator.mp4" "D:\Filme\Test.avs"

--aud --nal-hrd --me-prepass
--[Information] [31.03.2008 19:15:24] Encoding started
--[NoImage] Standard output stream:
--[NoImage] Standard error stream
---[NoImage] avis [info]: 1920x816 @ 25.00 fps (2977 frames)
---[NoImage] x264 [info]: using SAR=4993/5000
---[NoImage] x264 [warning]: DPB size (18800640) > level limit (12582912)
---[NoImage] x264 [info]: using cpu capabilities: MMX MMXEXT SSE SSE2 SSE3 SSSE3 Cache64
---[NoImage] mp4 [info]: initial delay 2 (scale 25)
---[NoImage] x264 [info]: slice I:44 Avg QP:17.87 size:181942 PSNR Mean Y:45.82 U:50.39 V:51.29 Avg:46.92 Global:44.63
---[NoImage] x264 [info]: slice P:1291 Avg QP:19.58 size:104282 PSNR Mean Y:43.02 U:48.19 V:49.09 Avg:44.21 Global:43.92
---[NoImage] x264 [info]: slice B:1642 Avg QP:21.21 size: 37887 PSNR Mean Y:42.19 U:48.12 V:48.98 Avg:43.46 Global:43.20
---[NoImage] x264 [info]: mb I I16..4: 16.9% 51.8% 31.3%
---[NoImage] x264 [info]: mb P I16..4: 3.3% 11.2% 5.1% P16..4: 49.2% 23.4% 6.2% 0.0% 0.0% skip: 1.6%
---[NoImage] x264 [info]: mb B I16..4: 0.7% 2.0% 1.0% B16..8: 44.7% 3.5% 5.0% direct: 9.9% skip:33.3%
---[NoImage] x264 [info]: 8x8 transform intra:56.0% inter:39.6%
---[NoImage] x264 [info]: direct mvs spatial:99.9% temporal:0.1%
---[NoImage] x264 [info]: ref P 80.0% 13.0% 2.8% 1.4% 0.9% 0.8% 0.6% 0.5%
---[NoImage] x264 [info]: ref B 83.6% 13.1% 1.5% 0.7% 0.4% 0.3% 0.2%
---[NoImage] x264 [info]: SSIM Mean Y:0.9805220
---[NoImage] x264 [info]: PSNR Mean Y:42.605 U:48.184 V:49.062 Avg:43.840 Global:43.514 kb/s:13761.79
---[NoImage] encoded 2977 frames, 2.41 fps, 13766.00 kb/s
--[Information] Final statistics
---[NoImage] Desired video bitrate: 18 kbit/s
---[NoImage] Obtained video bitrate (approximate: 13767 kbit/s
--[Information] [31.03.2008 19:36:01] Job completed
--[Information] [31.03.2008 19:36:01] Postprocessing
---[Information] Deleting intermediate files

bob0r's build has a slightly lower bitrate: 13763.75 kb/s vs. 13766.00 kb/s
maybe because of "x264_2pass_vbv.6.diff" instead of "x264_2pass_vbv.7.diff"

both encoded at 2.41 fps: bob0r = 20min40sec; MythCreator = 20min38sec
2secs difference seems to be fault-tolerance

[bob0r]

why did you include vbv patch 7 ?

Fixed, just a typo, 7 was used.

Seems there is 8 now?

[tenkai]

L 4.1 ref 8? and 16 bframes? Do you think that will work out? :D I´m just wondering if i missed anything.. wasn´t the max 5 ref on 1920x800 for example and 3 bframes on L.4.1 encoding?

[Wishbringer]

Fixed, just a typo, 7 was used.

Now I am a bit curios. I thought that same build with same patches should produce same bitcompatible encoded output of videostream, independend of used compiler...

See my previous post, where bob0r's build produced a slightly smaller encoded video.

[Wishbringer]

@tenkai:

I didn't said, that this is a useable clip on any standalone player.
I used my PS3-SD profile on a HD clip, because I wanted to test how encoding speed is in compare with nearly all options maxed out.
On the other hand, these settings work very well with my SD DVD conversions for my PS3.

[tenkai]

oki.. SD with ref 8 etc shouldn´t be a prob, yea. so am i right? Its still the max for 1080p encoding to fit quality and full support on ps3 etc ref 4/5 but with maximal 3 bframes? I´m askin coz i want to have the maximum possible quality but having a compatible encode on the other hand.. and i have no idea if i can reach that with ref 5 and 3 bfr.. even with subme 7 etc :(

[tenkai]

some ideas, tweaks are welcomed ofcoz :)

[bob0r]

x264.808.modified.exe (http://files.x264.nl/x264.808.modified.exe)

General thread:
http://forum.doom9.org/showthread.php?t=130364

x264.gaussian.cplxblur.01.diff
Dark Shikari: - gaussian cplxblur: gives a tiny improvement in 2pass ratecontrol
x264_me-prepass_DeathTheSheep.01.diff
http://forum.doom9.org/showthread.php?p=1093523
x264_2pass_vbv.7.diff
http://thread.gmane.org/gmane.comp.video.x264.devel/3093/focus=3748
x264_hrd_pulldown.04_interlace.diff
- HRD and pulldown for HD compatibility, updated patch for interlacing
http://forum.doom9.org/showthread.php?p=1047919#post1047919

Link to x264 patches collected: http://files.x264.nl/x264_patches/

[MythCreator]

x264.808.modified.experimental.exe (http://www.fs2you.com/files/564e6247-009c-11dd-855e-0014221f4662/)

General thread:
http://forum.doom9.org/showthread.php?t=130364

x264.gaussian.cplxblur.01.diff
Dark Shikari: - gaussian cplxblur: gives a tiny improvement in 2pass ratecontrol
x264_me-prepass_DeathTheSheep.01.diff
http://forum.doom9.org/showthread.php?p=1093523
x264_2pass_vbv.7.diff
http://thread.gmane.org/gmane.comp.video.x264.devel/3093/focus=3748
x264_hrd_pulldown.04_interlace.diff
- HRD and pulldown for HD compatibility, updated patch for interlacing
http://forum.doom9.org/showthread.php?p=1047919#post1047919
x264_fix_win_stdin.diff
http://forum.doom9.org/showthread.php?p=1120065#post1120065

Link to x264 patches collected: http://files.x264.nl/x264_patches/



make frofiled in GCC 4.4.0 20080331 experimental,totally for experiment & test

[audyovydeo]

bob0r,

I noticed the Thread Pool patch hasn't been applied in a while.
I haven't seen at which point it has been dumped : is it no longer useful, or it simply hasn't been updated ?


Also, am I alone in regretting SVN versioning ? Git seems pretty f_d up.


cheers
a/v

[SpAwN_gUy]

Also, am I alone in regretting SVN versioning ? Git seems pretty f_d up. i was also thinking about WHY? ... SVN is just "New" (comparing to CVS) and git.. is just "newer"...
so.. why?

[nm]

i was also thinking about WHY? ... SVN is just "New" (comparing to CVS) and git.. is just "newer"...
so.. why?
Git is in many ways better than SVN and it makes things easier for collaborative development.

[Henrikx]

What Patches would be useful in a Linux Build (Ubuntu).

[J_Darnley]

What do you want your build to do differently than the git source? The patches (not the Win stdin patch) should work the same way on all systems.

[Henrikx]

@J_Darnley

The patches (not the Win stdin patch) should work the same way on all systems.
That is precisely what I wanted to know.

THX!

[DeathTheSheep]

Git might be newer, and from a developer's standpoint it might be "supposedly" advantageous, but for pete's sake, the web interface is AWFUL. It can't even list the revision number on its (butt-ugly) log.

Ironic an encoder that makes video quite pretty has such an ugly developer's interface. Simplicity, I know...

[Sharktooth]

that's coz there's no revision number in git...

[DeathTheSheep]

Exactly my point. :)

Maybe you should "make the move" and switch your builds to a "last modified date," rather than revision number?

...on second thought, I've grown fond of the revision number system. :P

[edit]
More on topic, I'm thinking of optimizing prepass a bit more, at least so that it shares x264's new mv clipping method. Additionally, I'm also thinking of re-releasing AQ0.46 to overwrite the current 1.0 AQ (possibly deciding which rounding method to use based on whether or not an "--anime" tag is specified).

What sayeth thee?

[SpAwN_gUy]

Additionally, I'm also thinking of re-releasing AQ0.46 to overwrite the current 1.0 AQ (possibly deciding which rounding method to use based on whether or not an "--anime" tag is specified).

What sayeth thee?Cool. :) .. nice and simple... just --anime... and you're an Anime Encoder :) ..

maybe, it would be nice to make such optimisations not only for AQ? (like lame with its presets..)

[Razorholt]

How about grown-ups who don't like whatching cartoons? Kiiiiiding :)

What's your intention DeathTheSheep in re-releasing 0.46? Using it for anime only? Don't you think VAQ2 is better?

[Dark Shikari]

How about grown-ups who don't like whatching cartoons? Kiiiiiding :)

What's your intention DeathTheSheep in re-releasing 0.46? Using it for anime only? Don't you think VAQ2 is better?His purpose is to discourage me from ever releasing any patches publicly again by intentionally distributing broken code with my name on it. :rolleyes:

[~bT~]

^ that's sad :p

keep up the gr8 work Dark!

[burfadel]

Its probably the combination of settings he's using is falsely giving the impression that 0.46 is better, when for example if crf mode the objective quality and file size better relates to simply lowering the crf value. A much better way would be to lower the crf instead. It could also be a settings issue where non-ideal settings are used? Of course with solid colour in anime (the Japanese definition of which is all animation), it probably just simply means lowering the AQ strength slightly may benefit, say to 0.7, and disabling fast-pskip! by --no-fast-pskip which is purported to be better in those situations.

Actually Dark_shikari, how is the relationship between --no-fast-pskip and AQ, do they affect each other? I was just thinking that if a slight deterioration occurs on solid colour due to pskip, AQ may be compensating hence causing problems referred to by deaththesheep? I'm only guessing here...

[Dark Shikari]

Actually Dark_shikari, how is the relationship between --no-fast-pskip and AQ, do they affect each other? I was just thinking that if a slight deterioration occurs on solid colour due to pskip, AQ may be compensating hence causing problems referred to by deaththesheep? I'm only guessing here...AQ will reduce the amount of blocks in which fast-pskip is activated, yes. The primary effect is a reduction in speed.

[burfadel]

Therefore for anime, 0.46 was possibly not correcting the pskip induced areas that occur in flat areas, at least to the extent of the proper VAQ? leaving more bits for lines?

If thats the case, is variable fast-pskip possible? that is, only apply fast-pskip to non-flat areas? I'm guessing that would improve the picture quality and effectiveness of VAQ, and since it would only be applied to flat areas (or largely flat areas) not induce the speed penalty that occurs when --no-fast-pskip is applied? That would be a good default option if possible! I believe its only flat areas that are visually penalised by using fast-pskip?

[DeathTheSheep]

Mmkay guys, lots of stuff to address:

What's your intention DeathTheSheep in re-releasing 0.46? Using it for anime only? Don't you think VAQ2 is better?
My intentions at the time of initial posting were nil, which is precisely the reason why I was gathering input. I've made extensive quality comparisons of the two and have found 0.46 produces a significantly higher SSIM and (perceived) visual quality on low-bitrate (high quantizer) anime sources, especially in baseline profile, and regardless of other options used. However, I do plan to wait it out a bit in the hopes that DS will in fact address anime specifically in VAQ2.0 (read below).

His purpose is to discourage me from ever releasing any patches publicly again by intentionally distributing broken code with my name on it.
What! I appreciate your work as much as (or perhaps more than) most. Recall I was of the very first to support your first x264 hacks (remember x264-sad-opt and such?), and was always in favor of you releasing all and anything you could. I can't understand your accusation of me intentionally discouraging you...unless the underlying intention of this statement is the OS equivalent of FUD (I'm teasing here, but really now, it's unprofessional). Look at my sources, people--any anime sources, including Gundam Seed--and test yourself. My tests were all very clear, replete with commandlines, the source, tons of screenshots, visual analysis, the sample clips, metrics (especially the one found in the "megathread"). Besides, the code is certainly not "broken" (though the rounding is mathematically suboptimal), and if you'd like I can take your name off of it, DS. You can disown your ugly first born, if you will. But at your strongly suggested request, I will hold off on releasing it and instead watch the progress of VAQ 2.0.

Its probably the combination of settings he's using is falsely giving the impression that 0.46 is better
Wrong, my good sir. While I do not profess nearly the code affinity and proficiency of DS, I understand the quality settings of x264 at least well enough to conduct proper and thorough testing (note: baseline/mobile profile). However, in doubt, I also used an exhaustive testing rubric, trying a ridiculously large combination of settings in the effort to convince myself. As you recall, I used no-fast-pskip in the majority of my testing--but certainly not all--and please remember the fact that the underlying algorithm is essentially a quantizer redistribution according to a variance function, not an intentional modification of color information. The difference between 1.0 and 0.46, for instance, is the rounding for core formula. That is all.

If you want a technical explanation, refer to the previous thread. 1.0 is no longer a patch. The admittedly interesting postulate that 0.46 is "favoring lines" isn't necessarily the case either. The quantizers were properly raised, but to the extent that the x264 deblocker would (conveniently) efficiently conceal artifacts. Additionally, relatively flat backgrounds and such were indeed awarded lower quantizers, but not to the extent that blocks would reappear due to an excess or an irregularity of distribution across the entire background. However, it isn't a matter of simply decreasing AQ strength on 1.0 to re-acheive this fragile balance--rather, the two algorithms have a markedly distinct visual effect from one another, for better (as DS strongly supports), or for worse (as DS strongly opposes, since his interests understandably lie with his newer codebase, the evolution of his brainchild).

And indeed, this is only noticeable on anime. Perhaps 0.48/1.0 is in the lead as regards live footage/non-anime content. One would be more willing to accept that a perfected mathematical formula to account for real quantization error would perform more optimally on non-artificial footage unlike anime.

But when all is said and done, this isn't a settings discussion, or a question of whether or not anybody/anything knows what he/it's doing, or who/what is right and wrong about the subtleties of the algorithms at hand--I had wanted a re-release so that any user can come along and see it for himself with his sources and bitrates which performed more optimally for his needs.

The point of fact is, there is far too much contention, and I fear re-releasing AQ 0.46 at this point will do much in the way of hurting DS (his feelings, his name, his efforts) and perhaps the concept of "progress" itself, so I will not. At least not until 2.0 has matured enough to make differences meaningful, not to mention worthwhile. I have my eyes on it, in the meantime...

[Dark Shikari]

Look at my sources, people--any anime sources, including Gundam Seed--and test yourself. My tests were all very clear, replete with commandlines, the source, tons of screenshots, visual analysis, the sample clips, metrics (especially the one found in the "megathread").Your tests were completely invalid, and only proved one thing: lower AQ strength was better on certain frames in anime. Because 0.46 had an effectively lower strength, it therefore performed better on those frames. You have never ever posted any comparison clip in which AQ 0.46 offered a "better" distribution of QPs except in that it offered a weaker AQ.

Yet you cannot accept this simple fact, and continue to simply post cherrypicked comparison frames and intentionally misleading comparisons in order to promote an algorithm that does not make sense.

I welcome an attempt to make a better AQ for anime; I have had a number of ideas in mind, in fact, such as intentionally raising QP for flat blocks while putting lambda much lower, to take advantage of the higher deblocking.

I don't welcome an attempt to rip off a broken, bugged version of my own work and, through a careful campaign of misleading comparisons, declare it "better."

[DeathTheSheep]

Nobody sweepingly declared anything better, and people can determine for themselves whether or not my tests were valid. I strongly believe in their suggestive validity. The higher 0.46 AQ strength was optimal metrically and visually when keyframes (or the frames you "cherrypicked" [that's a funny word] immediately proceeding them!) were respectively boosted. Again, the frames I chose were random. Again, I did not base my comparisons off of still shots.

I welcome your ideas to make AQ better for anime. So much so I'm not re-releasing 0.46, as I said. Please don't misinterpret, and please don't go on the defensive/offensive about this. How about you email me, and I'll take this whole shebang off air, eh?

[Dark Shikari]

I welcome your ideas to make AQ better for anime.If you want to work on this, drop by #x264dev; I'd be happy to help. I'm somewhat interested in the concept myself, and given your success in getting QNS to work, I suspect you're good enough at coding that given enough guidance you can try out some ideas ;)
So much so I'm not re-releasing 0.46, as I said.Good that's cleared up then.

[DeathTheSheep]

Hey, I'm not one to so easily forget about that little QNS present you presented me. I owe you big time for help on that. And for that, period. :)

[Razorholt]

Can we once for all determine how to declare what's best? If comparing frames doesn't make sense at all (Although you DS as well as others is using that method very often) and if SSIM doesn't always make sense either, so what does? I'm talking about professional judgment and not personal taste.

I have the feeling that this little war between VAQ 0.46 partisans and VAQ 1.0 enthusiasts will not end soon... And I don't think it benefits the majority of us (x264 users).

I'm personally spending a lot of hours encoding and comparing VAQ settings because it's the least I can do to “give back”, but I want to know whether my time is spent wisely.


Thanks,
- Dan

[DeathTheSheep]

Actually, trying to find the "best" is banned in this forum. Even the word. :) You can do metrics, or you can do a double-blind elsewhere.

But, as DS suggested, it's best to pick up 2.0 and optimize that specifically rather than keep around the old guy.

[Razorholt]

So, SSIM + frames comparison will work or not? - I'm talking about comparing settings.

[DeathTheSheep]

Why not? Nobody's stopping you, knock yourself out. But in retrospect, 1.0 is committed, and there's a 2.0 under wraps, so why not just integrate 0.46's benefit (not the formula, but some "anime optimization") into 2.0 while it's still not out of the oven?

[Razorholt]

No no, I'm talking about comparing different settings using VAQ2 exclusively. Oh well, I'll stick to frames + SSIM and that's it. :)

[burfadel]

So variable fast-pskip, so that is only applies to non-flat areas wouldn't actually work?!

[lexor]

No no, I'm talking about comparing different settings using VAQ2 exclusively. Oh well, I'll stick to frames + SSIM and that's it. :)

I think the original quote by DS about frame to frame comparison being useless is being misinterpreted. What I think it should say is that you can't take just one frame and compare that frame with different settings. If you take enough frames out of the stream and compare them using different settings, it's valid.

Think of it this way, bits have to go somewhere. If one frame has lost some, another had to gain some to maintain bitrate (especially with 2pass). So selecting like 1 or 2% of frames at random (random is important here) and comparing them is useful and will yield a valid result. Though it will be difficult if the source has a large number of frames (i.e. you aren't testing on a short clip). You can of course reduce the number of frames (2% I would say is an overkill) at the expense of confidence in your conclusion. However don't just use avisynth's selectevery()/even/whatever-else function, you have got to pick randomly as many frames as you are willing to compare. So get a decent pseudo-random number generator (random.org is a good place for a quick one) generate N numbers between 1 and max_num_frames in your clip, then compare the frames corresponding to those numbers.

[Dark Shikari]

I think the original quote by DS about frame to frame comparison being useless is being misinterpreted. What I think it should say is that you can't take just one frame and compare that frame with different settings. If you take enough frames out of the stream and compare them using different settings, it's valid.One trick is to also compare frame sizes: if two frames are quite different sizes, its probably not a valid comparison.

With P/B frames, one also has to look at the size of the last I-frame and recent frames, too.

[DeathTheSheep]

Hot diggity dang, QNS is so good it hurts. And so slow it hurts. (Hey, there's always the tradeoff).

It's simply amazing in baseline. It brings CAVLC encoding to the efficiency of CABAC+trellis encoding. Well, you know. Pretty much. It's absolutely, utterly, ridiculously good on low-bitrate anime. No, no, forget AQ for now, this thing is already on the table. This is the first real progress baseline profile has seen since AQ. And that was the first ever, pretty much, since general RDO refinements. Usually CABAC and B-frames and trellis are required when quality is increased, but nobody seemed to care about where the quality hits home the most--in the lowest bitrates, for older computers or crappy decoders or handhelds or small screens and so on.

QNS is astounding. I can't believe something like tucking quant error in strange places does something this...marked. Is there any hope of a speedup??!

[Dark Shikari]

Hot diggity dang, QNS is so good it hurts. And so slow it hurts. (Hey, there's always the tradeoff).

It's simply amazing in baseline. It brings CAVLC encoding to the efficiency of CABAC+trellis encoding. Well, you know. Pretty much. It's absolutely, utterly, ridiculously good on low-bitrate anime. No, no, forget AQ for now, this thing is already on the table. This is the first real progress baseline profile has seen since AQ. And that was the first ever, pretty much, since general RDO refinements. Usually CABAC and B-frames and trellis are required when quality is increased, but nobody seemed to care about where the quality hits home the most--in the lowest bitrates, for older computers or crappy decoders or handhelds or small screens and so on.

QNS is astounding. I can't believe something like tucking quant error in strange places does something this...marked. Is there any hope of a speedup??!This is because QNS does two things:

1. It serves as a non-optimal version of trellis that works on CAVLC. Normal trellis might actually have to be exponential time to work on CAVLC. This means you get most of the benefits of trellis on CAVLC, at a high speed cost (but not as high as true trellis). One thing you might want to try is to not use the variance-weighting at all (use a constant weight for each pixel) and then change the "error *= 38" line to make the bitrate equal to what it was before in CRF mode; this will make the result of QNS basically like trellis. Considering the amazing benefit of both trellis and CABAC on low-bitrate anime, its not surprising QNS is also so useful.

2. It weights the value of pixels based on their local variance.

Possible speedups:

1. Find a way to estimate the bit cost of a decision without doing an actual macroblock_write. Trellis already has this; obviously its method is CABAC-only.

2. Make a special IDCT function that adds only a single basis vector to an existing IDCT output, since we're only adjusting one coefficient at a time. FFmpeg has something like this for the regular DCT, which is even more important there since MPEG-2/MPEG-4 ASP use much slower DCT algorithms than H.264 does.

3. ASM-ize the quality metric used.

4. Don't look at coefficients that are already zeroed.

5. Don't consider raising or lowering any coefficient more than once.

[DeathTheSheep]

Varience-weighting, I wonder how it would stack on top of Variance AQ. At the same filesize and settings, I get:
Normal 0.46: SSIM: 0.9752356
w/QNS 0.46: SSIM: 0.9758788

I notice less artifacts in the QNS encode (surprised? :P).
That's a sizable boost even with VAQ on (admittedly I did use 0.46, though, as it was the only one with adjustable sensitivity I had lying around).

So if I disable variance weighting, will this likely go up or down with VAQ? :)

[Dark Shikari]

So if I disable variance weighting, will this likely go up or down with VAQ? :)Try and see ;)

[lexor]

One trick is to also compare frame sizes: if two frames are quite different sizes, its probably not a valid comparison.

With P/B frames, one also has to look at the size of the last I-frame and recent frames, too.

It's a bad thing to try to manually find specific frames to compare by an arbitrary criterion like you describe. Just because frames found by that criterion may be better with AQ, the price you pay for them on other frames may be too high. It is the overall quality that we want too see, having a bunch of really good frames counts for little if the rest of the frames tank.

Random selection is as close as we can get to fairness (with large enough sample pool, it will actually achieve fairness), due to natural balancing properties of random selection.

[fields_g]

No no, I'm talking about comparing different settings using VAQ2 exclusively. Oh well, I'll stick to frames + SSIM and that's it. :)

I've been seeing messages about using PNSR finally disappearing. In a non-AQ world, SSIM has much more meaning than now with VAQ. This is because VAQ, in some cases, will lower SSIM to achieve better subjective quality. This is because SSIM is not a perfect match to the average user's perception (although better then PNSR).

With newer VAQ moving bits between frames, select frames can look worse while a segment of encoded time is better perceptually.

My coding abilities are no where close to many here so I'm not one for implementation, but I think I see the need to complete another tool before we further try to tweak VAQ. Do you guys also see a need for some comparison tool (player)?

Load 2 (or more) encoded files, have a single time slider, blind the user of which is which, Side by side and/or toggled playback, user rating, etc. Have you guys seen what tools are available for audio abx? They even have blinded submissions so results can be combined with other people's results!

We can successfully make crude tweaks to psy, but when we start smaller shifts, we do really need something better.

[IgorC]

I totally agree with you.
Public ABX is optimal way to go when test psycho visual enhancements.
There was application MSU ABX for video.

[lexor]

I totally agree with you.
Public ABX is optimal way to go when test psycho visual enhancements.
There was application MSU ABX for video.

Actually I don't think this should be done as a group. Anything but personal tests are not very useful in this case. If you look at the audio ABX tests, they ask one question "can you hear a difference between 2 files?". Testing AQ doesn't just ask the question of "can you see a difference?", it also has to ask "is the difference better?". And "better" is not just a question of more or less noise (as it is in audio abx between multiple formats), it's too much of a personal preference in AQ's case.

I remember when DS first started working on his AQ he asked us to rate a bunch of pics (while fine tuning some params) and the thing that looked best to me was a sharper detailed picture, but others voted for blurrier ones, because that's more DVD like (or so they said).

While ABX will detect difference reliably, in this case it can't really rate quality effectively.

[fields_g]

lexor,
I see what you are saying about abx about perceivable differences. I think you are right, however if it is tied to using high/low anchors and a rating system, meaningful "x" is better than "y" can be determined. Take for example the 64 kbps encoding comparison here (http://www.listening-tests.info/mf-64-1/results.htm). I think your concern also connects to the important note found on the page:
Important note: These plots represent group preferences (for the particular group of people who participated in the test). Individual preferences vary somewhat. The best codec for a person is dependent on his own preferences and the type of music he prefers.
It is true that it is the rating is based on the participants. And not all participants may agree. That is where the averages and confidence intervals come into play.

But your concern that this should be done independently because personal preference varies, I believe, is wrong. Psy is all about compromises. We strive to have the compromises have as little visual impact on the end product for most people. Opinions will differ at points and what wins out should be what is most pleasing for the majority. Therefore it should be tested as a group, with group data backing our decisions.

I'm not saying that only one version of psy will be committed. Eventually I hope we develop multiple psy models, for example anime, noise, darkness, bitrate, etc and interactions between these. Hopefully scene detection will come into the mix and an auto detect setting would choose the correct model for that scene. We are not looking at psy this way yet, and may not ever. We are trying to find broad psy that works on most for most.

We will not be able to commit every conceived psy into x264 and at some point we will need to trim to the most useful. Personal taste needs to be set aside for group tastes at these times. This is where I believe a comparison tool fits.

I'm not trying to sound overly egalitarian, but it has its place when judging subjectively.

Oh yea... acceptance is also based on if x264 authors are willing to maintain the psy code also.

[MythCreator]

x264.815.modified.experimental.exe (http://www.fs2you.com/files/3d178ab5-06e9-11dd-a2d4-00142218fc6e/)

General thread:
http://forum.doom9.org/showthread.php?t=130364

x264.gaussian.cplxblur.01.diff
Dark Shikari: - gaussian cplxblur: gives a tiny improvement in 2pass ratecontrol
x264_me-prepass_DeathTheSheep.01.diff
http://forum.doom9.org/showthread.php?p=1093523
x264_2pass_vbv.7.diff
http://thread.gmane.org/gmane.comp.video.x264.devel/3093/focus=3748
x264_hrd_pulldown.04_interlace.diff
- HRD and pulldown for HD compatibility, updated patch for interlacing
http://forum.doom9.org/showthread.php?p=1047919#post1047919
x264_fix_win_stdin.diff
http://forum.doom9.org/showthread.php?p=1120065#post1120065

Link to x264 patches collected: http://files.x264.nl/x264_patches/



make frofiled in GCC 4.4.0 20080331 experimental,totally for experiment & test

[bob0r]

x264.816.modified.exe (http://files.x264.nl/x264.816.modified.exe)

General thread:
http://forum.doom9.org/showthread.php?t=130364

x264.gaussian.cplxblur.01.diff
Dark Shikari: - gaussian cplxblur: gives a tiny improvement in 2pass ratecontrol
x264_me-prepass_DeathTheSheep.01.diff
http://forum.doom9.org/showthread.php?p=1093523
x264_2pass_vbv.7.diff
http://thread.gmane.org/gmane.comp.video.x264.devel/3093/focus=3748
x264_hrd_pulldown.04_interlace.diff
- HRD and pulldown for HD compatibility, updated patch for interlacing
http://forum.doom9.org/showthread.php?p=1047919#post1047919

Link to x264 patches collected: http://files.x264.nl/x264_patches/

[MythCreator]

x264.816.modified.experimental.exe (http://www.fs2you.com/files/5cad8a23-06ee-11dd-8be7-0014221b798a/)

General thread:
http://forum.doom9.org/showthread.php?t=130364

x264.gaussian.cplxblur.01.diff
Dark Shikari: - gaussian cplxblur: gives a tiny improvement in 2pass ratecontrol
x264_me-prepass_DeathTheSheep.01.diff
http://forum.doom9.org/showthread.php?p=1093523
x264_2pass_vbv.7.diff
http://thread.gmane.org/gmane.comp.video.x264.devel/3093/focus=3748
x264_hrd_pulldown.04_interlace.diff
- HRD and pulldown for HD compatibility, updated patch for interlacing
http://forum.doom9.org/showthread.php?p=1047919#post1047919
x264_fix_win_stdin.diff
http://forum.doom9.org/showthread.php?p=1120065#post1120065

Link to x264 patches collected: http://files.x264.nl/x264_patches/



make frofiled in GCC 4.4.0 20080331 experimental,totally for experiment & test

[Atak_Snajpera]

I cannot find -aq-mode in longhelp :(

[MuLTiTaSK]

I cannot find -aq-mode in longhelp :(


x264 core:59 r816M 761630d
Syntax: x264 [options] -o outfile infile [widthxheight]

Infile can be raw YUV 4:2:0 (in which case resolution is required),
or YUV4MPEG 4:2:0 (*.y4m),
or AVI or Avisynth if compiled with AVIS support (yes).
Outfile type is selected by filename:
.264 -> Raw bytestream
.mkv -> Matroska
.mp4 -> MP4 if compiled with GPAC support (yes)

Options:

-h, --help List the more commonly used options
--longhelp List all options

Frame-type options:

-I, --keyint <integer> Maximum GOP size [250]
-i, --min-keyint <integer> Minimum GOP size [25]
--scenecut <integer> How aggressively to insert extra I-frames [40]
--pre-scenecut Faster, less precise scenecut detection.
Required and implied by multi-threading.
-b, --bframes <integer> Number of B-frames between I and P [0]
--no-b-adapt Disable adaptive B-frame decision
--b-bias <integer> Influences how often B-frames are used [0]
--b-pyramid Keep some B-frames as references
--no-cabac Disable CABAC
-r, --ref <integer> Number of reference frames [1]
--no-deblock Disable loop filter
-f, --deblock <alpha:beta> Loop filter AlphaC0 and Beta parameters [0:0]
--interlaced Enable pure-interlaced mode (tff)
--tff Alias for --interlaced
--bff Enable pure-interlaced mode (bff)

Ratecontrol:

-q, --qp <integer> Set QP (0=lossless) [26]
-B, --bitrate <integer> Set bitrate (kbit/s)
--crf <float> Quality-based VBR (nominal QP)
--vbv-maxrate <integer> Max local bitrate (kbit/s) [0]
--vbv-bufsize <integer> Enable CBR and set size of the VBV buffer (kbit) [0]
--vbv-init <float> Initial VBV buffer occupancy [0.9]
--qpmin <integer> Set min QP [10]
--qpmax <integer> Set max QP [51]
--qpstep <integer> Set max QP step [4]
--ratetol <float> Allowed variance of average bitrate [1.0]
--ipratio <float> QP factor between I and P [1.40]
--pbratio <float> QP factor between P and B [1.30]
--chroma-qp-offset <integer> QP difference between chroma and luma [0]
--aq-mode <integer> How AQ distributes bits [2]
- 0: Disabled
- 1: Avoid moving bits between frames
- 2: Move bits between frames
--aq-strength <float> Reduces blocking and blurring in flat and
textured areas. [1.0]
- 0.5: weak AQ
- 1.5: strong AQ

-p, --pass <1|2|3> Enable multipass ratecontrol
- 1: First pass, creates stats file
- 2: Last pass, does not overwrite stats file
- 3: Nth pass, overwrites stats file
--stats <string> Filename for 2 pass stats ["x264_2pass.log"]
--rceq <string> Ratecontrol equation ["blurCplx^(1-qComp)"]
--qcomp <float> QP curve compression: 0.0 => CBR, 1.0 => CQP [0.60]
--cplxblur <float> Reduce fluctuations in QP (before curve compression) [20.0]
--qblur <float> Reduce fluctuations in QP (after curve compression) [0.5]
--zones <zone0>/<zone1>/... Tweak the bitrate of some regions of the video
Each zone is of the form
<start frame>,<end frame>,<option>
where <option> is either
q=<integer> (force QP)
or b=<float> (bitrate multiplier)
--qpfile <string> Force frametypes and QPs

Analysis:

-A, --partitions <string> Partitions to consider ["p8x8,b8x8,i8x8,i4x4"]
- p8x8, p4x4, b8x8, i8x8, i4x4
- none, all
(p4x4 requires p8x8. i8x8 requires --8x8dct.)
--direct <string> Direct MV prediction mode ["spatial"]
- none, spatial, temporal, auto
--direct-8x8 <-1|0|1> Direct prediction size [-1]
- 0: 4x4
- 1: 8x8
- -1: smallest possible according to level
-w, --weightb Weighted prediction for B-frames
--me <string> Integer pixel motion estimation method ["hex"]
- dia: diamond search, radius 1 (fast)
- hex: hexagonal search, radius 2
- umh: uneven multi-hexagon search
- esa: exhaustive search
- tesa: hadamard exhaustive search (slow)
--merange <integer> Maximum motion vector search range [16]
--mvrange <integer> Maximum motion vector length [-1 (auto)]
--mvrange-thread <int> Minimum buffer between threads [-1 (auto)]
-m, --subme <integer> Subpixel motion estimation and partition
decision quality: 1=fast, 7=best. [5]
--me-prepass Run an ME prepass on predictors. Requires subme 3 or higher.
--b-rdo RD based mode decision for B-frames. Requires subme 6 or higher.
--mixed-refs Decide references on a per partition basis
--no-chroma-me Ignore chroma in motion estimation
--bime Jointly optimize both MVs in B-frames
-8, --8x8dct Adaptive spatial transform size
-t, --trellis <integer> Trellis RD quantization. Requires CABAC. [0]
- 0: disabled
- 1: enabled only on the final encode of a MB
- 2: enabled on all mode decisions
--no-fast-pskip Disables early SKIP detection on P-frames
--no-dct-decimate Disables coefficient thresholding on P-frames
--nr <integer> Noise reduction [0]

--deadzone-inter <int> Set the size of the inter luma quantization deadzone [21]
--deadzone-intra <int> Set the size of the intra luma quantization deadzone [11]
Deadzones should be in the range 0 - 32.
--cqm <string> Preset quant matrices ["flat"]
- jvt, flat
--cqmfile <string> Read custom quant matrices from a JM-compatible file
Overrides any other --cqm* options.
--cqm4 <list> Set all 4x4 quant matrices
Takes a comma-separated list of 16 integers.
--cqm8 <list> Set all 8x8 quant matrices
Takes a comma-separated list of 64 integers.
--cqm4i, --cqm4p, --cqm8i, --cqm8p
Set both luma and chroma quant matrices
--cqm4iy, --cqm4ic, --cqm4py, --cqm4pc
Set individual quant matrices

Video Usability Info (Annex E):
The VUI settings are not used by the encoder but are merely suggestions to
the playback equipment. See doc/vui.txt for details. Use at your own risk.

--overscan <string> Specify crop overscan setting ["undef"]
- undef, show, crop
--videoformat <string> Specify video format ["undef"]
- component, pal, ntsc, secam, mac, undef
--fullrange <string> Specify full range samples setting ["off"]
- off, on
--colorprim <string> Specify color primaries ["undef"]
- undef, bt709, bt470m, bt470bg
smpte170m, smpte240m, film
--transfer <string> Specify transfer characteristics ["undef"]
- undef, bt709, bt470m, bt470bg, linear,
log100, log316, smpte170m, smpte240m
--colormatrix <string> Specify color matrix setting ["undef"]
- undef, bt709, fcc, bt470bg
smpte170m, smpte240m, GBR, YCgCo
--chromaloc <integer> Specify chroma sample location (0 to 5) [0]

Input/Output:

-o, --output Specify output file
--sar width:height Specify Sample Aspect Ratio
--fps <float|rational> Specify framerate
--seek <integer> First frame to encode
--frames <integer> Maximum number of frames to encode
--level <string> Specify level (as defined by Annex A)

-v, --verbose Print stats for each frame
--progress Show a progress indicator while encoding
--quiet Quiet Mode
--no-psnr Disable PSNR computation
--no-ssim Disable SSIM computation
--threads <integer> Parallel encoding
--thread-input Run Avisynth in its own thread
--non-deterministic Slightly improve quality of SMP, at the cost of repeatability
--no-asm Disable all CPU optimizations
--visualize Show MB types overlayed on the encoded video
--sps-id <integer> Set SPS and PPS id numbers [0]
--aud Use access unit delimiters
--nal-hrd Use NAL HRD parameters
--pulldown <integer> Use 3:2 pulldown
- 32: TBT,BT,BTB,BT pattern
- 64: triple,double *recommended for 720p

[Atak_Snajpera]

I need stronger glasses :)

[bob0r]

I need stronger glasses :)

Or put them on (avatar) :rolleyes:

[bob0r]

x264.818.modified.exe (http://files.x264.nl/x264.818.modified.exe)

General thread:
http://forum.doom9.org/showthread.php?t=130364

x264.gaussian.cplxblur.01.diff
Dark Shikari: - gaussian cplxblur: gives a tiny improvement in 2pass ratecontrol
x264_me-prepass_DeathTheSheep.01.diff
http://forum.doom9.org/showthread.php?p=1093523
x264_2pass_vbv.7.diff
http://thread.gmane.org/gmane.comp.video.x264.devel/3093/focus=3748
x264_hrd_pulldown.04_interlace.diff
- HRD and pulldown for HD compatibility, updated patch for interlacing
http://forum.doom9.org/showthread.php?p=1047919#post1047919

Link to x264 patches collected: http://files.x264.nl/x264_patches/

[SpAwN_gUy]

can i post this here?

ok. i've found a solution about howto build x264 in MSVC 2005 ... and even with some patches..
but..

i'm having strange compiler errors about "no ";" before "type"" when x264.gaussian.cplxblur.01.diff is applied (just before first declaration of "double gaussian_weight").. is it fixable?

and i'm a bit confused.. how to determine REVISION, when having access only to daily tar-balls?

is there a way to configure git to use proxy?

any simple howto apply patches? (git-merge applied only x264_hrd_pulldown.04_interlace.diff ... and even not on ALL files...)

upd.can anyone test this?
revision... em.. from 20080410. modified.
gPACK, pthreads - enabled :)

applied patches:
x264_me-prepass_DeathTheSheep.01.diff
x264_2pass_vbv.7.diff
x264_hrd_pulldown.04_interlace.diff
- HRD and pulldown for HD compatibility, updated patch for interlacing

removed...

[SpAwN_gUy]

ok.. i've made another one... this one is a bit MORE proper :) .. the previous one had constant glitches on some scenes of my testencode... this one went just fine... if anyone interested...

BTW.. i've changed a bit first patch... 'cause under MSVC it still gave me
"error C2143: syntax error : missing ';' before 'type' d:\CVS\x264farm-GUI\x264\build\x264\encoder\ratecontrol.c line: 1757"

so i had to make it like this:
if(weight < .0001){
break;
}
else {
double gaussian_weight = weight * exp(-j*j/200.0);
weight_sum += gaussian_weight;
cplx_sum += gaussian_weight * (qscale2bits(rcj, 1) - rcj->misc_bits);
}

x264 rev.819, modified, MSVC2005 build
General thread:
http://forum.doom9.org/showthread.php?t=130364

x264.gaussian.cplxblur.01.diff
Dark Shikari: - gaussian cplxblur: gives a tiny improvement in 2pass ratecontrol
x264_me-prepass_DeathTheSheep.01.diff
http://forum.doom9.org/showthread.php?p=1093523
x264_2pass_vbv.7.diff
http://thread.gmane.org/gmane.comp.video.x264.devel/3093/focus=3748
x264_hrd_pulldown.04_interlace.diff
- HRD and pulldown for HD compatibility, updated patch for interlacing
http://forum.doom9.org/showthread.php?p=1047919#post1047919

grab it here (http://rapidshare.com/files/107703602/x264.819.msvc2005.modified.exe)

[buzzqw]

@ALL

please apply the x264_fix_win_stdin.diff too!

BHH

[bob0r]

x264.819.modified.exe (http://files.x264.nl/x264.819.modified.exe)

General thread:
http://forum.doom9.org/showthread.php?t=130364

x264.gaussian.cplxblur.01.diff
Dark Shikari: - gaussian cplxblur: gives a tiny improvement in 2pass ratecontrol
x264_me-prepass_DeathTheSheep.01.diff
http://forum.doom9.org/showthread.php?p=1093523
x264_2pass_vbv.7.diff
http://thread.gmane.org/gmane.comp.video.x264.devel/3093/focus=3748
x264_hrd_pulldown.04_interlace.diff
HRD and pulldown for HD compatibility, updated patch for interlacing
http://forum.doom9.org/showthread.php?p=1047919#post1047919
x264_fix_win_stdin.diff
http://mailman.videolan.org/pipermail/x264-devel/2008-March/004325.html

Link to x264 patches collected: http://files.x264.nl/x264_patches/

[Sharktooth]

on my way.

[SpAwN_gUy]

please apply the x264_fix_win_stdin.diff too! not needed, when compiled with MSVC ;)

[MythCreator]

x264.820.modified.experimental.exe (http://www.fs2you.com/files/27b407f8-0ba3-11dd-b243-0014221f3995/)

General thread:
http://forum.doom9.org/showthread.php?t=130364

x264.gaussian.cplxblur.01.diff
Dark Shikari: - gaussian cplxblur: gives a tiny improvement in 2pass ratecontrol
x264_me-prepass_DeathTheSheep.01.diff
http://forum.doom9.org/showthread.php?p=1093523
x264_2pass_vbv.7.diff
http://thread.gmane.org/gmane.comp.video.x264.devel/3093/focus=3748
x264_hrd_pulldown.04_interlace.diff
- HRD and pulldown for HD compatibility, updated patch for interlacing
http://forum.doom9.org/showthread.php?p=1047919#post1047919
x264_fix_win_stdin.diff
http://forum.doom9.org/showthread.php?p=1120065#post1120065

Link to x264 patches collected: http://files.x264.nl/x264_patches/



make frofiled in GCC 4.4.0 20080331 experimental,totally for experiment & test

[bob0r]

x264.826.modified.exe (http://files.x264.nl/x264.826.modified.exe)

General thread:
http://forum.doom9.org/showthread.php?t=130364

x264.gaussian.cplxblur.01.diff
Dark Shikari: - gaussian cplxblur: gives a tiny improvement in 2pass ratecontrol
x264_me-prepass_DeathTheSheep.01.diff
http://forum.doom9.org/showthread.php?p=1093523
x264_2pass_vbv.7.diff
http://thread.gmane.org/gmane.comp.video.x264.devel/3093/focus=3748
x264_hrd_pulldown.04_interlace.diff
HRD and pulldown for HD compatibility, updated patch for interlacing
http://forum.doom9.org/showthread.php?p=1047919#post1047919
x264_fix_win_stdin.diff
http://mailman.videolan.org/pipermail/x264-devel/2008-March/004325.html

Link to x264 patches collected: http://files.x264.nl/x264_patches/

[Sharktooth]

bobor, i constantly check this thread for modified builds for megui.
however, can you manage to stress D_S to obtain an updated FGO patch for the next build? ;)

[bob0r]

I am holding his fastest Intel System Hostage, he is giving me all the patches i demand!

I can compile FGO now, but i rather do it with a new further developed and easy appliable patch :D

[MythCreator]

x264.830.modified.experimental.exe (http://www.fs2you.com/files/42390bcc-1372-11dd-bf57-0014221f4662/)

General thread:
http://forum.doom9.org/showthread.php?t=130364

x264.gaussian.cplxblur.01.diff
Dark Shikari: - gaussian cplxblur: gives a tiny improvement in 2pass ratecontrol
x264_me-prepass_DeathTheSheep.01.diff
http://forum.doom9.org/showthread.php?p=1093523
x264_2pass_vbv.7.diff
http://thread.gmane.org/gmane.comp.video.x264.devel/3093/focus=3748
x264_hrd_pulldown.04_interlace.diff
- HRD and pulldown for HD compatibility, updated patch for interlacing
http://forum.doom9.org/showthread.php?p=1047919#post1047919
x264_fix_win_stdin.diff
http://forum.doom9.org/showthread.php?p=1120065#post1120065
x264_fgo.01.826.diff
32x32samples_crash.diff
cosmetic.diff
debug-defines.diff
fix_stats_file_work_for_cli.diff
frames_memoryleak.diff
multithreading_Nth_pass_ratecontrol.diff
http://forum.doom9.org/showthread.php?p=1128461#post1128461


Link to x264 patches collected: http://files.x264.nl/x264_patches/



make frofiled in GCC 4.4.0 20080331 experimental,totally for experiment & test

[Rodger]

x264.830.modified.experimental.exe (http://www.fs2you.com/files/42390bcc-1372-11dd-bf57-0014221f4662/)



I can´t sugguest this release as it totally sucks doing an encode 1280*720 at 4Mbit! Total blockyness! everything washed out.
Just my 2 cents.

[burfadel]

If its just that build and not the normal 830 build it would be interesting to know which patch causes the problem, let alone helpful for those maintaining/developing the patches!

[Dark Shikari]

I can´t sugguest this release as it totally sucks doing an encode 1280*720 at 4Mbit! Total blockyness! everything washed out.
Just my 2 cents.Does it give particularly *different* results from a non-experimental build? Most of the extra patches applied are off by default...

[MythCreator]

I can´t sugguest this release as it totally sucks doing an encode 1280*720 at 4Mbit! Total blockyness! everything washed out.
Just my 2 cents.



Maybe you use FGO?Or something else.I doing an encode 1280*720 at 1.5Mbps,everything was fine....

Here's my settings

--no-psnr --no-ssim --cqmfile "C:\AutoMKV\profiles\x264-profiles\matrix\M4G_High_Detail_V3.1.cfg" --no-fast-pskip --no-dct-decimate --mixed-refs --scenecut 40 -I 90 -i 25 --me tesa --merange 16 --sar 1:1 --threads 3 -r 6 --nr 0 -f -3:0 -b 16 --direct "auto" --bime --b-bias 0 --b-pyramid -w --deadzone-inter 6 --deadzone-intra 6 --aq-mode 0 --chroma-qp-offset 0 --direct-8x8 1 -B 1500 --qpmin 10 --qpmax 51 --qpstep 4 --qcomp 0.600000 --ipratio 1.400000 --pbratio 1.300000 --8x8dct -A p8x8,p4x4,b8x8,i8x8,i4x4 -m 7 --b-rdo --ratetol 1.000000 --vbv-init 0.9 --vbv-bufsize 0 --vbv-maxrate 0

[Rodger]

MeGui´s current release, Jarods 826, was okay doing the same job. :confused:
Nobody else experiencing the same? I´ll have a second look on that.


--bitrate 4000 --level 4.1 --keyint 25 --min-keyint 2 --ref 2 --mixed-refs --bframes 2 --bime --weightb --nf --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --ipratio 1.1 --pbratio 1.1 --vbv-bufsize 24000 --vbv-maxrate 32000 --qcomp 0.5 --merange 12 --threads auto --thread-input --progress --no-psnr --no-ssim --output "output" "input" --mvrange 511 --aud --nal-hrd

[Inventive Software]

I can´t sugguest this release as it totally sucks doing an encode 1280*720 at 4Mbit! Total blockyness! everything washed out.
Just my 2 cents.

Post a command line before posting such a damning verdict. ;)

[chriszxl]

Post a command line before posting such a damning verdict. ;-)

DDDamnin' right! posting the command line 1st. then we can find out the problem

[lexor]

DDDamnin' right! posting the command line 1st. then we can find out the problem

you realize that you both asked him for the line at least half an hour after he posted it? where you writing your post for all that time?

[Inventive Software]

Pedanticism aside lexor (we have other lives too, we're not on here 24/7, so quit bugging when we ask something a bit "late" ;)), those are quite conservative settings. 2 Refs and 2 B-frames for 4 Mbits? If it's very fast motion, 4 Mbits won't be enough, so either increase the bitrate, or increase the Refs and B-frames. 8 for each would be a could number.

[lexor]

Pedanticism aside lexor (we have other lives too, we're not on here 24/7, so quit bugging when we ask something a bit "late" ;))

Dunno about pedantic, but I'm pretty sure that your argument that you don't have time to read posts after you asked him to post more is a logical fallacy :) and now you have 2 posts instead of 1 you would otherwise make, doesn't fit the time saving mantra either.

Also I don't see the problem with b-frames and refs that you mentioned. At most he can raise each by 1 to maintain CE compatibility (which by the looks of the other settings is probably the reason it's so low to begin with). That won't give him enough, not to mention that 3,3 for those 2 works wonders on every DVD5 HD backup I've done (and Italian Job for one has some fast motion with blur and wacky colours to boot). I doubt +1 to both will save the picture from being a horrid mess.

Rodger, do other movies playback fine? i.e. do you know the decoder isn't the issue, like deblocking being skipped maybe?

[Rodger]

So here is my final "judgement".

TO ME this release tends more to blockyness than the "current" release for Megui.

This monster blockyness I got out of that new release that one time must have been a bad encode or something...I don´t have that source anymore, so I can´t rebuild the error.

But to repeat myself...I´d say the new version just tends more to blockyness than the old one.

Try yourself...If it´s just me....than everything has to be fine.
I just wanted to share my thoughts with you.

Infos: Same settings used as above. The "effect" does come to get noticed more on green grass like gardens.

[MythCreator]

Just for more test

x264.839.modified.experimental.1.exe (http://stashbox.org/109018/x264.839.modification.experimental.1.exe)

contains the above patches:
x264.gaussian.cplxblur.01.diff
x264_me-prepass_DeathTheSheep.01.diff
x264_2pass_vbv.7.diff
x264_hrd_pulldown.04_interlace.diff
x264_fix_win_stdin.diff



And then:
x264.839.modified.experimental.2.exe (http://stashbox.org/109020/x264.839.modified.experimental.2.exe)

Contains these:
x264.gaussian.cplxblur.01.diff
x264_me-prepass_DeathTheSheep.01.diff
x264_2pass_vbv.7.diff
x264_hrd_pulldown.04_interlace.diff
x264_fix_win_stdin.diff
x264_fgo.01.826.diff
32x32samples_crash.diff
cosmetic.diff
debug-defines.diff
fix_stats_file_work_for_cli.diff
frames_memoryleak.diff
multithreading_Nth_pass_ratecontrol.diff




both are make fprofiled by GCC 4.4.0 20080331 experimental

[chriszxl]

Just for more test

x264.839.modified.experimental.1.exe (http://stashbox.org/109018/x264.839.modification.experimental.1.exe)

contains the above patches:
x264.gaussian.cplxblur.01.diff
x264_me-prepass_DeathTheSheep.01.diff
x264_2pass_vbv.7.diff
x264_hrd_pulldown.04_interlace.diff
x264_fix_win_stdin.diff



And then:
x264.839.modified.experimental.2.exe (http://stashbox.org/109020/x264.839.modified.experimental.2.exe)

Contains these:
x264.gaussian.cplxblur.01.diff
x264_me-prepass_DeathTheSheep.01.diff
x264_2pass_vbv.7.diff
x264_hrd_pulldown.04_interlace.diff
x264_fix_win_stdin.diff
x264_fgo.01.826.diff
32x32samples_crash.diff
cosmetic.diff
debug-defines.diff
fix_stats_file_work_for_cli.diff
frames_memoryleak.diff
multithreading_Nth_pass_ratecontrol.diff




both are make fprofiled by GCC 4.4.0 20080331 experimental

WOO...nice...can not wait to try.....
But someone real shd be pay attention to the red characters before da final judgement

[Sharktooth]

bobor, any chance for a fresh modified build?

[lexor]

bobor, any chance for a fresh modified build?

fresh? x264.nl changelog matches git, and I don't see any updated patches, so what is there to build?

[Sharktooth]

oh, sorry. i missed it.

[bob0r]

bobor, any chance for a fresh modified build?

Never announced but:
x264.839.modified.exe (http://files.x264.nl/force.php?file=./x264.839.modified.exe)
=)

I was waiting for more patches, guess they will be with the next pengvado patching spree!

[jefrey]

hi boboir, have you an build of x264 64 bit edition?
i've found an old x264build on my hdd and it is for 64 bit systems but not much patched :(.

Would be very nice if you can create a 64bit build of x264:thanks:

[bob0r]

I am oldschool, nothing is 64bit here :cool:

[jefrey]

damned:(, Would you tell me(pm) how can i add some patches to the 64 build?
i Wanna see if my 32bit build is much faster that the 64bit build on my dual core2quad cpus :devil:

[IgorC]

Can anyone please make an experimental build with following patches:
1. VAQ 2.0
2. FGO
3. me prepass
...and others

Thanks.

[Sharktooth]

x264_2pass_vbv.8.diff (taken form the x264 ML)
diff --git a/encoder/encoder.c b/encoder/encoder.c
old mode 100644
new mode 100755
index a328fdf..05dcc55
--- a/encoder/encoder.c
+++ b/encoder/encoder.c
@@ -659,6 +659,7 @@ x264_t *x264_encoder_open ( x264_param_t *param )
|| h->param.rc.i_rc_method == X264_RC_CRF
|| h->param.b_bframe_adaptive
|| h->param.b_pre_scenecut );
+ h->frames.b_have_lowres |= (h->param.rc.b_stat_read && h->param.rc.i_vbv_buffer_size > 0);

h->frames.i_last_idr = - h->param.i_keyint_max;
h->frames.i_input = 0;
diff --git a/encoder/ratecontrol.c b/encoder/ratecontrol.c
old mode 100644
new mode 100755
index a0e0859..7e252fd
--- a/encoder/ratecontrol.c
+++ b/encoder/ratecontrol.c
@@ -43,6 +43,7 @@ typedef struct
int p_tex_bits;
int misc_bits;
uint64_t expected_bits;
+ double expected_vbv;
float new_qscale;
int new_qp;
int i_count;
@@ -331,7 +332,7 @@ int x264_ratecontrol_new( x264_t *h )
rc->rate_tolerance = 0.01;
}

- h->mb.b_variable_qp = (rc->b_vbv && !rc->b_2pass) || h->param.rc.i_aq_mode;
+ h->mb.b_variable_qp = rc->b_vbv || h->param.rc.i_aq_mode;

if( rc->b_abr )
{
@@ -851,17 +852,25 @@ double predict_row_size( x264_t *h, int y, int qp )
return (pred_s + pred_t) / 2;
}

-double predict_row_size_sum( x264_t *h, int y, int qp )
+double row_bits_so_far( x264_t *h, int y )
{
int i;
double bits = 0;
for( i = 0; i <= y; i++ )
bits += h->fdec->i_row_bits[i];
+ return bits;
+}
+
+double predict_row_size_sum( x264_t *h, int y, int qp )
+{
+ int i;
+ double bits = row_bits_so_far(h, y);
for( i = y+1; i < h->sps->i_mb_height; i++ )
bits += predict_row_size( h, i, qp );
return bits;
}

+
void x264_ratecontrol_mb( x264_t *h, int bits )
{
x264_ratecontrol_t *rc = h->rc;
@@ -873,7 +882,7 @@ void x264_ratecontrol_mb( x264_t *h, int bits )
rc->qpa_rc += rc->qpm;
rc->qpa_aq += h->mb.i_qp;

- if( h->mb.i_mb_x != h->sps->i_mb_width - 1 || !rc->b_vbv || rc->b_2pass )
+ if( h->mb.i_mb_x != h->sps->i_mb_width - 1 || !rc->b_vbv)
return;

h->fdec->i_row_qp[y] = rc->qpm;
@@ -883,9 +892,8 @@ void x264_ratecontrol_mb( x264_t *h, int bits )
/* B-frames shouldn't use lower QP than their reference frames */
if( y < h->sps->i_mb_height-1 )
{
- rc->qpm = X264_MAX( rc->qp,
- X264_MIN( h->fref0[0]->i_row_qp[y+1],
- h->fref1[0]->i_row_qp[y+1] ));
+ int avg_qp = (h->fref0[0]->i_row_qp[y+1]+h->fref1[0]->i_row_qp[y+1])*0.5+rc->pb_offset * ((h->fenc->i_type == X264_TYPE_BREF) ? 0.5 : 1);
+ rc->qpm = X264_MIN(X264_MAX( rc->qp, avg_qp), 51); //avg_qp could go higher than 51 due to pb_offset
}
}
else
@@ -901,20 +909,42 @@ void x264_ratecontrol_mb( x264_t *h, int bits )
int i_qp_max = X264_MIN( prev_row_qp + h->param.rc.i_qp_step, h->param.rc.i_qp_max );
int i_qp_min = X264_MAX( prev_row_qp - h->param.rc.i_qp_step, h->param.rc.i_qp_min );
float buffer_left_planned = rc->buffer_fill - rc->frame_size_planned;
+ float rc_tol = 1;
+ float headroom = 0;
+
+ /* Don't modify the row QPs until a sufficent amount of the bits of the frame have been processed, in case a flat */
+ /* area at the top of the frame was measured inaccurately. */
+ if(row_bits_so_far(h,y) < 0.05 * rc->frame_size_planned)
+ {
+ return;
+ }
+
+ headroom = buffer_left_planned/rc->buffer_size;
+ if(h->sh.i_type != SLICE_TYPE_I)
+ headroom /= 2;
+ rc_tol += headroom;

if( !rc->b_vbv_min_rate )
i_qp_min = X264_MAX( i_qp_min, h->sh.i_qp );

while( rc->qpm < i_qp_max
- && (b1 > rc->frame_size_planned * 1.15
+ && (b1 > rc->frame_size_planned * rc_tol
|| (rc->buffer_fill - b1 < buffer_left_planned * 0.5)))
{
rc->qpm ++;
b1 = predict_row_size_sum( h, y, rc->qpm );
}

+ /* avoid VBV underflow */
+ while( (rc->qpm < h->param.rc.i_qp_max)
+ && (rc->buffer_fill - b1 < rc->buffer_size * 0.005))
+ {
+ rc->qpm ++;
+ b1 = predict_row_size_sum( h, y, rc->qpm );
+ }
+
while( rc->qpm > i_qp_min
- && buffer_left_planned > rc->buffer_size * 0.4
+ && ((buffer_left_planned > rc->buffer_size * 0.4) || rc->qpm > h->fdec->i_row_qp[0])
&& ((b1 < rc->frame_size_planned * 0.8 && rc->qpm <= prev_row_qp)
|| b1 < (rc->buffer_fill - rc->buffer_size + rc->buffer_rate) * 1.1) )
{
@@ -1249,7 +1279,7 @@ static void update_vbv( x264_t *h, int bits )
return;

rct->buffer_fill_final += rct->buffer_rate - bits;
- if( rct->buffer_fill_final < 0 && !rct->b_2pass )
+ if( rct->buffer_fill_final < 0 )
x264_log( h, X264_LOG_WARNING, "VBV underflow (%.0f bits)\n", rct->buffer_fill_final );
rct->buffer_fill_final = x264_clip3f( rct->buffer_fill_final, 0, rct->buffer_size );
}
@@ -1425,6 +1455,23 @@ static float rate_estimate_qscale( x264_t *h )
double w = x264_clip3f( time*100, 0.0, 1.0 );
q *= pow( (double)total_bits / rcc->expected_bits_sum, w );
}
+ if( rcc->b_vbv )
+ {
+ double expected_size = qscale2bits(&rce, q);
+ double expected_vbv = rcc->buffer_fill + rcc->buffer_rate - expected_size;
+ if( (expected_vbv < rcc->buffer_size*.4) && (expected_vbv < rce.expected_vbv) )
+ {
+ double qmax = (expected_vbv < rcc->buffer_size*.15) ? lmax : q*1.5;
+ double size_constraint = 1 + rce.expected_vbv/rcc->buffer_size;
+ while( (expected_vbv < rce.expected_vbv/size_constraint) && (q < qmax) )
+ {
+ q *= 1.05;
+ expected_size = qscale2bits(&rce, q);
+ expected_vbv = rcc->buffer_fill + rcc->buffer_rate - expected_size;
+ }
+ }
+ rcc->last_satd = x264_rc_analyse_slice( h );
+ }
q = x264_clip3f( q, lmin, lmax );
}
else /* 1pass ABR */
@@ -1509,10 +1556,13 @@ static float rate_estimate_qscale( x264_t *h )
rcc->last_qscale_for[pict_type] =
rcc->last_qscale = q;

- if( !rcc->b_2pass && h->fenc->i_frame == 0 )
+ if( !(rcc->b_2pass && !rcc->b_vbv) && h->fenc->i_frame == 0 )
rcc->last_qscale_for[SLICE_TYPE_P] = q;

- rcc->frame_size_planned = predict_size( &rcc->pred[h->sh.i_type], q, rcc->last_satd );
+ if( rcc->b_2pass && rcc->b_vbv)
+ rcc->frame_size_planned = qscale2bits(&rce, q);
+ else
+ rcc->frame_size_planned = predict_size( &rcc->pred[h->sh.i_type], q, rcc->last_satd );
return q;
}
}
@@ -1555,6 +1605,133 @@ void x264_thread_sync_ratecontrol( x264_t *cur, x264_t *prev, x264_t *next )
/* the rest of the variables are either constant or thread-local */
}

+static int find_underflow( x264_t *h, double *fills, int *t0, int *t1, int over )
+{
+ /* find an interval ending on an overflow or underflow (depending on whether
+ * we're adding or removing bits), and starting on the earliest frame that
+ * can influence the buffer fill of that end frame. */
+ x264_ratecontrol_t *rcc = h->rc;
+ const double buffer_min = (over ? .1 : .1) * rcc->buffer_size;
+ const double buffer_max = .9 * rcc->buffer_size;
+ double fill = fills[*t0-1];
+ double parity = over ? 1. : -1.;
+ int i, start=-1, end=-1;
+ for(i=*t0; i<rcc->num_entries; i++)
+ {
+ fill += (rcc->buffer_rate - qscale2bits(&rcc->entry[i], rcc->entry[i].new_qscale)) * parity;
+ fill = x264_clip3f(fill, 0, rcc->buffer_size);
+ fills[i] = fill;
+ if(fill <= buffer_min || i == 0)
+ {
+ if(end >= 0)
+ break;
+ start = i;
+ }
+ else if(fill >= buffer_max && start >= 0)
+ end = i;
+ }
+ *t0 = start;
+ *t1 = end;
+ return start>=0 && end>=0;
+}
+
+static int fix_underflow( x264_t *h, int t0, int t1, double adjustment, double qscale_min, double qscale_max)
+{
+ x264_ratecontrol_t *rcc = h->rc;
+ double qscale_orig, qscale_new;
+ int i;
+ int adjusted = 0;
+ if(t0 > 0)
+ t0++;
+ for(i=t0; i<=t1; i++) {
+ qscale_orig = rcc->entry[i].new_qscale;
+ qscale_new = qscale_orig * adjustment;
+ qscale_new = x264_clip3f(qscale_new, qscale_min, qscale_max);
+ rcc->entry[i].new_qscale = qscale_new;
+ adjusted = adjusted || (qscale_new != qscale_orig);
+ }
+ return adjusted;
+}
+
+static double count_expected_bits( x264_t *h )
+{
+ x264_ratecontrol_t *rcc = h->rc;
+ double expected_bits = 0;
+ int i;
+ for(i=0; i<rcc->num_entries; i++)
+ {
+ ratecontrol_entry_t *rce = &rcc->entry[i];
+ rce->expected_bits = expected_bits;
+ expected_bits += qscale2bits(rce, rce->new_qscale);
+ }
+ return expected_bits;
+}
+
+static void vbv_pass2( x264_t *h )
+{
+ /* foreach interval of buffer_full .. underflow
+ * uniformly increase the qp of all frames in the interval until either
+ * buffer is full at some intermediate frame
+ * or the last frame in the interval no longer underflows
+ * recompute intervals and repeat
+ * then do the converse to put bits back into overflow areas until target size is met */
+
+ x264_ratecontrol_t *rcc = h->rc;
+ double *fills = x264_malloc((rcc->num_entries+1)*sizeof(double));
+ double all_available_bits = h->param.rc.i_bitrate * 1000. * rcc->num_entries / rcc->fps;
+ double expected_bits = 0;
+ double adjustment;
+ double prev_bits = 0;
+ int i, t0, t1;
+ double qscale_min = qp2qscale(h->param.rc.i_qp_min);
+ double qscale_max = qp2qscale(h->param.rc.i_qp_max);
+ int iterations = 0;
+ int adj_min, adj_max;
+
+ fills++;
+
+ //adjust overall stream size
+ do {
+ iterations++;
+ prev_bits = expected_bits;
+
+ if (expected_bits != 0) { //not first iteration
+ adjustment = X264_MAX(X264_MIN(expected_bits / all_available_bits, 0.999), 0.9);
+ fills[-1] = rcc->buffer_size * h->param.rc.f_vbv_buffer_init;
+ t0 = 0;
+ //fix overflows
+ adj_min = 1;
+ while(adj_min && find_underflow(h, fills, &t0, &t1, 1))
+ {
+ adj_min = fix_underflow(h, t0, t1, adjustment, qscale_min, qscale_max);
+ t0 = t1;
+ }
+ }
+
+ fills[-1] = rcc->buffer_size * (1. - h->param.rc.f_vbv_buffer_init);
+ t0 = 0;
+ //fix underflows - should be done after overflow, as we'd better undersize target than underflowing VBV
+ adj_max = 1;
+ while(adj_max && find_underflow(h, fills, &t0, &t1, 0))
+ {
+ adj_max = fix_underflow(h, t0, t1, 1.001, qscale_min, qscale_max);
+ }
+
+ expected_bits = count_expected_bits(h);
+ } while(expected_bits < .995*all_available_bits && expected_bits > prev_bits);
+
+ if (!adj_max)
+ x264_log( h, X264_LOG_WARNING, "vbv-maxrate issue, qpmax or vbv-maxrate too low\n");
+
+ //store expected vbv filling values for tracking when encoding
+ for(i=0; i<rcc->num_entries; i++)
+ rcc->entry[i].expected_vbv = rcc->buffer_size - fills[i];
+
+// x264_log( h, X264_LOG_INFO, "VBV RC initial iterations: %d \n", iterations);
+
+ x264_free(fills-1);
+}
+
static int init_pass2( x264_t *h )
{
x264_ratecontrol_t *rcc = h->rc;
@@ -1643,7 +1820,6 @@ static int init_pass2( x264_t *h )
rcc->last_non_b_pict_type = -1;
rcc->last_accum_p_norm = 1;
rcc->accum_p_norm = 0;
- rcc->buffer_fill = rcc->buffer_size * h->param.rc.f_vbv_buffer_init;

/* find qscale */
for(i=0; i<rcc->num_entries; i++){
@@ -1680,18 +1856,11 @@ static int init_pass2( x264_t *h )
/* find expected bits */
for(i=0; i<rcc->num_entries; i++){
ratecontrol_entry_t *rce = &rcc->entry[i];
- double bits;
rce->new_qscale = clip_qscale(h, rce->pict_type, blurred_qscale[i]);
assert(rce->new_qscale >= 0);
- bits = qscale2bits(rce, rce->new_qscale);
-
- rce->expected_bits = expected_bits;
- expected_bits += bits;
- update_vbv(h, bits);
- rcc->buffer_fill = rcc->buffer_fill_final;
+ expected_bits += qscale2bits(rce, rce->new_qscale);
}

-//printf("expected:%llu available:%llu factor:%lf avgQ:%lf\n", (uint64_t)expected_bits, all_available_bits, rate_factor);
if(expected_bits > all_available_bits) rate_factor -= step;
}

@@ -1699,6 +1868,10 @@ static int init_pass2( x264_t *h )
if(filter_size > 1)
x264_free(blurred_qscale);

+ if(rcc->b_vbv)
+ vbv_pass2(h);
+ expected_bits = count_expected_bits(h);
+
if(fabs(expected_bits/all_available_bits - 1.0) > 0.01)
{
double avgq = 0;
@@ -1706,7 +1879,8 @@ static int init_pass2( x264_t *h )
avgq += rcc->entry[i].new_qscale;
avgq = qscale2qp(avgq / rcc->num_entries);

- x264_log(h, X264_LOG_WARNING, "Error: 2pass curve failed to converge\n");
+ if ((expected_bits > all_available_bits) || (!rcc->b_vbv))
+ x264_log(h, X264_LOG_WARNING, "Error: 2pass curve failed to converge\n");
x264_log(h, X264_LOG_WARNING, "target: %.2f kbit/s, expected: %.2f kbit/s, avg QP: %.4f\n",
(float)h->param.rc.i_bitrate,
expected_bits * rcc->fps / (rcc->num_entries * 1000.),
@@ -1725,7 +1899,7 @@ static int init_pass2( x264_t *h )
else
x264_log(h, X264_LOG_WARNING, "try increasing target bitrate\n");
}
- else
+ else if(!(rcc->b_2pass && rcc->b_vbv))
x264_log(h, X264_LOG_WARNING, "internal error\n");
}

[Mr VacBob]

Noboru Asai has 6 patches that fix RD decisions here:
http://article.gmane.org/gmane.comp.video.x264.devel/3503/match=
http://article.gmane.org/gmane.comp.video.x264.devel/3608/match=

Nobody ever said if they were correct or not.

[Dark Shikari]

Apparently pengvado is too "lazy" to apply them.

I'm serious. :rolleyes:

[Sharktooth]

do it for him then...

[bob0r]

*Jarod votes Dark Shikari for GIT president!

[Dark Shikari]

do it for him then...It would help if I had commit access ;)

[burfadel]

How about a build with these corrections, so we can test them? :)

[Dark Shikari]

How about a build with these corrections, so we can test them? :)AFAIK Gabriel has already tested them.

[bob0r]

x264.845.modified.exe (http://files.x264.nl/x264.845.modified.exe)

General thread:
http://forum.doom9.org/showthread.php?t=130364

x264_fgo.2.diff (made compilable for 826)
http://forum.doom9.org/showthread.php?t=137117
x264.gaussian.cplxblur.01.diff
Dark Shikari: - gaussian cplxblur: gives a tiny improvement in 2pass ratecontrol
x264_me-prepass_DeathTheSheep.01.diff
http://forum.doom9.org/showthread.php?p=1093523
x264_2pass_vbv.8.diff
http://thread.gmane.org/gmane.comp.video.x264.devel/3093/focus=3972
x264_hrd_pulldown.04_interlace.diff
HRD and pulldown for HD compatibility, updated patch for interlacing
http://forum.doom9.org/showthread.php?p=1047919#post1047919
x264_fix_win_stdin.diff
http://mailman.videolan.org/pipermail/x264-devel/2008-March/004325.html

Link to x264 patches collected: http://files.x264.nl/x264_patches/

[burfadel]

Not sure whether this is already covered with me prepass but anyways:
I was thinking about ME, and thought of variable ME if thats possible. As an assumption, it would only be beneficial with say 5 reference frames or more. The idea is to have a forward frame pool equal to the number of reference frames. Built in to that, you'd have scenechange detection for the number of reference frames. If the scene changes in say, 2 or 3 frames then the baseline ME is used (say UMH), only because the benefits of doing otherwise is very little. If the scenechange is not detected in that range, then every say 5 reference frames do an ESA search (or even a hadamard ESA (TESA) search). If there is very little change then for the next 4 encoded frames (that is, the four frames PREceding the ESA/TESA search) hex or even dia can be used for those frames. Maybe a 'low' and a high setting, so the ME used is determined whether the setting is low or high (that is, hex or umh)! But basically, no point wasting cycles on ME if its not needed. If there is discernible motion then UMH can be used. For that 5th frame since ME has already been calculated that can be used for that frame. If reference frames is set to say 6, 7, then the TESA search could be done on these instead (if a scenechange hasn't occured) at say 8,9,10 frames a second search can be done if ref frames are set that high. In the case of 8 or 9 ref frames the first TESA search can be on frame 4 and at 10 ref frames the first tesa search on frame 5, and so on. Such that with 15 or 16 ref frames, if there were no scenechanges detected ESA/TESA search would have taken place at frames 5, 10, and 15/16, and depending on the motion detected between those data points dia, hex, or umh can be used for the in-between frames. ESA/Tesa search number 2 would be the comparison between the ESA/TESA search 1 and the frame for search 2 (8,9,10), and ESA/tesa search 3 between search 2 & the frame for search 3 (say 14,15,16). Of course, the latter would only apply if there were no scenechanges and if ref frame were set high enough for this to be the case.

Is this how --me-prepass currently works, or is it slightly different?

Additionally, I guess the tesa search at frame say 10, will determine whether reference frames from 5 to 10 would possible be beneficial, and if not then they can be skipped for ME when the encoder gets to that frame. This is a forward seeking ME, not a back seeking ME which I believe it is normally?

I guess this could be between UMH and ESA. It should give better results than UMH, but be quicker than ESA. Depending on the number of reference frames it could also be quicker than UMH depending on the source clip!

[Dark Shikari]

Is this how --me-prepass currently works, or is it slightly different?Prepass just does a hpel hex search on all predictors.

[burfadel]

Prepass just does a hpel hex search on all predictors.

Ah ok! so would my 'variable ME' idea actually work, or be beneficial speed/efficiency wise? I thought it may be particularly useful for 4 or 5 ref frames or more. If you're already using 5 or more ref frames, it seems obvious you're striving for quality/bitrate, so having the more complex search methods for these reference frames seems more important. Unfortunately it also makes it significantly slower. I thought maybe an approach like that outlined above could reduce the speed impact (potentially quite significantly depending on the source) whilst still providing high quality and efficient ME. Also If no change is noticed between the current and 5th frame TESA frame (or 10th etc, depending on ref frames etc) for large proportions of the image, wouldn't it be possible to have just a simple check on those portions for the inbetween frames, to ensure that something hasn't changed in those frames?

Now doesn't ME work currently work on changes from previous frames currently? so complex ME can't be skipped. If it works forward seeking (that is, work out ME frames ahead using a complex method), the appropriate ME method can be implied for the future frames. Now that frame that has had the complex ME implied (I used TESA as an example, but ESA or UMH could be used depending on the setting), that information from the search can still be used on it, however if it would make things more efficient in that frame to use previous frames (such as that of frames 1 to 4) as reference, those areas of the picture can be updated!

I hope that makes sense! That way, only the needed ME method is used, and the complex frames the are calculated are not wasted either as the data can be updated!

[ACrowley]

Mhhh..

Strange...i use x264 patched Builds from techouse..

When i encode with unrestricetd Level i still get DXVA with mplayerc HC latest Build and or standalone .ax !! How can it be ?

With all my older unrestricted encodes from older/other x264 Builds i get no DXVA (as it should be...) ?

Techouse x264 r845
Applied patches (current versions):

x264_2pass_vbv.7.diff

x264_fix_win_stdin.diff

x264_FGO.diff (fixed by Dark Shikari & techouse)

x264.gaussian.cplxblur.01.diff

x264_hrd_pulldown.04_interlace.diff

x264_me-prepass_DeathTheSheep.diff

--pass 2 --bitrate 10670 --stats "D:\test.stats" --ref 5 --mixed-refs --no-fast-pskip --bframes 16 --b-pyramid --b-rdo --bime --weightb --direct auto --filter -3,-3 --subme 7 --trellis 1 --partitions all --8x8dct --me umh --threads auto --thread-input --progress --no-psnr --no-ssim --output "D:\test.mp4"

Its 1920x816 with 5 Ref Frames

How can it be ? Decoder is 100% sure in DXVA Mode with MPC HC Decoder, no doubt.
Cyberlink outputs a black Picture as usual because of incompatible x264 Settings

Can somebody explian it to me ? Is there some applied Patch which makes it more DXVA Compatible or what ?

[MatMaul]

what is the resolution of your stream ?
the only thing which matter for the DXVA compatibility is the number of refs regarding the resolution wich needs to be compliant with the level 4.1

[ACrowley]

what is the resolution of your stream ?
the only thing which matter for the DXVA compatibility is the number of refs regarding the resolution wich needs to be compliant with the level 4.1

Ofcourse i know :)

Its 1920x816 / 5 ref Frames

But as i say ...in this Case Level is unrestricted "but" DXVA works.

[lexor]

Are those 6 rd patches in 845 or is pengdavo still "lazy"?

[MatMaul]

Ofcourse i know :)

Its 1920x816 / 5 ref Frames

But as i say ...in this Case Level is unrestricted "but" DXVA works.
the level is not checked by the MPC DXVA decoder, it only checks the number of refs to be compliant with the level 4.1.
according to the formula with your resolution the max number of refs is 5 so all is normal :)

EDIT : I forgot to mention that I update this part of the MPC decoder recently, now all the streams with a number of refs compliant with the level 4.1 will be read in DXVA mode.
http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc?view=rev&revision=512

[DarkZell666]

Are those 6 rd patches in 845 or is pengdavo still "lazy"?

Oh come on, let him off, he's a human not a robot (I think ... o_O ... :D).

[bob0r]

Oh come on, let him off, he's a human not a robot (I think ... o_O ... :D).

Pengvado is a Cybernetic Autonomous Robotic Organism from the Andromeda Galaxy.

[DeathTheSheep]

And what about DS's chroma optimizations referenced on his "diary"? Someone needs commit access. ;)

[Shinigami-Sama]

And what about DS's chroma optimizations referenced on his "diary"? Someone needs commit access. ;)

or a fork ;)

[Japhsoncross]

r839, r845 have broken lossless encoding, green blocks in the picture. r830 is OK.

[Dark Shikari]

Confirmed. Turning off CABAC resolves it, so it is probably this (http://git.videolan.org/?p=x264.git;a=commitdiff;h=5dae513218070a3aafc7c56b097bc7ff7ae58526) or this (http://git.videolan.org/?p=x264.git;a=commitdiff;h=45cc42cc3f5155a9bcbadaaa88c828359884c85b) that is causing the problem.

Edit: Fixed. Turned out to be a problem in the nnz patch as I expected (I overlooked DC coefficients in i16x16/8x8 chroma in lossless mode). Here (http://pastebin.com/m2362067e) is a patch to fix it and here (http://x264dev.multimedia.cx/?p=31) is a blog entry on the topic (and now its fixed in git, too) ;)

[ACrowley]

the level is not checked by the MPC DXVA decoder, it only checks the number of refs to be compliant with the level 4.1.
according to the formula with your resolution the max number of refs is 5 so all is normal :)

EDIT : I forgot to mention that I update this part of the MPC decoder recently, now all the streams with a number of refs compliant with the level 4.1 will be read in DXVA mode.
http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc?view=rev&revision=512

Ah, i didnt know that but now i understand, THX! Great work :)

But : As i say, i have dozens of older encodes, which are 1920x8xx with 5 Ref Frames Level unrestricted but DXVA will not work for them? I have to check it

[Japhsoncross]

Confirmed. Turning off CABAC resolves it, so it is probably this (http://git.videolan.org/?p=x264.git;a=commitdiff;h=5dae513218070a3aafc7c56b097bc7ff7ae58526) or this (http://git.videolan.org/?p=x264.git;a=commitdiff;h=45cc42cc3f5155a9bcbadaaa88c828359884c85b) that is causing the problem.

Edit: Fixed. Turned out to be a problem in the nnz patch as I expected (I overlooked DC coefficients in i16x16/8x8 chroma in lossless mode). Here (http://pastebin.com/m2362067e) is a patch to fix it and here (http://x264dev.multimedia.cx/?p=31) is a blog entry on the topic (and now its fixed in git, too) ;)

Thanks ;)

[bob0r]

x264.851.modified.exe (http://files.x264.nl/x264.851.modified.exe)

General thread:
http://forum.doom9.org/showthread.php?t=130364

x264_fgo.2.diff (made compilable for 826)
http://forum.doom9.org/showthread.php?t=137117
x264.gaussian.cplxblur.01.diff
Dark Shikari: - gaussian cplxblur: gives a tiny improvement in 2pass ratecontrol
x264_me-prepass_DeathTheSheep.01.diff
http://forum.doom9.org/showthread.php?p=1093523
x264_2pass_vbv.8.diff
http://thread.gmane.org/gmane.comp.video.x264.devel/3093/focus=3972
x264_hrd_pulldown.04_interlace.diff
HRD and pulldown for HD compatibility, updated patch for interlacing
http://forum.doom9.org/showthread.php?p=1047919#post1047919
x264_fix_win_stdin.diff
http://mailman.videolan.org/pipermail/x264-devel/2008-March/004325.html

Link to x264 patches collected: http://files.x264.nl/x264_patches/

[ACrowley]

Ah, i didnt know that but now i understand, THX! Great work :)

But : As i say, i have dozens of older encodes, which are 1920x8xx with 5 Ref Frames Level unrestricted but DXVA will not work for them? I have to check it

Ok ,i found it

These encodes with unrestricted Level 1920x816 ,5 Ref Frames are working in DXVA with mpc hc...allright

I can see in Avinaptic :

SPS id: 0
Profile: High@L5.1
Num ref frames: 8

But theyre encoded 100% sure with 5 Ref Frames ?!
User data: ref=5
MediaInfo shows Reference Frames 5 too.

So. my Question is, why ? What is the SPS id ?
And why it is ref Frames 8, even its surely encoded with 5 ?

The compatible unrestricted encode has SPS id Num ref Frames :5
So DXVA works with mpc hc

[Shinigami-Sama]

old encodes have a bug in motion vectors being out of range
so you're kinda screwed if they were made by those revs

[ACrowley]

old encodes have a bug in motion vectors being out of range
so you're kinda screwed if they were made by those revs

Its a newer x264 Revision..MV Range was already fixed !

[MatMaul]

I can see in Avinaptic :

SPS id: 0
Profile: High@L5.1
Num ref frames: 8

But theyre encoded 100% sure with 5 Ref Frames ?!
User data: ref=5
MediaInfo shows Reference Frames 5 too.
akupenguin changes recently the behavior of --ref to match the SPS flag, that was not the case before.
more information here :
http://forum.doom9.org/showthread.php?t=132924

[ACrowley]

akupenguin changes recently the behavior of --ref to match the SPS flag, that was not the case before.
more information here :
http://forum.doom9.org/showthread.php?t=132924

Yes, i know this Thread...but i didnt find a solution ?

Is it possible to change the Flag to match "real" Ref FRames amount ?
I mean all my encodes are encoded only with 5 Ref Frames..
So the SPS Info is wrong ,isnt it ?

[MatMaul]

no the sps info is correct, your rips can't be read with DXVA and there is no solution (except re-encode with a recent x264 build).

[DarkZell666]

no the sps info is correct, your rips can't be read with DXVA and there is no solution (except re-encode with a recent x264 build).

Maybe there aren't tools for this yet, but isn't it just possible to go through the stream and replace the SPS id values on the fly ?

[burfadel]

Is Cabrc portable to x264? I know it was talked about earlier, and it was said x264 would require a lot of code change elsewhere in the code, but isn't cabrc basically just a faster and higher precision type of cabac? Would the decoder still be able to decode it?

[Dark Shikari]

Is Cabrc portable to x264? I know it was talked about earlier, and it was said x264 would require a lot of code change elsewhere in the code, but isn't cabrc basically just a faster and higher precision type of cabac? Would the decoder still be able to decode it?Of course not, since CABRC is a different method of entropy coding; you'd have to declare it a new format.

CABRC is not inherently faster than CABAC, but the implementation commonly used is faster than the H.264 implementation of CABAC. They're really just the same thing though; range coding is an integer representation of arithmetic coding.

[akupenguin]

range coding is an integer representation of arithmetic coding.
The difference between cabac and cabrc is essentially unrelated to the difference between rangecoding and arithcoding. Because there is no difference between rangecoding and arithcoding other than notation, and that inherently disappears when you go and implement it.

[DeathTheSheep]

So here's a nice, new, completely different patch I decided to pick up. It's updated and working wonderfully with the latest x264 revision.

DTS Noborrific RD optimizations! Automatically applied when patched, active at subme 6+.
- Improves SSIM and PSNR metrics
- Lowers bitrate
- No significant speed impact
- Fix: no more compile-time warnings
- Completely separate and different from me-prepass; both patches can be simultaneously applied

Enjoy... x264_rd-optimize_DeathTheSheep.02.diff

diff --git a/encoder/analyse.c b/encoder/analyse.c
--- a/encoder/analyse.c
+++ b/encoder/analyse.c
@@ -841,3 +841,3 @@ static void x264_intra_rd_refine( x264_t
pels[3] = *(uint32_t*)(p_dst_by+3*FDEC_STRIDE);
- i_nnz = h->mb.cache.non_zero_count[x264_scan8[idx]];
+ i_nnz = array_non_zero_count( h->dct.luma4x4[idx], 15 );
}
@@ -895,3 +895,3 @@ static void x264_intra_rd_refine( x264_t
for( j=0; j<3; j++ )
- i_nnz[j] = h->mb.cache.non_zero_count[x264_scan8[4*idx+j+1]];
+ i_nnz[j] = array_non_zero( h->dct.luma8x8[4*idx+j+1] );
}
@@ -1556,4 +1556,7 @@ static void x264_mb_analyse_inter_b16x16

-static inline void x264_mb_cache_mv_p8x8( x264_t *h, x264_mb_analysis_t *a, int i )
+static inline void x264_mb_cache_mv_p8x8( x264_t *h, x264_mb_analysis_t *a, int i, int b_mvd )
{
+ DECLARE_ALIGNED_4( int16_t mvp[2] );
+ int mdx, mdy;
+
const int x = 2*(i%2);
@@ -1569,2 +1572,14 @@ static inline void x264_mb_cache_mv_p8x8
x264_macroblock_cache_mv_ptr( h, x, y+1, 2, 1, 0, a->l0.me8x4[i][1].mv );
+ if( b_mvd )
+ {
+ x264_mb_predict_mv( h, 0, i*4+0, 2, mvp );
+ mdx = a->l0.me8x4[i][0].mv[0] - mvp[0];
+ mdy = a->l0.me8x4[i][0].mv[1] - mvp[1];
+ x264_macroblock_cache_mvd( h, x, y+0, 2, 1, 0, pack16to32_mask(mdx,mdy) );
+
+ x264_mb_predict_mv( h, 0, i*4+2, 2, mvp );
+ mdx = a->l0.me8x4[i][1].mv[0] - mvp[0];
+ mdy = a->l0.me8x4[i][1].mv[1] - mvp[1];
+ x264_macroblock_cache_mvd( h, x, y+1, 2, 1, 0, pack16to32_mask(mdx,mdy) );
+ }
break;
@@ -1573,2 +1588,14 @@ static inline void x264_mb_cache_mv_p8x8
x264_macroblock_cache_mv_ptr( h, x+1, y, 1, 2, 0, a->l0.me4x8[i][1].mv );
+ if( b_mvd )
+ {
+ x264_mb_predict_mv( h, 0, i*4+0, 1, mvp );
+ mdx = a->l0.me4x8[i][0].mv[0] - mvp[0];
+ mdy = a->l0.me4x8[i][0].mv[1] - mvp[1];
+ x264_macroblock_cache_mvd( h, x+0, y, 1, 2, 0, pack16to32_mask(mdx,mdy) );
+
+ x264_mb_predict_mv( h, 0, i*4+1, 1, mvp );
+ mdx = a->l0.me4x8[i][1].mv[0] - mvp[0];
+ mdy = a->l0.me4x8[i][1].mv[1] - mvp[1];
+ x264_macroblock_cache_mvd( h, x+1, y, 1, 2, 0, pack16to32_mask(mdx,mdy) );
+ }
break;
@@ -1579,2 +1606,24 @@ static inline void x264_mb_cache_mv_p8x8
x264_macroblock_cache_mv_ptr( h, x+1, y+1, 1, 1, 0, a->l0.me4x4[i][3].mv );
+ if( b_mvd )
+ {
+ x264_mb_predict_mv( h, 0, i*4+0, 1, mvp );
+ mdx = a->l0.me4x4[i][0].mv[0] - mvp[0];
+ mdy = a->l0.me4x4[i][0].mv[1] - mvp[1];
+ x264_macroblock_cache_mvd( h, x+0, y+0, 1, 1, 0, pack16to32_mask(mdx,mdy) );
+
+ x264_mb_predict_mv( h, 0, i*4+1, 1, mvp );
+ mdx = a->l0.me4x4[i][1].mv[0] - mvp[0];
+ mdy = a->l0.me4x4[i][1].mv[1] - mvp[1];
+ x264_macroblock_cache_mvd( h, x+1, y+0, 1, 1, 0, pack16to32_mask(mdx,mdy) );
+
+ x264_mb_predict_mv( h, 0, i*4+2, 1, mvp );
+ mdx = a->l0.me4x4[i][2].mv[0] - mvp[0];
+ mdy = a->l0.me4x4[i][2].mv[1] - mvp[1];
+ x264_macroblock_cache_mvd( h, x+0, y+1, 1, 1, 0, pack16to32_mask(mdx,mdy) );
+
+ x264_mb_predict_mv( h, 0, i*4+3, 1, mvp );
+ mdx = a->l0.me4x4[i][3].mv[0] - mvp[0];
+ mdy = a->l0.me4x4[i][3].mv[1] - mvp[1];
+ x264_macroblock_cache_mvd( h, x+1, y+1, 1, 1, 0, pack16to32_mask(mdx,mdy) );
+ }
break;
@@ -1876,2 +1925,3 @@ static void x264_mb_analyse_p_rd( x264_t
h->mb.i_type = P_8x8;
+ h->mb.i_partition = D_8x8;
x264_analyse_update_cache( h, a );
@@ -1894,2 +1944,3 @@ static void x264_mb_analyse_p_rd( x264_t
h->mb.i_sub_partition[2] = h->mb.i_sub_partition[3] = D_L0_8x8;
+ x264_analyse_update_cache( h, a );
i_cost = x264_rd_cost_mb( h, a->i_lambda2 );
@@ -2169,3 +2220,3 @@ void x264_macroblock_analyse( x264_t *h
}
- x264_mb_cache_mv_p8x8( h, &analysis, i );
+ x264_mb_cache_mv_p8x8( h, &analysis, i, 0 );
}
@@ -2313,2 +2364,4 @@ void x264_macroblock_analyse( x264_t *h
{
+ h->mb.i_sub_partition[0] = h->mb.i_sub_partition[1] =
+ h->mb.i_sub_partition[2] = h->mb.i_sub_partition[3] = D_L0_8x8;
x264_macroblock_cache_ref( h, 0, 0, 4, 2, 0, analysis.l0.me16x8[0].i_ref );
@@ -2320,2 +2373,4 @@ void x264_macroblock_analyse( x264_t *h
{
+ h->mb.i_sub_partition[0] = h->mb.i_sub_partition[1] =
+ h->mb.i_sub_partition[2] = h->mb.i_sub_partition[3] = D_L0_8x8;
x264_macroblock_cache_ref( h, 0, 0, 2, 4, 0, analysis.l0.me8x16[0].i_ref );
@@ -2332,2 +2387,7 @@ void x264_macroblock_analyse( x264_t *h
x264_me_refine_qpel_rd( h, &analysis.l0.me8x8[i8x8], analysis.i_lambda2, i8x8 );
+ else
+ {
+ x264_mb_cache_mv_p8x8( h, &analysis, i8x8, 1 );
+ x264_macroblock_encode_p8x8( h, i8x8 );
+ }
}
@@ -2649,3 +2709,3 @@ static void x264_analyse_update_cache( x
for( i = 0; i < 4; i++ )
- x264_mb_cache_mv_p8x8( h, a, i );
+ x264_mb_cache_mv_p8x8( h, a, i, 0 );
break;
diff --git a/encoder/macroblock.c b/encoder/macroblock.c
--- a/encoder/macroblock.c
+++ b/encoder/macroblock.c
@@ -765,4 +765,5 @@ void x264_macroblock_encode_p8x8( x264_t
int b_decimate = h->sh.i_type == SLICE_TYPE_B || h->param.analyse.b_dct_decimate;
- int nnz8x8;
+ int nnz8x8, nnz4x4;
int ch;
+ int i4;

@@ -782,2 +783,5 @@ void x264_macroblock_encode_p8x8( x264_t

+ for( i4 = 0; i4 < 4; i4++ )
+ h->mb.cache.non_zero_count[x264_scan8[i8*4+i4]] = nnz8x8;
+
if( nnz8x8 )
@@ -790,3 +794,3 @@ void x264_macroblock_encode_p8x8( x264_t
{
- int i4;
+// int i4;
DECLARE_ALIGNED_16( int16_t dct4x4[4][4][4] );
@@ -804,5 +808,19 @@ void x264_macroblock_encode_p8x8( x264_t
nnz8x8 = 4 <= i_decimate_8x8;
+
+ for( i4 = 0; i4 < 4; i4++ )
+ {
+ nnz4x4 = ( nnz8x8 ) ? array_non_zero( dct4x4[i4] ) : 0;
+ h->mb.cache.non_zero_count[x264_scan8[i8*4+i4]] = nnz4x4;
+ }
}
else
- nnz8x8 = array_non_zero( dct4x4 );
+ {
+ nnz8x8 = 0;
+ for( i4 = 0; i4 < 4; i4++ )
+ {
+ nnz4x4 = array_non_zero( dct4x4[i4] );
+ h->mb.cache.non_zero_count[x264_scan8[i8*4+i4]] = nnz4x4;
+ nnz8x8 += nnz4x4;
+ }
+ }

@@ -827,3 +845,7 @@ void x264_macroblock_encode_p8x8( x264_t
h->zigzagf.scan_4x4( h->dct.luma4x4[16+i8+ch*4], dct4x4 );
- if( array_non_zero( dct4x4 ) )
+
+// if( array_non_zero( dct4x4 ) )
+ nnz4x4 = array_non_zero_count( h->dct.luma4x4[16+i8+ch*4], 15 );
+ h->mb.cache.non_zero_count[x264_scan8[16+i8+ch*4]] = nnz4x4;
+ if( nnz4x4 )
{

[Dark Shikari]

So in addition to just fixing up pre-pass, here's a nice patch I decided to pick up. It's based of good ol' Noboru's fine work, and also consolidated and updated and working wonderfully with the latest x264 revision.DTS, what are you doing here? You should be in #x264dev, then your patches might be committed. :p

[desta]

Something I keep forgetting to ask, hopefully asking here is okay: is me-prepass actually required in both passes of a 2 pass encode, or will just the 2nd pass suffice?

[Dark Shikari]

Something I keep forgetting to ask, hopefully asking here is okay: is me-prepass actually required in both passes of a 2 pass encode, or will just the 2nd pass suffice?Its totally useless in the first pass.

[Sagittaire]

Another patch
http://pastebin.com/f7538d8b7

Chroma encoding optimizations
http://x264dev.multimedia.cx/?p=26

[bob0r]

x264.859.modified.exe (http://files.x264.nl/x264.859.modified.exe)

General thread:
http://forum.doom9.org/showthread.php?t=130364

x264_fgo.2.diff (made compilable for 826)
http://forum.doom9.org/showthread.php?t=137117
x264.gaussian.cplxblur.01.diff
Dark Shikari: - gaussian cplxblur: gives a tiny improvement in 2pass ratecontrol
x264_me-prepass_DeathTheSheep.01.diff
http://forum.doom9.org/showthread.php?p=1093523
x264_2pass_vbv.8.diff
http://thread.gmane.org/gmane.comp.video.x264.devel/3093/focus=3972
x264_hrd_pulldown.04_interlace.diff
HRD and pulldown for HD compatibility, updated patch for interlacing
http://forum.doom9.org/showthread.php?p=1047919#post1047919
x264_fix_win_stdin.diff
http://mailman.videolan.org/pipermail/x264-devel/2008-March/004325.html

Link to x264 patches collected: http://files.x264.nl/x264_patches/

[akupenguin]

And what about DS's chroma optimizations referenced on his "diary"? Someone needs commit access.
Those were rejected (or at least postponed for further experimentation) because I failed to measure any speedup.

[SpAwN_gUy]

x264.859.modified.exe (http://files.x264.nl/x264.859.modified.exe)

Link to x264 patches collected: http://files.x264.nl/x264_patches/is it possible to share the "patched" sources with us?
'cause it was nice, when Cef made his builds he also gave us the src...
(i'm still having troubles with .git :( ...)

[bob0r]

x264.859.modified.02.exe (http://files.x264.nl/x264.859.modified.02.exe)
x264.859.modified.02.source.zip (http://files.x264.nl/x264.859.modified.02.source.zip)

x264_fgo.2.diff (made compilable for 826)
http://forum.doom9.org/showthread.php?t=137117
x264.gaussian.cplxblur.01.diff
Dark Shikari: - gaussian cplxblur: gives a tiny improvement in 2pass ratecontrol
x264_me-prepass_DeathTheSheep.01.diff
http://forum.doom9.org/showthread.php?p=1093523
x264_rd-optimze_DeathTheSheep.01.diff
http://forum.doom9.org/showthread.php?p=1139605
x264_2pass_vbv.9.diff
http://thread.gmane.org/gmane.comp.video.x264.devel/3093/focus=4039
x264_hrd_pulldown.04_interlace.diff
HRD and pulldown for HD compatibility, updated patch for interlacing
http://forum.doom9.org/showthread.php?p=1047919#post1047919
x264_fix_win_stdin.diff
http://mailman.videolan.org/pipermail/x264-devel/2008-March/004325.html

Link to x264 patches collected: http://files.x264.nl/x264_patches/

Here is the output of the compiling process.
http://files.x264.nl/x264.859.modified.02.out.txt


gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DPTW32_STATIC_LIB -DHAVE_PTHREAD -s -fomit-frame-pointer -fprofile-generate -c -o encoder/analyse.o encoder/analyse.c
encoder/analyse.c: In function `x264_mb_cache_mv_p8x8':
encoder/analyse.c:1576: warning: passing arg 5 of `x264_mb_predict_mv' from incompatible pointer type
encoder/analyse.c:1581: warning: passing arg 5 of `x264_mb_predict_mv' from incompatible pointer type
encoder/analyse.c:1592: warning: passing arg 5 of `x264_mb_predict_mv' from incompatible pointer type
encoder/analyse.c:1597: warning: passing arg 5 of `x264_mb_predict_mv' from incompatible pointer type
encoder/analyse.c:1610: warning: passing arg 5 of `x264_mb_predict_mv' from incompatible pointer type
encoder/analyse.c:1615: warning: passing arg 5 of `x264_mb_predict_mv' from incompatible pointer type
encoder/analyse.c:1620: warning: passing arg 5 of `x264_mb_predict_mv' from incompatible pointer type
encoder/analyse.c:1625: warning: passing arg 5 of `x264_mb_predict_mv' from incompatible pointer type



gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DPTW32_STATIC_LIB -DHAVE_PTHREAD -s -fomit-frame-pointer -fprofile-generate -c -o encoder/set.o encoder/set.c
encoder/set.c: In function `x264_sps_init':
encoder/set.c:215: warning: unused variable `cpbBrVclFactor'

gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DPTW32_STATIC_LIB -DHAVE_PTHREAD -s -fomit-frame-pointer -fprofile-use -c -o encoder/encoder.o encoder/encoder.c
encoder/encoder.c: In function `x264_encoder_encode':
encoder/encoder.c:1278: warning: 'cpb_removal_delay' might be used uninitialized in this function


red = x264_rd-optimze_DeathTheSheep.01.diff
darkorange = x264_hrd_pulldown.04_interlace.diff

The warnings that are not in the GIT code are highlighted with a color, and should not be there.
(The GIT warnings are there because of a bug in Windows, they prevent the usage of extended zones, example: x264 --zones 1,100,bframes=0)
The GIT warnings:

gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DPTW32_STATIC_LIB -DHAVE_PTHREAD -s -fomit-frame-pointer -fprofile-generate -c -o common/common.o common/common.c
common/common.c: In function `x264_param_parse':
common/common.c:252: warning: unused variable `saveptr'

gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DPTW32_STATIC_LIB -DHAVE_PTHREAD -s -fomit-frame-pointer -fprofile-generate -c -o encoder/ratecontrol.o encoder/ratecontrol.c
encoder/ratecontrol.c: In function `parse_zone':
encoder/ratecontrol.c:564: warning: unused variable `saveptr'
encoder/ratecontrol.c: In function `parse_zones':
encoder/ratecontrol.c:607: warning: unused variable `saveptr'

[DeathTheSheep]

bob0r: My new patch has nothing to do with me-prepass and may be applied alongside it, but certainly does not replace it. I'll look into the warnings, though I tend to ignore them when my output is consistently good...

PS: DTS, what are you doing here? You should be in #x264dev, then your patches might be committed. :p
Yeah well, IRC and my computer are, sadly, allergic to one another. :(

[bob0r]

bob0r: My new patch has nothing to do with me-prepass and may be applied alongside it, but certainly does not replace it. I'll look into the warnings, though I tend to ignore them when my output is consistently good...


Ah its a seperate patch!
What can i call it?

[DeathTheSheep]

Haha, that's your freedom. If I were you, I'd call it x264 rd optimize deaththesheep 01 or something, with all the right caps and dots and such. :)

[Dark Shikari]

Hint: the warnings are a serious problem. We changed some syntax recently so you might want to fix it, lest you have serious consequences (crashes, etc).

[DeathTheSheep]

So it doesn't directly take the ol' motion vector pointer anymore? All these bloody syntax changes! :p Now I have to go thru trac for all recent changes to x264_mb_predict_mv and find out how this pointer of ours changes its "type." Or you could just tell me if it's a quick little fix, right? :D

[edit]Wait. My GCC doesn't give any warning or error on these lines. I've also tried everything and never gotten a crash... the only change I've made since posting the patch is to align the darn array (which by the way sped the thing up quite a nice bit)...

[TheRyuu]

x264.859.modified (http://www.mediafire.com/?g4qmmbdyx94)

Care for a 3rd version of 859 modified? :p
fprofiled build with patches. Made with GCC 3.4.5.
avis input, mp4 output, and pthreads enabled.

Almost the same thing as bob0r's build just this one has BOTH the me-prepass patch and his new RD one as well (as it was meant to be).

Comes with:
x264_2pass_vbv.9.diff
x264_fgo.2.diff
x264_fix_win_stdin.diff
x264_gaussian.cplxblur.01.diff
x264_gxRC.diff <---DTS's new aligned version of the patch (no longer gives those warnings either)
x264_hrd_pulldown.04_interlace.diff
x264_me-prepass_DeathTheSheep.01.diff

[bob0r]

x264.859.modified.03 (http://www.mediafire.com/?g4qmmbdyx94)

Care for a 3rd version of 859 modified? :p
fprofiled build with patches. Made with GCC 3.4.5.
avis input, mp4 output, and pthreads enabled.

Almost the same thing as bob0r's build just this one has BOTH the me-prepass patch and his new RD one as well (as it was meant to be).

Comes with:
x264_2pass_vbv.9.diff
x264_fgo.2.diff
x264_fix_win_stdin.diff
x264_gaussian.cplxblur.01.diff
x264_gxRC.diff <---DTS's new aligned version of the patch (no longer gives those warnings either)
x264_hrd_pulldown.04_interlace.diff
x264_me-prepass_DeathTheSheep.01.diff

You can just call your own build modified, next of mine will be 03.
"x264_gxRC.diff <---DTS's new aligned version of the patch (no longer gives those warnings either)" Where to downloooooad?

Oh and i silently updated my modified .exe aswell, with BOTH patches :)

[DeathTheSheep]

bobor: silent update... :)

[MatMaul]

any chance to get this multislicing patch adapted and included in your builds ?
http://mailman.videolan.org/pipermail/x264-devel/2008-May/004497.html
Thanks !

[TheRyuu]

any chance to get this multislicing patch adapted and included in your builds ?
http://mailman.videolan.org/pipermail/x264-devel/2008-May/004497.html
Thanks !

I thought slices were deemed to be 'bad'. Which is why they were removed...
Unless we're talking about two different things.

[bob0r]

bobor: silent update... :)

Ya next build ill include your updated patch, still thinking of how to continue with this.
Probably some x264-devs patches and 3rd party patches seperated builds.

[foxyshadis]

I thought slices were deemed to be 'bad'. Which is why they were removed...
Unless we're talking about two different things.

Slicing isn't bad. Basing threading entirely on slices was bad, this patch works unrelated to the threading. Slices themselves are inefficient, but allow simpler parallel decoding, error recovery, and in the case of this patch, changing the contents of slices without affecting the other slices on the fly.

[Inventive Software]

For those bitching about multithreaded decoding and why it's not in libavcodec / ffdshow / VLC / ffmpeg, this is one way of decoding it that libavcodec has multithreaded, but an encoder (i.e x264) has not.

[chriszxl]

hey guys...Dark Shikari / DeathTheSheep / bob0r / wizboy11 , you are all expert...But it really puzzled me properly by so many diff modified version....so who can tell me Which seems better for me?? Actually I usually use it for 1500k-2000 wmv/mpeg/divx...to 500-1000K H.264...my laptop's little HD is really tooooo crowded...
who can tell me pls? x264 from x264.nl or other modified ver.... thx a loooot!!!

[Dark Shikari]

hey guys...Dark Shikari / DeathTheSheep / bob0r / wizboy11 , you are all expert...But it really puzzled me properly by so many diff modified version....so who can tell me Which seems better for me?? Actually I usually use it for 1500k-2000 wmv/mpeg/divx...to 500-1000K H.264...my laptop's little HD is really tooooo crowded...
who can tell me pls? x264 from x264.nl or other modified ver.... thx a loooot!!!Just use the ordinary x264 from x264.nl.

Anything that isn't there is pretty much experimental and if you don't know what you're doing, you should probably not touch it.

Rule 1 of x264: All good patches will eventually reach the official git repository, for certain definitions of "good" and for certain definitions of "eventually."

[bob0r]

x264.859.modified.03.exe (http://files.x264.nl/x264.859.modified.03.exe)
x264.859.modified.03.source.zip (http://files.x264.nl/x264.859.modified.03.source.zip)

x264_fgo.2.diff (made compilable for 826)
http://forum.doom9.org/showthread.php?t=137117
x264.gaussian.cplxblur.01.diff
Dark Shikari: - gaussian cplxblur: gives a tiny improvement in 2pass ratecontrol
x264_me-prepass_DeathTheSheep.01.diff
http://forum.doom9.org/showthread.php?p=1093523#post1093523
x264_rd-optimze_DeathTheSheep.02.diff
http://forum.doom9.org/showthread.php?p=1139605#post1139605
x264_2pass_vbv.9.diff
http://thread.gmane.org/gmane.comp.video.x264.devel/3093/focus=4039
x264_hrd_pulldown.04_interlace.diff
HRD and pulldown for HD compatibility, updated patch for interlacing
http://forum.doom9.org/showthread.php?p=1047919#post1047919
x264_fix_win_stdin.diff
http://mailman.videolan.org/pipermail/x264-devel/2008-March/004325.html
x264.859.nr.fix.01.diff
http://forum.doom9.org/showthread.php?p=1143349#post1143349
x264.progress.indication.01.diff
http://forum.doom9.org/showthread.php?t=135905

Link to x264 patches collected: http://files.x264.nl/x264_patches/

Here is the output of the patching process:
http://files.x264.nl/x264.859.modified.03.patch.out.txt

Here is the output of the compiling process:
http://files.x264.nl/x264.859.modified.03.out.txt


gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DPTW32_STATIC_LIB -DHAVE_PTHREAD -s -fomit-frame-pointer -fprofile-generate -c -o encoder/set.o encoder/set.c
encoder/set.c: In function `x264_sps_init':
encoder/set.c:215: warning: unused variable `cpbBrVclFactor'

gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DPTW32_STATIC_LIB -DHAVE_PTHREAD -s -fomit-frame-pointer -fprofile-use -c -o encoder/encoder.o encoder/encoder.c
encoder/encoder.c: In function `x264_encoder_encode':
encoder/encoder.c:1278: warning: 'cpb_removal_delay' might be used uninitialized in this function


darkorange = x264_hrd_pulldown.04_interlace.diff

The warnings that are not in the GIT code are highlighted with a color, and should not be there.
(The GIT warnings are there because of a bug in Windows, they prevent the usage of extended zones, example: x264 --zones 1,100,bframes=0)
The GIT warnings:

gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DPTW32_STATIC_LIB -DHAVE_PTHREAD -s -fomit-frame-pointer -fprofile-generate -c -o common/common.o common/common.c
common/common.c: In function `x264_param_parse':
common/common.c:252: warning: unused variable `saveptr'

gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DPTW32_STATIC_LIB -DHAVE_PTHREAD -s -fomit-frame-pointer -fprofile-generate -c -o encoder/ratecontrol.o encoder/ratecontrol.c
encoder/ratecontrol.c: In function `parse_zone':
encoder/ratecontrol.c:564: warning: unused variable `saveptr'
encoder/ratecontrol.c: In function `parse_zones':
encoder/ratecontrol.c:607: warning: unused variable `saveptr'

[Inventive Software]

Have been waiting for this for a lil while, as I've been unimpressed with interlaced grain retention at CRF 18 with the vanilla build. Hopefully FGO will improve this. (Yes I was using AQ.)

[DeathTheSheep]

bob0r: me-prepass and rd-optimize are still 2 separate patches... all I did was update one of them and solve the compile-time warnings. :)

[bob0r]

bob0r: me-prepass and rd-optimize are still 2 separate patches... all I did was update one of them and solve the compile-time warnings. :)

Ah yes, i did indeed apply them seperately, let me update the post.

[chriszxl]

Just use the ordinary x264 from x264.nl.

Anything that isn't there is pretty much experimental and if you don't know what you're doing, you should probably not touch it.

Rule 1 of x264: All good patches will eventually reach the official git repository, for certain definitions of "good" and for certain definitions of "eventually."

thx a lot!you hv explained the very clearly,I got it.

[survivant001]

@bob0r

can you make a build for AMD64 ? I saw few post talking about x64, but I don't know if there were talking about the OS or a x264 build.

[ToS_Maverick]

currently x264 only supports x64 on linux

x64 on windows is not available atm

[MythCreator]

Is there any chance to make x264 to support SSE4, SSE4a, and SSE5?

[Dark Shikari]

Is there any chance to make x264 to support SSE4, SSE4a, and SSE5?Ther'es nothing useful in SSE4a. SSE4 might be useful for slightly improving the current sequential elimination algorithm (ESA/SEA), though I'm not sure how much it'll help in practice. SSE5 optimization is impossible since no chip is available to the public with such an instruction set yet.

[burfadel]

Isn't there still a few optimisations to be made in regards to SSE2/SSE3/SSSE3 etc? I know they won't give massive increase, just curious!

[Dark Shikari]

Isn't there still a few optimisations to be made in regards to SSE2/SSE3/SSSE3 etc? I know they won't give massive increase, just curious!I can't think of any obvious current MMX functions that haven't been SSE'd (of the ones which are practical to). Well, except chroma MC, which has an SSSE3 version in libavcodec that Akupenguin really doesn't feel like porting to nasm syntax.

[TheRyuu]

See https://forum.doom9.org/showthread.php?p=1144364#post1144364

[gav1577]

Ok guys please could someone explain as simple as possible what rdo optimize does an how does it benefit fgo ? Thanks

[TheRyuu]

Ok guys please could someone explain as simple as possible what rdo optimize does an how does it benefit fgo ? Thanks

See http://forum.doom9.org/showthread.php?t=138293

[gav1577]

See https://forum.doom9.org/showthread.php?t=138293

Thanks wizboy11 :)

[survivant001]

This build also doesn't have the hrd pulldown (does anyone even use that?)


It's not the patch to make it works on the PS3 ?

[tymoxa]

It's not the patch to make it works on the PS3 ?
Not only PS3. This patch allows х264-encoded videos to be reproduced on standalone blu-ray players.
Hrd-pulldown patch is really needed.

[Atak_Snajpera]

I think that hrd is automatically added during muxing in TSmuxer

[TheRyuu]

Because people like to complain:
x264.859.modified.tenbillion (http://www.mediafire.com/?tnbsyoqejoc) (how many 859 builds do we have now???) :p

Patches:
hrd pulldown
fix win stdin
meprepass
gxRC
x264_progress
nr fix
gaussian cplxblur
2pass vbv
new RDO

Enjoy

[gav1577]

Hi there i have been searching trying to find out what the 2pass vbv patch does but cant seem to find out much about it please could someone explain what this patch does the benefits and usage please thanks

[LoRd_MuldeR]

Hi there i have been searching trying to find out what the 2pass vbv patch does but cant seem to find out much about it please could someone explain what this patch does the benefits and usage please thanks


From the changelog:

commit 7331ea4e381898421a1a908ed57f73126faacd36
Author: Gabriel Bouvigne <gabriel.bouvigne@joost.com>
Date: Mon Jun 2 12:53:01 2008 -0600

2-pass VBV support and improved VBV handling
Dramatically improves 1-pass VBV ratecontrol (especially CBR) and provides support for VBV in 2-pass mode. This consists of a series of functions that attempts to find overflows and underflows in the VBV from the first-pass statsfile and fix them before encoding.
1-pass VBV code partially by Dark Shikari.

[gav1577]

Thanks LoRd_MuldeR much appreciated but one thing i am unclear of is there cmd switch or is the patch automatically activated ?

[Atak_Snajpera]

Because people like to complain:
x264.859.modified.tenbillion (how many 859 builds do we have now???)

Patches:
hrd pulldown
fix win stdin
meprepass
gxRC
x264_progress
nr fix
gaussian cplxblur
2pass vbv
new RDO

Enjoy

wizboy11 could you compile with latest psy patch 0.22?

[TheRyuu]

wizboy11 could you compile with latest psy patch 0.22?

I was already on it before you asked >_>

------------------------------------------

x264.861.modified.exe (http://www.mediafire.com/?gknvsmldmy0)
(Alt Download Site (http://www.zshare.net/download/13006439902b0087/))

Patches:
x264_progress.diff
x264.gaussian.cplxblur.01.diff
x264_hrd_pulldown.04_interlace.diff
x264_fix_win_stdin.diff
x264_me-prepass_DeathTheSheep.01.diff
x264_psyRDO_02.diff
gxRC.diff <---DTS 02 patch but aligned

avis input, mp4 output, pthreads activated upon configure. (statically linked pthreads)
Built with GCC 3.4.5, fprofiled.

Couple notes:
vbv has been integrated into git as well as the nr threads fix.

New option : --rdcmp
Usage:
--rdcmp psy (psy rdo)
--rdcmp ssd (regular)
Psy RDO is on by default. at subme levels 6 and 7. 7 + b-rdo is best.
Read psyRDO thread for more info regarding it.

me-prepass:
activated with --me-prepass
off by default

gxRC:
Activated at subme levels 6 and 7.

[Atak_Snajpera]

Thanks!

[survivant001]

Couple notes:
vbv has been integrated into git as well as the nr threads fix.


that's mean that we wont' see vbv_0x.. patch anymore because they are in the common branch right ?

just to know because I'm only using 2 passes.

[TheRyuu]

that's mean that we wont' see vbv_0x.. patch anymore because they are in the common branch right ?

just to know because I'm only using 2 passes.

The patch has been integrated into the git so you won't see the patch in the list anymore because it's already there :p

[gav1577]

Nice 1 wizboy11 :thanks:

[TheRyuu]

x264.869.modified.exe (http://www.mediafire.com/?xb4ittdi0nz)
(alt DL link (http://www.zshare.net/download/130689194e58f8bb/))

x264 Rev. 869 Modified Patch Build
Avis Input, mp4 output, pthreads config.

Built with GCC 3.4.5, make fprofiled, and statically linked pthreads. (means no pthreads.dll required in x264 directory)

Patches:
x264_gxRC.diff
x264.gaussian.cplxblur.01.diff
x264_hrd_pulldown.04_interlace.diff
x264_me-prepass_DeathTheSheep.01.diff
x264_progress.diff
x264_psyRDO_0.22.diff

The x264_fix_win_stdin.diff patch has been committed into the git so that has been left out.

Notes:
See the psyRDO thread (http://forum.doom9.org/showthread.php?t=138293) on usage of it although I briefly explained it in an above post.
Option: --rdcmp
Usage:
--rdcmp psy (psy rdo)
--rdcmp ssd (regular)
Psy RDO is on by default. at subme levels 6 and 7. 7 + b-rdo is best.
Read psyRDO thread for more info regarding it.

me-prepass:
Use --me-prepass flag to activate, off by default
Runs a half-pel search at a slight speed cost to improve quality with any --me mode.

x264_gxRC.diff:
Activated at subme levels 6 and 7, basically increases quality at little to no speed reduction.

x264_progress.diff:
Adds a little progress thingy at the top of the x264 window. Neat feature.

[bokonon]

Thanks wizboy11

x264.869.modified.exe (http://www.mediafire.com/?xb4ittdi0nz)
(alt DL link (http://www.zshare.net/download/130689194e58f8bb/))

x264_gxRC.diff:
Activated at subme levels 6 and 7, basically increases quality at little to no speed reduction.

I've done a search for this and i get no results other than your posts in this thread. What does it really do/where can i read more?

[TheRyuu]

Thanks wizboy11

I've done a search for this and i get no results other than your posts in this thread. What does it really do/where can i read more?

gxRC actually isn't worth it after talking with some x264 devs. The speed/quality tradeoff just isn't worth it.

So it will be removed from later builds. It's in this thread, just look back if you want to learn a little about it I think.

[TheRyuu]

New build, basically just changing the patches (using less).

x264.869.modified.02.exe (http://www.mediafire.com/?svdk4z9vmz3)

Patches:
x264_progress.diff
x264.gaussian.cplxblur.01.diff
x264_hrd_pulldown.04_interlace.diff
x264_me-prepass_DeathTheSheep.01.diff
x264_psyRDO_02.diff

Notes:
Removed gxRC patch because there's a reason it wasn't committed into the git. (speed/quality trade off totally not worth it)

x264_me-prepass_DeathTheSheep.01.diff:
use the --me-prepass flag to activate the half pel search. Improves quality using any --me mode but isn't really worth it until you get up to --me esa.

x264.gaussian.cplxblur.01.diff:
improves 2 pass rate control

x264_psyRDO_02.diff:
see thread (http://forum.doom9.org/showthread.php?t=138293)
Option: --rdcmp
Usage:
--rdcmp psy (psy rdo)
--rdcmp ssd (regular)
Psy RDO is on by default. at subme levels 6 and 7. 7 + b-rdo is best.
Read psyRDO thread for more info regarding it.

x264_progress.diff:
Adds a little progress thingy at the top of the x264 window. Neat feature.

[gav1577]

Hi how much of a difference can --me-prepass make? basically is there a noticeable difference because it slows things down quite a bit for me and i cant see any difference with it turned on or off. is it more effective for lower bitrates ?

[Dark Shikari]

Hi how much of a difference can --me-prepass make? basically is there a noticeable difference because it slows things down quite a bit for me and i cant see any difference with it turned on or off. is it more effective for lower bitrates ?No it isn't very useful. The benefit is on par with --me umh -> esa or something like that.

[gav1577]

Thanks for the help Dark Shikari

[lexor]

//snip from git for gaussian blur patch
for(j=0; j<=cplxblur*2 && j<=i; j++){
ratecontrol_entry_t *rcj = &rcc->entry[i-j];
double gaussian_weight = weight * exp(-j*j/200.0);

Are we trusting gcc to take that double definition out of the loop? I know early 4.x's couldn't be always relied on to do that (though I encountered it with larger objects, not primitives). Even though if it stays in there performance shouldn't suffer measurably, still seems like bad form.

[Dark Shikari]

//snip from git for gaussian blur patch
for(j=0; j<=cplxblur*2 && j<=i; j++){
ratecontrol_entry_t *rcj = &rcc->entry[i-j];
double gaussian_weight = weight * exp(-j*j/200.0);

Are we trusting gcc to take that double definition out of the loop? I know early 4.x's couldn't be always relied on to do that (though I encountered it with larger objects, not primitives). Even though if it stays in there performance shouldn't suffer measurably, still seems like bad form.Its actually better for GCC to define a variable as close as possible to where its used. But it doesn't matter here; the main problem was a C99-ism in code a few lines later, and your issue as been resolved in the same patch, r871.

[MasterNobody]

Collection of patches that I use for building x264vfw (useful not only for VfW): bm_x264_patch_collection.r870.zip (http://stashbox.org/132452/bm_x264_patch_collection.r870.zip)
List of independent patches:
x264_32x32samples_crash.r870.diff
x264_cosmetic.r870.diff
x264_debug_defines.r870.diff
x264_fix_stats_file_work.r870.diff
x264_frames_memoryleak.r870.diff
x264_multithreading_Nth_pass_ratecontrol.r870.diff
x264_psy_rdo.r870.diff
x264_thread_pool.r870.diff
x264_vaq2mod.03.r870.diff

Patches that depends of others:
bm_x264_thread_pool.r870.diff depends of x264_fix_stats_file_work.r870.diff, x264_frames_memoryleak.r870.diff, x264_multithreading_Nth_pass_ratecontrol.r870.diff
bm_x264_vfw2cli.r870.diff depends of x264_fix_stats_file_work.r870.diff

All in one patches:
bm_x264_cli_VAQ2mod_PsyRDO_fixed.r870.diff
bm_x264_exp_VAQ2mod_PsyRDO_fixed.r870.diff
bm_x264_normal_fixed.r870.diff

Description of the patches here (http://mailman.videolan.org/pipermail/x264-devel/2008-January/003921.html).

CLI-version build with this patches here: x264_CLI_870bm_VAQ2mod_PsyRDO_fixed.zip (http://stashbox.org/132124/x264_CLI_870bm_VAQ2mod_PsyRDO_fixed.zip)
Build with GCC (GCC TDM-3 for MinGW) 4.3.0 and YASM 0.7.1.2093
Configuration:
Platform: X86
System: MINGW
avis input: yes
mp4 output: yes
pthread: yes
gtk: no
debug: no
gprof: no
PIC: no
shared: no
visualize: no

[Razorholt]

Thanks a lot MasterNobody!

I don't see me-prepass patch listed here. What is your opinion on this patch? Apparently it has been "fixed" but I don't know what that means since I can't test it.

[TheRyuu]

Thanks a lot MasterNobody!

I don't see me-prepass patch listed here. What is your opinion on this patch? Apparently it has been "fixed" but I don't know what that means since I can't test it.

me-prepass is only really worth it when using --me esa or higher. It's not even that useful, tesa is probably just better.

-------------------------------------------

x264.871.modified.exe (http://www.mediafire.com/?ulvxaxxz0dj)

GCC 3.4.5 make fprofiled build.

Patches:
x264_hrd_pulldown.04_interlace.diff
x264_me-prepass_DeathTheSheep.01.diff
x264_psyRDO_02.diff
x264_progress.diff

More git commits means less patches. Guassian blur was committed so that's off the list now too.

x264_me-prepass_DeathTheSheep.01.diff:
use the --me-prepass flag to activate the half pel search. Improves quality using any --me mode but isn't really worth it until you get up to --me esa. Isn't really worth it since --me tesa will provide better motion searching. But since it has a flag and it's default is off I include it.

x264_psyRDO_02.diff:
see thread
Option: --rdcmp
Usage:
--rdcmp psy (psy rdo)
--rdcmp ssd (regular)
Psy RDO is on by default. at subme levels 6 and 7. 7 + b-rdo is best.
Read psyRDO thread for more info regarding it.

x264_progress.diff:
Adds a little progress thingy at the top of the x264 window. Neat feature.

[gav1577]

Thanks wizboy11

[MasterNobody]

Thanks a lot MasterNobody!

I don't see me-prepass patch listed here. What is your opinion on this patch? Apparently it has been "fixed" but I don't know what that means since I can't test it.I don't use me-prepass patch. As for the "fixed" than it stays here to indicate that this build didn't crash with multithreading on CPUs with SSE2 (my first build of 870 crashes due to the bug in x264_thread_pool patch, which I than fix).

[IgorC]

me-prepass is only really worth it when using --me esa or higher. It's not even that useful, tesa is probably just better.


Speaking mostly of DVD resolution:
me-prepass + umh has higher metric increase and speed then tesa with or w/o merange 24. Visually I think also.
Even 3d pass has higher metric boost then tesa ( ~ 0.1 avisynth SSIM = ~ 1%. Maybe a bit less)
I know that metric isn't ideal indicator of quality but it's already very hard to see difference.
I prefer umh+prepass and maybe 3dpass. Practically the same quality and much higher speed.

Maybe tesa and merange 24 perform better on HD.
It's just my experience.

[cyberbeing]

That is pretty much what I have found as well for DVD resolution content using --me-prepass. I just did a test comparison earlier today with a crf 10 encode on a high motion scene and umh + me-prepass was 38% faster (19% slower than w/o me-prepass) and had about 0.5% lower bitrate than esa.

I also did a test with a crf 17 encode on a low motion scene and esa was 67% slower than umh + me-prepass and again the me-prepass encode had the lowest bitrate by a slight margin.

Overall, considering that the speed hit from me-prepass is so much less than esa and tesa, I don't see it as all that bad a thing if you want to push a bit of extra quality out of your encode but aren't patient enough for esa or tesa.

[burfadel]

In reference to me-prepass, does x264 normally do a hpel search on a frame, and if so are the results from the me-prepass recycled (if they can be)? I'm assuming there may be elements of the frame encoded that has had me-prepass over it that no longer require any ME, so are those elements skipped when me-prepass is enabled?

[Dark Shikari]

In reference to me-prepass, does x264 normally do a hpel search on a frame, and if so are the results from the me-prepass recycled (if they can be)? I'm assuming there may be elements of the frame encoded that has had me-prepass over it that no longer require any ME, so are those elements skipped when me-prepass is enabled?ME-prepass is just a simple ugly hack to do tons of hex searches. Its not particularly pretty or efficient.

[TheRyuu]

x264.877.modified.exe (http://www.mediafire.com/?4t4d3mzsreh)
(alt DL link (http://www.uploadjockey.com/download/9767026/x264.877.modified.exe))

Patches:
x264_hrd_pulldown.04_interlace.diff
x264_progress.diff
x264_psyRDO_0.22.diff
x264_me-prepass_updated.02.diff <---nothing more then a compatibility update to make it compatible with psyRDO patch.

Notes:
Few git commits fix up some asm coding. Also a slight speedup in trellis. See x264 GIT for more details (http://git.videolan.org/?p=x264.git;a=summary)

x264_me-prepass_updated.02.diff
use the --me-prepass flag to activate the half pel search. Improves quality using any --me mode but isn't really worth it until you get up to --me esa. Isn't really worth it since --me tesa will provide better motion searching. But since it has a flag and it's default is off I include it.

x264_psyRDO_02.diff:
see thread
Option: --rdcmp
Usage:
--rdcmp psy (psy rdo)
--rdcmp ssd (regular)
Psy RDO is on by default at subme levels 6 and 7. 7 + b-rdo is best.
Read psyRDO thread for more info regarding it.

x264_progress.diff:
Adds a little progress thingy at the top of the x264 window. Neat feature.

[techouse]

x264_x86_r877_techouse (http://techouse.project357.com/builds/x264_x86_r877_techouse.7z)

Source: x264 r877 GIT (git://git.videolan.org/x264.git)

Applied patches (current versions):

x264_hrd_pulldown.04_interlace.diff

x264_me-prepass_DeathTheSheep_techouse_fix.diff (http://pastebin.com/f62aea32f)

x264_progress.diff

x264_psy_rdo_0.22.diff


Please check http://forum.doom9.org/showthread.php?t=130364 and http://git.videolan.org/gitweb.cgi?p=x264.git;a=shortlog for more info

Compiled by techouse on June 8th 2008, 11:55:51 CEST with GCC-4.3.0 on Windows Vista Ultimate SP-1 32-bit.

Commandline used: ./configure&&make fprofiled

Platform: X86
System: MINGW
avis input: yes
mp4 output: yes
pthread: yes
gtk: no
debug: no
gprof: no
PIC: no
shared: no
visualize: no

x264_x86_r877_FGO_techouse (http://techouse.project357.com/builds/x264_x86_r877_FGO_techouse.7z)

Source: x264 r877 GIT (git://git.videolan.org/x264.git)

Applied patches (current versions):

x264_FGO_techouse_fix.diff (http://pastebin.com/f7dcb4e0f)

x264_hrd_pulldown.04_interlace.diff

x264_me-prepass_DeathTheSheep.diff

x264_progress.diff


Please check http://forum.doom9.org/showthread.php?t=130364 and http://git.videolan.org/gitweb.cgi?p=x264.git;a=shortlog for more info

Compiled by techouse on June 8th 2008, 13:21:54 CEST with GCC-4.3.0 on Windows Vista Ultimate SP-1 32-bit.

Commandline used: ./configure&&make fprofiled

Platform: X86
System: MINGW
avis input: yes
mp4 output: yes
pthread: yes
gtk: no
debug: no
gprof: no
PIC: no
shared: no
visualize: no

I built both cause some of you still prefer testing which perform better. ;)

Enjoy ;)

[MythCreator]

For my experience,Psy RDO just make more block than ssd in low and ultra low bitrate,Would Dark Shikari do some work to improve that?

[Dark Shikari]

For my experience,Psy RDO just make more block than ssd in low and ultra low bitrate,Would Dark Shikari do some work to improve that?I can't do anything unless you give me a specific example of what you're talking about. And by a specific example I mean two .h264 files, one with psy and one without, at the same bitrate.

[MythCreator]

@Dark Shikari:Well , I will do that some days later, I just del the source..
@techouse:You don't have a yasm.exe at your /MinGW/bin ? I just noticed that your build have no optimization to SSE/SSE2 and others

[techouse]

@Dark Shikari:Well , I will do that some days later, I just del the source..
@techouse:You don't have a yasm.exe at your /MinGW/bin ? I just noticed that your build have no optimization to SSE/SSE2 and others

http://git.videolan.org/?p=x264.git;a=commit;h=86c70b0fccc46752e03d3ed7fc5733dab31b5a41


many changes to which asm functions are enabled on which cpus.

with Phenom, 3dnow is no longer equivalent to "sse2 is slow", so make a new flag for that.

some sse2 functions are useful only on Core2 and Phenom, so make a "sse2 is fast" flag for that.

some ssse3 instructions didn't become useful until Penryn, so yet another flag.

disable sse2 completely on Pentium M and Core1, because it's uniformly slower than mmx.

enable some sse2 functions on Athlon64 that always were faster and we just didn't notice.

remove mc_luma_sse3, because the only cpu that has lddqu (namely Pentium 4D) doesn't have "sse2 is fast".

don't print mmx1, sse1, nor 3dnow in the detected cpuflags, since we don't really have any such functions. likewise don't print sse3 unless it's used (Pentium 4D).

And I have nasm.exe and yasm.exe in my C:\MingGW\bin folder

[MythCreator]

http://git.videolan.org/?p=x264.git;a=commit;h=86c70b0fccc46752e03d3ed7fc5733dab31b5a41



And I have nasm.exe and yasm.exe in my C:\MingGW\bin folder


Ah , sorry and thanks~

[bob0r]

x264.880.modified.01.exe (http://files.x264.nl/x264.880.modified.01.exe)
x264.880.modified.01.source.zip (http://files.x264.nl/x264.880.modified.01.source.zip)

x264.psyRDO.0.22.diff
http://forum.doom9.org/showthread.php?t=138293
x264_hrd_pulldown.04_interlace.diff
HRD and pulldown for HD compatibility, updated patch for interlacing
http://forum.doom9.org/showthread.php?p=1047919#post1047919
x264.progress.indication.01.diff
http://forum.doom9.org/showthread.php?t=135905

Link to x264 patches collected: http://files.x264.nl/x264_patches/

Here is the output of the patching process:
http://files.x264.nl/x264.880.modified.01.patch.out.txt

Here is the output of the compiling process:
http://files.x264.nl/x264.880.modified.01.fprofiled.out.txt


gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DPTW32_STATIC_LIB -DHAVE_PTHREAD -s -fomit-frame-pointer -fprofile-generate -c -o encoder/set.o encoder/set.c
encoder/set.c: In function `x264_sps_init':
encoder/set.c:215: warning: unused variable `cpbBrVclFactor'

gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DPTW32_STATIC_LIB -DHAVE_PTHREAD -s -fomit-frame-pointer -fprofile-use -c -o encoder/encoder.o encoder/encoder.c
encoder/encoder.c: In function `x264_encoder_encode':
encoder/encoder.c:1278: warning: 'cpb_removal_delay' might be used uninitialized in this function


darkorange = x264_hrd_pulldown.04_interlace.diff

The warnings that are not in the GIT code are highlighted with a color, and should not be there.
(The GIT warnings are there because of a bug in Windows, they prevent the usage of extended zones, example: x264 --zones 1,100,bframes=0)
The GIT warnings:

gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DPTW32_STATIC_LIB -DHAVE_PTHREAD -s -fomit-frame-pointer -fprofile-generate -c -o common/common.o common/common.c
common/common.c: In function `x264_param_parse':
common/common.c:252: warning: unused variable `saveptr'

gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DPTW32_STATIC_LIB -DHAVE_PTHREAD -s -fomit-frame-pointer -fprofile-generate -c -o encoder/ratecontrol.o encoder/ratecontrol.c
encoder/ratecontrol.c: In function `parse_zone':
encoder/ratecontrol.c:564: warning: unused variable `saveptr'
encoder/ratecontrol.c: In function `parse_zones':
encoder/ratecontrol.c:607: warning: unused variable `saveptr'

[TheRyuu]

x264.883.modified.exe (http://www.mediafire.com/?xzwgm1gucmv)
x264.833.modified.source.rar (http://www.mediafire.com/?me1tqou2t1x)

Patches:
x264_progress.diff
x264_hrd_pulldown.04_interlace.diff
x264_psyRDO_0.22.diff

Notes:
Removed me-prepass due to incompatibility (only really useful on esa anyway, and going to tesa would probably be more beneficial then using me-prepass)

Other then that, not much to report this week. As always, notes on additional options added through the psyRDO patch:
x264_psyRDO_02.diff:
see thread
Option: --rdcmp
Usage:
--rdcmp psy (psy rdo)
--rdcmp ssd (regular)
Psy RDO is on by default at subme levels 6 and 7. 7 + b-rdo is best.
Read psyRDO thread for more info regarding it.

[Ranguvar]

Thanks, Dragon! Been waiting for an 883 build, especially without me-prepass. Hey, is it possible for someone to make a build where this can be disabled/enabled through the CLI?

Thanks again!

[Wishbringer]

is it possible for someone to make a build where this can be disabled/enabled through the CLI?

Wasn't ME-Prepass enabled by "--me-prepass" in commandline and otherwise disabled?! :confused:

[survivant001]

Wasn't ME-Prepass enabled by "--me-prepass" in commandline and otherwise disabled?! :confused:

yep.. he is just confused.

[TheRyuu]

Thanks, Dragon! Been waiting for an 883 build, especially without me-prepass. Hey, is it possible for someone to make a build where this can be disabled/enabled through the CLI?

Thanks again!

I make notes for a reason.
Removed me-prepass due to incompatibility (only really useful on esa anyway, and going to tesa would probably be more beneficial then using me-prepass)

I believe the type of loop used in me.c was changed and is the cause for the incompatibility. However I'm not about to go and try and hack it together for something that probably a.) won't work and b.) isn't really worth the effort.

[Ranguvar]

'Apologies'... I did read the notes, I just didn't know that me-prepass was already triggered by a switch.

[TheRyuu]

x264.886.modified.exe (http://www.mediafire.com/?gdmcekznhcu)
x264.886.modified.source.rar (http://www.mediafire.com/?dmga3jzzsbc)

Patches:
x264_progress.diff
x264_hrd_pulldown.04_interlace.diff
x264_psyRDO_0.22.diff

Notes:
Nothing new other then a few git commits (speed things up slightly cause GCC is a dumb-ass at unrolling loops (and some inline stuff I don't understand), at least I think that's what the commits do :p)

As always, additional options added by the patches:
x264_psyRDO_02.diff:
see thread
Option: --rdcmp
Usage:
--rdcmp psy (psy rdo)
--rdcmp ssd (regular)
Psy RDO is on by default at subme levels 6 and 7. 7 + b-rdo is best.
Read psyRDO thread for more info regarding it.

[wyti]

Can anyone compile a patch with me-prepass ? Or the patch is actually borked ?

[Sagittaire]

Can anyone compile a patch with me-prepass ? Or the patch is actually borked ?

from the author of pre-pass ...

ME-prepass is just a simple ugly hack to do tons of hex searches. Its not particularly pretty or efficient

Use most available patch doesn't mean always better quality!

[wyti]

True but.
Dark Shikari isn't the author of pre-pass

And I ask this because I tried it, and I use it with a lot of my encodes (I usually encore small clips of 2-3 minutes) and it give me better results than --me esa.

[Sharktooth]

dark shikari IS the author... iirc death the sheep just kept it up to date.

[wyti]

Thanks for the explanation, but what about this patch itself, is it borked, or no one want to use it ?

[Dark Shikari]

Thanks for the explanation, but what about this patch itself, is it borked, or no one want to use it ?I'm too lazy to keep it updated with all the changes I've been making to me.c, I never figured out entirely why it worked at all, and people these days aren't exactly demanding more "lots of time for very little quality boost" improvements anyways.

[wyti]

Ok thanks, but i think that with the good speed boost, we can introduce some quality boost too.

if I understand, the patch isn't dead, but someone have to maintain it ?

[techouse]

A high --merange and --me esa or tesa would probably give you the same results.

[wyti]

Yes but with pre-pass i got about 1.5fps, that was not bad for a 3minutes long clip. But with esa, it is significantly slower, i don't remember the exact numbers, but around 0.8-0.9 fps, with a very slighly better result...
for me umh + prepass was very good.

Now i have to learn how to maintain me-pre-pass patch :p

[techouse]

It's quite nasty cause the problem is in the encoder/me.c section which is very SENSITIVE. Good luck.

[bob0r]

x264.886.modified.01.exe (http://files.x264.nl/x264.886.modified.01.exe)
x264.886.modified.01.source.zip (http://files.x264.nl/x264.886.modified.01.source.zip)

x264.psyRDO.0.22.diff
http://forum.doom9.org/showthread.php?t=138293
x264_hrd_pulldown.04_interlace.diff
HRD and pulldown for HD compatibility, updated patch for interlacing
http://forum.doom9.org/showthread.php?p=1047919#post1047919
x264.progress.indication.01.diff
http://forum.doom9.org/showthread.php?t=135905

Link to x264 patches collected: http://files.x264.nl/x264_patches/

Here is the output of the patching process:
http://files.x264.nl/x264.886.modified.01.patch.out.txt

Here is the output of the compiling process:
http://files.x264.nl/x264.886.modified.01.fprofiled.out.txt


gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DPTW32_STATIC_LIB -DHAVE_PTHREAD -s -fomit-frame-pointer -fprofile-generate -c -o encoder/set.o encoder/set.c
encoder/set.c: In function `x264_sps_init':
encoder/set.c:215: warning: unused variable `cpbBrVclFactor'

gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DPTW32_STATIC_LIB -DHAVE_PTHREAD -s -fomit-frame-pointer -fprofile-use -c -o encoder/encoder.o encoder/encoder.c
encoder/encoder.c: In function `x264_encoder_encode':
encoder/encoder.c:1278: warning: 'cpb_removal_delay' might be used uninitialized in this function


darkorange = x264_hrd_pulldown.04_interlace.diff

The warnings that are not in the GIT code are highlighted with a color, and should not be there.
(The GIT warnings are there because of a bug in Windows, they prevent the usage of extended zones, example: x264 --zones 1,100,bframes=0)
The GIT warnings:

gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DPTW32_STATIC_LIB -DHAVE_PTHREAD -s -fomit-frame-pointer -fprofile-generate -c -o common/common.o common/common.c
common/common.c: In function `x264_param_parse':
common/common.c:252: warning: unused variable `saveptr'

gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DPTW32_STATIC_LIB -DHAVE_PTHREAD -s -fomit-frame-pointer -fprofile-generate -c -o encoder/ratecontrol.o encoder/ratecontrol.c
encoder/ratecontrol.c: In function `parse_zone':
encoder/ratecontrol.c:564: warning: unused variable `saveptr'
encoder/ratecontrol.c: In function `parse_zones':
encoder/ratecontrol.c:607: warning: unused variable `saveptr'

[IgorC]

sorry for offtopic
A high --merange and --me esa or tesa would probably give you the same results.
Could somebody show a clear sample where --merange > 16 and --me (t)esa would be helpfull? Really.
I tested some videos and never have seen where is it so usefull (at all?).

And --me-prepass was more efficient than tesa and merange some time ago.
http://forum.doom9.org/showthread.php?p=1054774

[Sagittaire]

sorry for offtopic

Could somebody show a clear sample where --merange > 16 and --me (t)esa would be helpfull? Really.
I tested some videos and never have seen where is it so usefull (at all?).

And --me-prepass was more efficient than tesa and merange some time ago.
http://forum.doom9.org/showthread.php?p=1054774

Well I make a little test with 10 000 frame from Casino Royal (1080p24 at crf 22) and tesa + merange 32 produce something like 1% improvement (lower bitrate and higher metric).

[IgorC]

Thanks for throw some numbers. I expected practically the same.
But I think it's correct to keep insane settings (tesa, merange). This way user know the limits of encoder and there is no paranoid thoughts about if it's possible to squeeze the last .% of quality when it's necessary.

[skystrife]

x264.889.modified.exe (http://www.mediafire.com/?gymumhj1fnc) - Source (http://www.mediafire.com/?jmmucyhy9mb)
(alt download link) (http://www.sendspace.com/file/atdvmv)

Patches:
x264.psyRDO.0.22.diff
x264_hrd_pulldown.04_interlace.diff
x264.progress.indication.01.diff

gcc 3.4.5 fprofiled build

Built in mingw on Windows Vista x64.

Enjoy.

[kemuri-_9]

Hmm.... I think i developed a small patch that relaxes the qpfile to be able to only specify certain frames of the video (i believe this was mentioned as a feature request somewhere)
http://kemuri9.net/dev/x264/x264_qpfile_relax.diff
(based on r889)

if someone else can confirm this for me that would be great

Edit:
Just changed it up a little to increase efficiency on reading the qpfile for only specifying certain frames

[MythCreator]

x264.modified.r891.exe (http://www.fs2you.com/files/20b87597-4268-11dd-a40a-0014221f4662/)
Source (http://www.fs2you.com/files/ae42fa5c-4269-11dd-a410-00142218fc6e/)

General thread:
http://forum.doom9.org/showthread.php?t=130364


x264.psyRDO.0.22.diff
http://forum.doom9.org/showthread.php?t=138293
X264_progress.indication.diff
http://forum.doom9.org/showthread.php?t=135905
x264_qpfile_relax.diff.diff
http://forum.doom9.org/showthread.php?p=1151919#post1151919
x264_interlaced_signaling.r886.diff
http://mailman.videolan.org/pipermail/x264-devel/2008-June/004656.html

Link to x264 patches collected: http://files.x264.nl/x264_patches/


GCC 3.4.5 build fprofiled

[jethro]

Hmm.... I think i developed a small patch that relaxes the qpfile to be able to only specify certain frames of the video (i believe this was mentioned as a feature request somewhere)
http://kemuri9.net/dev/x264_qpfile_relax.diff
(based on r889)

if someone else can confirm this for me that would be great

Edit:
Just changed it up a little to increase efficiency on reading the qpfile for only specifying certain frames
You mean the feature request in this thread?
http://forum.doom9.org/showthread.php?t=120449

So with your patched qpfile we may e.g., force key frames at specific frames?

[kemuri-_9]

You mean the feature request in this thread?
http://forum.doom9.org/showthread.php?t=120449

Ah yes, there was that thread where I read that.

So with your patched qpfile we may e.g., force key frames at specific frames?

yes, that's how I've been testing it so far and confirming its success in the stats file.

qpfile (entire file)
99 I 35
100 I 30

stats
...
in:99 out:99 type:I q:35.00 itex:326 ptex:0 mv:308 misc:326 imb:1350 pmb:0 smb:0 d:-;
in:100 out:100 type:I q:30.00 itex:224 ptex:0 mv:418 misc:318 imb:1350 pmb:0 smb:0 d:-;
...

I did back-to-back keyframes in an attempt to see if it can override the min-keyint parameter and it does.

The qp for the frame is still mandatory, but that's not too big of a deal in my opinion

[akupenguin]

btw, relaxing (qp < 0) to (qp < -1) will let you specify some frames as qp=-1 meaning auto.
It's a bad idea to mix a few auto frames into a lot of forced ones, but the other way around should work.

[kemuri-_9]

thanks for the tips, I updated the patch file to allow for -1 qp and confirmed it working!

btw, is there any chance of having this put into the git for standard usage?

[Razorholt]

Can someone please compile another modified version with this patch from MasterNobody: http://forum.doom9.org/showthread.php?p=1151782#post1151782

Thanks,
- Dan

[MythCreator]

x264.891.modified.2.exe (http://www.fs2you.com/files/9eee3fa8-435e-11dd-9653-001143e7b41c/)


General thread:
http://forum.doom9.org/showthread.php?t=130364


x264_psy_rdo.r889.diff
http://forum.doom9.org/showthread.php?t=138293
X264_progress.indication.diff
http://forum.doom9.org/showthread.php?t=135905
x264_qpfile_relax.diff(fixed)
http://forum.doom9.org/showthread.php?p=1151919#post1151919
x264_interlaced_signaling.r886.diff
http://mailman.videolan.org/pipermail/x264-devel/2008-June/004656.html

Link to x264 patches collected: http://files.x264.nl/x264_patches/


GCC 3.4.5 build fprofiled

[Razorholt]

Thanks MythCreator!

[LoRd_MuldeR]

What revision are we at now? The latest log entry on git says:

commit 2ca45934d79a62c1c04771c98eb3ee1d119cdd7a

Move bitstream end check to macroblock level
Additionally, instead of silently truncating the frame upon reaching the end of the buffer, reallocate a larger buffer instead.

That is identical with the latest entry in the changelog on x264.nl, but the revision number there says 890 instead of 891 :confused:

[burfadel]

I asked essentially the same question on another thread under the x264 sticky earlier today. It hasn't been answered yet! The other day I noticed x264.nl seemed to be down, so something could have happened to the system and it combined the last two revisions. The main issue with this is it creates confusion and possibility of problems applying future patches!

[Dark Shikari]

What revision are we at now? The latest log entry on git says:



That is identical with the latest entry in the changelog on x264.nl, but the revision number there says 890 instead of 891 :confused:I thought it was 891 too... :confused:

[MythCreator]

Changelog has been changed to r891~

[Fantacinni]

x264.r892.patched.exe (http://www.mediafire.com/?x1zne7mkyhd)

Patches used:
x264.progress.indication.01.diff
x264_hrd_pulldown.04.diff
x264_psy_rdo.0.22.diff

Built by GCC 4.2.2 fprofiled, pthread, GPAC

[Razorholt]

x264_psy_rdo
Which patch please?

Thanks,
- Dan

[Fantacinni]

Which patch please?

Thanks,
- Dan

x264_psy_rdo.0.22.diff

P.S. Congratulations Spain!

[Razorholt]

Have you checked this patch: http://forum.doom9.org/showthread.php?p=1151782#post1151782 ?
It's just a suggestion since I haven't compared it with 0.22. Maybe someone has?

[Razorholt]

Can someone please compile a new build with:

- New VAQ2.0: http://forum.doom9.org/showthread.php?p=1153982#post1153982
- New PsyRDO: http://forum.doom9.org/showthread.php?p=1151782#post1151782

Thanks! :)

- Dan

[MythCreator]

x264.892.modified.exe (http://www.fs2you.com/files/214c21cc-4722-11dd-af7f-001143e7b41c/)
Source (http://www.fs2you.com/files/b339b668-4721-11dd-80e8-001143e7b41c/)


General thread:
http://forum.doom9.org/showthread.php?t=130364


x264_psy_rdo.r889.diff
http://forum.doom9.org/showthread.php?t=138293
X264_progress.indication.diff
http://forum.doom9.org/showthread.php?t=135905
x264_qpfile_relax.diff(fixed)
http://forum.doom9.org/showthread.php?p=1151919#post1151919
x264_interlaced_signaling.r886.diff
http://mailman.videolan.org/pipermail/x264-devel/2008-June/004656.html

Link to x264 patches collected: http://files.x264.nl/x264_patches/


GCC 3.4.5 build fprofiled

[MythCreator]

@Razorholt:
PsyRDO & VAQ2 can't be patched at the same time

[Razorholt]

@Razorholt:
PsyRDO & VAQ2 can't be patched at the same time
I see... Hopefully this is something that will be fixed soon :)

Thanks for the builds!

- Dan

[Wishbringer]

@MythCreator:
x264_hrd_pulldown.04.diff intentionally left out? Or was it meanwhile committed?

[MasterNobody]

@Razorholt:
PsyRDO & VAQ2 can't be patched at the same time
They can but there is small problem with applying them together because they both add constants in x264.h and patch utility after applying first patch can't find place where to patch second. But you can simply add these constants manually. There result would be
#define X264_RC_NONE -1
#define X264_RC_CQP 0
#define X264_RC_CRF 1
#define X264_RC_ABR 2
#define X264_AQ_NONE 0
#define X264_AQ_LOCAL 1
#define X264_AQ_GLOBAL 2
#define X264_AQ_HYBRID 3
#define X264_CMP_SSD 0
#define X264_CMP_PSY 1
By the way you can find recent builds with this patches here: http://komisar.gin.by/
P.S. This is not my builds.

[MythCreator]

@Wishbringer:
http://mailman.videolan.org/pipermail/x264-devel/2008-June/004656.html

[Wishbringer]

Thanks, missed that message

[lexor]

@Wishbringer:
http://mailman.videolan.org/pipermail/x264-devel/2008-June/004656.html

I don't understand that message, it's talking like hrd was only ever used for interlaced encoding. But nal-hrd switch had to be used for 360/PS3 blu-ray/hddvd profiles even on progressive material.

So I don't see how that patch is a substitute for original.

[Sharktooth]

it is NOT.

[lexor]

it is NOT.

What's not? Not needed or not substitute?

If the former, it's in every megui profile for hd formats.

If the later, original question was why hrd patch isn't in, and MythCreator replied with that link. That suggests that he thinks it's a substitute. Since he does builds, I assumed he knew what the patches were for.

[Sharktooth]

it's not a substitute.
infact i dont use myth's builds for megui.

[MythCreator]

x264.893.modified.exe (http://www.fs2you.com/files/0138aa73-480a-11dd-9903-00142218fc6e/)
source (http://www.fs2you.com/files/0c8228ba-480b-11dd-bd53-001143e7b41c/)

General thread:
http://forum.doom9.org/showthread.php?t=130364


x264_psy_rdo.r889.diff
http://forum.doom9.org/showthread.php?t=138293
X264_progress.indication.diff
http://forum.doom9.org/showthread.php?t=135905
x264_qpfile_relax.diff
http://forum.doom9.org/showthread.php?p=1151919#post1151919
x264_hrd_pulldown.04_interlace.diff
HRD and pulldown for HD compatibility, updated patch for interlacing
http://forum.doom9.org/showthread.ph...19#post1047919


Link to x264 patches collected: http://files.x264.nl/x264_patches/


GCC 3.4.5 build fprofiled

[bob0r]

x264.895.modified.01.exe (http://files.x264.nl/x264.895.modified.01.exe)
x264.895.modified.01.source.zip (http://files.x264.nl/x264.895.modified.01.source.zip)

x264_psy_rdo.r889.diff
http://forum.doom9.org/showthread.php?t=138293
http://forum.doom9.org/showthread.php?p=1151782#post1151782
x264_hrd_pulldown.04_interlace.diff
HRD and pulldown for HD compatibility, updated patch for interlacing
http://forum.doom9.org/showthread.php?p=1047919#post1047919
x264.progress.indication.01.diff
http://forum.doom9.org/showthread.php?t=135905
x264_qpfile_relax.diff
http://forum.doom9.org/showthread.php?p=1151919#post1151919

Link to x264 patches collected: http://files.x264.nl/x264_patches/

Here is the output of the patching process:
http://files.x264.nl/x264.895.modified.01.patch.out.txt

Here is the output of the compiling process:
http://files.x264.nl/x264.895.modified.01.fprofiled.out.txt


gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DPTW32_STATIC_LIB -DHAVE_PTHREAD -s -fomit-frame-pointer -fprofile-generate -c -o encoder/set.o encoder/set.c
encoder/set.c: In function `x264_sps_init':
encoder/set.c:215: warning: unused variable `cpbBrVclFactor'

gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DPTW32_STATIC_LIB -DHAVE_PTHREAD -s -fomit-frame-pointer -fprofile-use -c -o encoder/encoder.o encoder/encoder.c
encoder/encoder.c: In function `x264_encoder_encode':
encoder/encoder.c:1278: warning: 'cpb_removal_delay' might be used uninitialized in this function


darkorange = x264_hrd_pulldown.04_interlace.diff

The warnings that are not in the GIT code are highlighted with a color, and should not be there.
(The GIT warnings are there because of a bug in Windows, they prevent the usage of extended zones, example: x264 --zones 1,100,bframes=0)
The GIT warnings:

gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DPTW32_STATIC_LIB -DHAVE_PTHREAD -s -fomit-frame-pointer -fprofile-generate -c -o common/common.o common/common.c
common/common.c: In function `x264_param_parse':
common/common.c:252: warning: unused variable `saveptr'

gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DPTW32_STATIC_LIB -DHAVE_PTHREAD -s -fomit-frame-pointer -fprofile-generate -c -o encoder/ratecontrol.o encoder/ratecontrol.c
encoder/ratecontrol.c: In function `parse_zone':
encoder/ratecontrol.c:564: warning: unused variable `saveptr'
encoder/ratecontrol.c: In function `parse_zones':
encoder/ratecontrol.c:607: warning: unused variable `saveptr'

[MythCreator]

x264.897.modified.exe (http://www.fs2you.com/files/42531e61-4908-11dd-915e-0014221f4662/)
source (http://www.fs2you.com/files/4cfae88f-4908-11dd-8391-00142218fc6e/)

General thread:
http://forum.doom9.org/showthread.php?t=130364


x264_psy_rdo.r889.diff
http://forum.doom9.org/showthread.php?t=138293
X264_progress.indication.diff
http://forum.doom9.org/showthread.php?t=135905
x264_qpfile_relax.diff
http://forum.doom9.org/showthread.php?p=1151919#post1151919
x264_hrd_pulldown.04_interlace.diff
HRD and pulldown for HD compatibility, updated patch for interlacing
http://forum.doom9.org/showthread.ph...19#post1047919


Link to x264 patches collected: http://files.x264.nl/x264_patches/


GCC 3.4.5 build fprofiled

[kemuri-_9]

x264 r899 builds with mods:

x264_psy_rdo.r889.diff
http://forum.doom9.org/showthread.php?t=138293
x264_qpfile_relax.diff
http://forum.doom9.org/showthread.php?p=1151919#post1151919
x264_hrd_pulldown.04_interlace.diff
http://forum.doom9.org/showthread.php?p=1047919#post1047919
X264_progress.indication.diff
http://forum.doom9.org/showthread.php?t=135905

builds using -march flags (if specified)
k8 (AMD) flavor
http://kemuri9.net/dev/x264/x264_k8.exe
prescott (Intel) flavor
http://kemuri9.net/dev/x264/x264_prescott.exe
unspecified (generic) flavor
http://kemuri9.net/dev/x264/x264.exe

GCC 4.2.1-sjlj build fprofiled
can see how much gcc -march affects the speeds and which one works best for you.

see http://gcc.gnu.org/onlinedocs/gcc-4.2.1/gcc/i386-and-x86_002d64-Options.html for information on -march specs

[chainring]

x264 r899 builds with mods:

x264_psy_rdo.r889.diff
http://forum.doom9.org/showthread.php?t=138293
x264_qpfile_relax.diff
http://forum.doom9.org/showthread.php?p=1151919#post1151919
x264_hrd_pulldown.04_interlace.diff
http://forum.doom9.org/showthread.php?p=1047919#post1047919
X264_progress.indication.diff
http://forum.doom9.org/showthread.php?t=135905

builds using -march flags (if specified)
k8 (AMD) flavor
http://kemuri9.net/dev/x264-arch/x264_k8.exe
nocona (Intel) flavor
http://kemuri9.net/dev/x264-arch/x264_nocona.exe
unspecified (generic) flavor
http://kemuri9.net/dev/x264.exe

GCC 4.2.1-sjlj build fprofiled
can see how much gcc -march affects the speeds and which one works best for you.

see http://gcc.gnu.org/onlinedocs/gcc-4.2.1/gcc/i386-and-x86_002d64-Options.html for information on -march specsAny possibility you could do one with '-march=prescott'? I have a lowly core duo, but it bombs on the nocona build, so I'm guessing it doesn't support the 64 bit extensions.

[akupenguin]

nocona (Intel) flavor
Nocona fails as a generic Intel flavor. In fact, both core2 and pentium4 run march=k8 faster than march=nocona.
Note that my results are specific to x264; apps with floating-point will differ.

[Underground78]

builds using -march flags (if specified)
k8 (AMD) flavor
http://kemuri9.net/dev/x264-arch/x264_k8.exe
unspecified (generic) flavor
http://kemuri9.net/dev/x264.exe

Both builds crash for me ... :eek:

[burfadel]

Both builds work fine for me, core 2 duo e6600 (soon to be q9400) :) wouldn't by any chance be running an overclock? If the overclock is too high certain things can start to go awry... someone I know had one of those 'big' overclocks, it wasn't until he knocked back his q6600 to around 3.2ghz did all his random crashes stop. Even if it was after 2 days with something not responding as well as it should! at 3.2ghz he hasn't had any problems with any programmes (this was about 4 weeks ago, leaves the computer on all the time). Its not worth going those few extra hundred mhz at the expense of rock stability. Those that go to 4ghz with the e8400, they can run tests on it for 2 days and not have a problem, but then have a random crash they blame on windows instead...

[Underground78]

I have an Athlon X2 6000+ @ 3 Ghz so without any overclocking ...

[burfadel]

Memory timings?

[Underground78]

Default ones but builds from x264.nl work fine so I'm not sure it can be an hardware problem ...

[cyberbeing]

Have you tried re-downloading it? Maybe your first download was incomplete or corrupt.

[Dark Shikari]

Both builds crash for me ... :eek:I wouldn't be surprised; a build I made with -march=core2 crashed for me the other day because GCC was incorrectly autovectorizing on an unaligned array.

[Sharktooth]

optimizing x264 via -march flag for more than i686 (or Pentium2) is USELESS.
it has been proven at least 5 (or even more) times... USELESS.
repeat with me... USELESS.
repeat again until you get it right...
USELESS.

[lexor]

optimizing x264 via -march flag for more than i686 (or Pentium2) is USELESS.
it has been proven at least 5 (or even more) times... USELESS.
repeat with me... USELESS.
repeat again until you get it right...
USELESS.

I think you should put an addendum to that statement. Most people who do builds won't just compile x264 itself, but also a bunch of other libraries (for mp4 and mkv support at least), and those libraries could benefit from compiler optimizations, last I saw their code they weren't nearly as handwritten-asm heavy as x264 is.

[LoRd_MuldeR]

I think you should put an addendum to that statement. Most people who do builds won't just compile x264 itself, but also a bunch of other libraries (for mp4 and mkv support at least), and those libraries could benefit from compiler optimizations, last I saw their code they weren't nearly as handwritten-asm heavy as x264 is.

Nevertheless I highly doubt that the muxer libs will ever become the bottleneck, even when using very "fast" x264 settings...

[foxyshadis]

Both builds crash for me ... :eek:

It crashes with a DEP exception for me, if I add it to the excluded list it runs fine.

[kemuri-_9]

well i've been testing with the unspec vs -march=k8 and on the encodes i finished the unspec was at 1.26 fps while the k8 was at 1.9 fps on my athlon64 X2 4200+.
So that proves to me that it's not useless
I'll do one for prescott and post it up, so can test that too

[Dark Shikari]

well i've been testing with the unspec vs -march=k8 and on the encodes i finished the unspec was at 1.26 fps while the k8 was at 1.9 fps on my athlon64 X2 4200+.That kind of benefit is basically impossible, since I'm not sure you could even get that much of a speed boost if you eliminate all of the runtime spent in C functions. Its more likely you're running with threads on one and not on the other, for example.

[kemuri-_9]

no, i have my x264 options in a batch file, and just run the batch file, only difference was which x264 it was using

they both had the exact same options on the encodes

Edit:
-march=prescott finished
http://kemuri9.net/dev/x264-arch/x264_prescott.exe

[Sharktooth]

i did tons of tests in the past an the gain was in order of 0.01/0.02 FPS.
The major gain is using -march=pentium2. Anything above is USELESS. Just a waste of time.
Also be sure to build the external dependecies with -march=pentium2 too... (pthreads, mp4box, ... whatever...)
If you get different results im sure you did something wrong.

[Dark Shikari]

i did tons of tests in the past an the gain was in order o 0.01/0.02 FPS.
The major gain is using -march=pentium2. Anything above is USELESS. Just a waste of time.
Also be sure to build the external dependecies with -march=pentium2 too... (pthreads, mp4box, ... whatever...)
If you get different results im sure you did something wrong.And the entire benefit of -march=pentium2 is probably from using CMOV.

[kemuri-_9]

I forgot to account for the caching principle in the first round of tests,
re-running them generated generic w/ 2.54 vs k8 w/ 2.58 after the video was cached from a first run

this is more of what i expected anyway (should have thought something was strange the first time: :stupid:), since x264 is heavily optimized with the handwritten asm.
since the -march in turn does -mtune, I'm attributing the difference in fps to the c code being written in a slightly 'affiliated' way to the processor. but hey any help helps...

following are the logs i have from the encode process since i redirect stderr to file to log the encodes since i often batch encode

source is a section of a 16:9 720x480 anime dvd roughly 88s @ 24000/1001 fps
http://kemuri9.net/dev/x264/test.x264.k8.2pass.log
http://kemuri9.net/dev/x264/test.x264.generic.2pass.log

(running windows 'type' on the logs produces output exactly they would if not written to file)

[3ngel]

On FX-62 the x264_k8.exe with heavy settings goes from 1.02fps to 1.80 fps. I think that's an improvement.

[Tarutaru]

x264.r899.patched.exe (http://www.mediafire.com/?39imxtc9mtg)

x264_psy_rdo.r889.diff
X264_progress.indication.diff
x264_hrd_pulldown.04_interlace.diff


GCC 4.3.1 build with fprofiled, -march=k8-sse3

[skystrife]

x264.901.modified.exe (http://www.mediafire.com/?y29cct6mhzw)
(source) (http://www.mediafire.com/?mictdce8bjb)

Patches Used:

x264.psyRDO.0.22.diff
x264_hrd_pulldown.04_interlace.diff
x264.progress.indication.01.diff
x264_qpfile_relax.diff
x264_frames_memoryleak.r891.diff

All patches included with the source.

gcc 3.4.5 fprofiled build.

[Dark Shikari]

x264.901.modified.exe (http://www.mediafire.com/?y29cct6mhzw)
(source) (http://www.mediafire.com/?mictdce8bjb)

Patches Used:

x264.psyRDO.0.22.diffUpdate to the latest, 0.3.

[Snowknight26]

x264.r899.patched.exe (http://www.mediafire.com/?39imxtc9mtg)

Thanks for the build. (Creative username by the way.. what server you on?)

[Geleodor]

Hi,
could somebody compile a build with a multislising patch (http://mailman.videolan.org/pipermail/x264-devel/attachments/20080505/409f150b/attachment-0001.obj) and "usual ones":
x264.psyRDO.0.3.diff
x264_hrd_pulldown.04_interlace.diff
x264.progress.indication.01.diff
x264_qpfile_relax.diff

Thanks.

[Tarutaru]

x264.r901.patched.exe (http://www.mediafire.com/?jdye5lmm3ge)

x264.progress.indication.01.diff
x264_hrd_pulldown.04_interlace.diff
x264_psy_rdo.r889.diff
x264_qpfile_relax.diff


GCC 4.3.1 build with fprofiled, -march=k8-sse3

Thanks for the build. (Creative username by the way.. what server you on?)

Fenrir.... yotaru play FFXI too? :p

[LoRd_MuldeR]

Would it be possible to get DLL of x264 r901 including Psy RDO patch v0.3 and Gruntster's patch (see below), but no other patch that changes the interface? :thanks:

diff --git a/encoder/encoder.c b/encoder/encoder.c
index cffaeeb..34cbe8c 100644
--- a/encoder/encoder.c
+++ b/encoder/encoder.c
@@ -1222,6 +1222,7 @@ static int x264_slices_write( x264_t *h )
* B 5 2*4
* B 6 2*5
****************************************************************************/
+__attribute__((force_align_arg_pointer))
int x264_encoder_encode( x264_t *h,
x264_nal_t **pp_nal, int *pi_nal,
x264_picture_t *pic_in,

[lexor]

does anyone know what version of pryrdo x264.nl uses for its 901?

[Sharktooth]

none. since there is no r901 modified build yet.

[bob0r]

Request by Sharktooth (quick post):

x264.901.modified.01.exe (http://files.x264.nl/x264.901.modified.01.exe)

x264_psy_rdo.r889.diff
x264_hrd_pulldown.04_interlace.diff
x264.progress.indication.01.diff
x264_qpfile_relax.diff

[LoRd_MuldeR]

Would it be possible to get DLL of x264 r901 including Psy RDO patch v0.3 and Gruntster's patch (see below), but no other patch that changes the interface? :thanks:

Think I got it done myself. The result can be found here:
http://forum.doom9.org/showpost.php?p=1156859&postcount=775

[skystrife]

x264.906.modified.exe (http://www.mediafire.com/?vyc1vdhtsug)
(Source) (http://www.mediafire.com/?gnz4yjggwdu)


x264_hrd_pulldown.04_interlace.diff has been omitted from this build. The patching process goes smoothly, but upon compile generates this error:

libx264.a(set.o):set.c:(.text+0x3cee): undefined reference to `bs_align_10'
libx264.a(set.o):set.c:(.text+0x3df5): undefined reference to `bs_align_10'
libx264.a(set.o):set.c:(.text+0x3ef5): undefined reference to `bs_align_10'
collect2: ld returned 1 exit status

Patches used:

x264_psy_rdo.r889.diff (aka 0.3)
x264.progress.indication.01.diff
x264_frames_memoryleak.r891.diff
x264_qpfile_relax.diff

All patches are included with the source.

gcc 3.4.5 fprofiled build.

[Dark Shikari]

[code]libx264.a(set.o):set.c:(.text+0x3cee): undefined reference to `bs_align_10'
libx264.a(set.o):set.c:(.text+0x3df5): undefined reference to `bs_align_10'
libx264.a(set.o):set.c:(.text+0x3ef5): undefined reference to `bs_align_10'The patch will have to be updated to deal with my new bitstream writer.

[dirio49]

hi,
a bit off topic
but how do you apply these patches?
i am having a hard time
i tried the git-apply and patch -p0 .
any other way or am i doing anything wrong.
thank you

[Dark Shikari]

patch -p1 <file.diff

[skystrife]

x264.910.modified.exe (http://www.mediafire.com/?wigetgxvhgy)
(Source) (http://www.mediafire.com/?iix3ld99gcy)


x264_hrd_pulldown.04_interlace.diff has been omitted from this build and will not be included until it is rewritten for the new bitstream writer.


Patches used:

x264_psyRDO_0.5.diff
x264.progress.indication.01.diff
x264_qpfile_relax.diff

All patches are included with the source.

gcc 3.4.5 fprofiled build.

[Trahald]

Im off work tomorrow. should have time then to update the diff.

[McCauley]

Hi!

is there a specific reason nobody did/does a patched x264.exe with psyRDO and VAQ2 ? I read both threads, but there was never an incompatibility mentioned, or am i wrong?
I really would like to see an .exe with both patches.

Regards
McCauley

[Razorholt]

nicko is doing it for us :D

http://komisar.gin.by/


I've already asked him to compile a new version with the lastest patches.

[bob0r]

Hi!

is there a specific reason nobody did/does a patched x264.exe with psyRDO and VAQ2 ? I read both threads, but there was never an incompatibility mentioned, or am i wrong?
I really would like to see an .exe with both patches.

Regards
McCauley

VAQ2 really isn't recommended
[21:27] ('Dark_Shikari): I already put "metric 4" which was just an AQ bugfix into git x264, as for psy-rd 0.5, still figuring out something before i compile:

x264_hrd_pulldown.04_interlace.diff needs to be updated, however x264_interlaced_signaling.r886.diff does patch.

My question: Does x264_interlaced_signaling.r886.diff work (at all?) as good as the x264_hrd_pulldown.04_interlace.diff for the bluray and other device people here??

[bob0r]

x264.912.modified.01.exe (http://files.x264.nl/x264.912.modified.01.exe)
libx264-60.912.modified.01.dll (http://files.x264.nl/libx264-60.912.modified.01.dll)

x264-psyrd-0.5.diff - more tests wanted before going to GIT!
http://forum.doom9.org/showthread.php?t=138293

not added:
x264_hrd_pulldown.04_interlace.diff - won't patch
x264_interlaced_signaling.r886.diff - not enough information from our bluray or other device friends.
(pengvado_): jarod: nothing is useful about interlaced encodes, and I'm not going to read the spec

x264.progress.indication.01.diff - doesn't seem enough interest to make this an all OS patch
x264_qpfile_relax.diff - part of GIT

[kemuri-_9]

yeah i just noticed the qpfile patch going into the git when i was just now trying to do some auto update/patching/building scripts so i can cron them eventually

guess it met approval from the developers to be used...

[Sharktooth]

not added:
x264_hrd_pulldown.04_interlace.diff - won't patch
Im off work tomorrow. should have time then to update the diff.
if you can build another modified exe after tharald has updated the patch i can include it in megui.
until then, the r901 is going to remain in the autoupdate.

[bob0r]

x264_interlaced_signaling.r886.diff is useless as replacement?

[lexor]

x264_interlaced_signaling.r886.diff is useless as replacement?
I'm not Sharktooth, but I've asked him this question, and it isn't a replacement. Mostly on account of progressive footage needing whatever hdr patch does, and interlaced patch is obviously for interlacing only.

[martino]

So I gave it a shot myself out of interest, and thought that I might as well post it if it'll be of any use to someone;

x264.912.modified.7z (http://www.mediafire.com/?mthtovve3ou) (exe)

Patches used:
x264-psyrd-0.5.diff
x264.progress.indication.01.diff
(I didn't use any of the other popular ones, because for my own uses they are pointless.)

GCC 3.4.5 built fprofiled, with pthreads and gpac, under XP SP3.


P.S. Thanks to kemuri for helping me with the building process.

[nicko]

nicko is doing it for us :D

http://komisar.gin.by/


I've already asked him to compile a new version with the lastest patches.
I am only transfer the information, komisar666 is responsible for this.

[Razorholt]

Thanks nicko. I think we've been heard :)

http://komisar.gin.by/

[Xoote]

great thanks

[Trahald]

I tested it a bit. seems to work. attached is the new patch.
sorry for the delay.. i havent used mingw32 in a bit and in the meanwhile i bought a webcam.. appears that sh.exe doesnt like the logitech quickcam service (http://www.devkitpro.org/faq/why-does-make-often-crash-creating-a-shexestackdump-file-when-i-try-to-compile-my-source-code/) and i got intermittent dumps . of course i didnt just find this out until 10 mins ago .. ugh. anyways.. looking for any reports.. output in mpc looks good and file data looks good in elecard tools.
*edit* removed attachment

[Zwitterion]

Thanks for the updated patch!
I have one question, though: When activating --nal-hrd no userdata which describes the encoder settings is being written (at least with x264_hrd_pulldown.04_interlace.diff.txt, haven't tried 05):

I mean like this:
x264
core 60 r901M 58d7d06
H.264/MPEG-4 AVC codec
Copyleft 2003-2008
http://www.videolan.org/x264.html
cabac=1
ref=3
...
...
...

Can this be fixed or is it unavoidable? :thanks:

[Ranguvar]

May I ask a quick question?

I'm not encoding anything interlaced, or that needs a pulldown, or anything... I just want to maximize future compatibility with all sorts of standalones.

Will --nal-hrd do that, and without compromising video quality?

Sorry, I don't know much about what it does :)

[skystrife]

x264.912.modified.exe (http://www.mediafire.com/?mc9even3yhx)
(Source) (http://www.mediafire.com/?9mzs4dwdndm)

qpfile_relax has been comitted to git, no longer included.

Patches used:

x264_psyRDO_0.5.diff
x264_hrd_pulldown.05_interlace.diff
x264.progress.indication.01.diff

All patches are included with the source.

gcc 3.4.5 fprofiled build.

[Zwitterion]

I can't mux raw streams created with x264_hrd_pulldown.05_interlace.diff to matroska. Yamb+MP4box works fine though. Mkvmerge displays the following error:
---------------------------
File identification failed
---------------------------
File identification failed for '4129_05.264'. Return code: 2

err end-of-file

Error: File 4129_05.264 has unknown type. Please have a look at the supported file types
('mkvmerge --list-types') and contact the author Moritz Bunkus <moritz@bunkus.org>
if your file type is supported but not recognized properly.


---------------------------
OK
---------------------------

h264 file created with x264_hrd_pulldown.04_interlace.diff (http://www.mediafire.com/?1xdb4mgqlxm)
h264 file created with x264_hrd_pulldown.05_interlace.diff (http://www.mediafire.com/?kcpnymouox1)

command line:
--crf 26 --level 4.1 --keyint 24 --min-keyint 1 --ref 3 --mixed-refs --bframes 3 --b-rdo --bime --weightb --direct auto --subme 7 --trellis 2 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --vbv-bufsize 30000 --vbv-maxrate 38000 --qcomp 0.5 --me umh --threads auto --thread-input --progress --no-psnr --no-ssim --output "output" "input" --mvrange 511 --aud --sar 1:1 --nal-hrd

skystrife's x264.912.modified.exe for x264_hrd_pulldown.05_interlace.diff
bob0r's x264.901.modified.01.exe for x264_hrd_pulldown.04_interlace.diff

[Sagittaire]

I can't mux raw streams created with x264_hrd_pulldown.05_interlace.diff to matroska.


Well HRD flag are here for HDDVD/BD hardware/software compatibility. It's completely useless for matroska mux. Anyway it's true: there are difference between 04 and 05 build.

[Trahald]

Thanks for the updated patch!
I have one question, though: When activating --nal-hrd no userdata which describes the encoder settings is being written (at least with x264_hrd_pulldown.04_interlace.diff.txt, haven't tried 05):

I mean like this:
x264
core 60 r901M 58d7d06
H.264/MPEG-4 AVC codec
Copyleft 2003-2008
http://www.videolan.org/x264.html
cabac=1
ref=3
...
...
...

Can this be fixed or is it unavoidable? :thanks:

yeah.. i will after im sure the other issue is fixed. (i havent looked at zwitterions streams yet tho)

[nm]

Well HRD flag are here for HDDVD/BD hardware/software compatibility. It's completely useless for matroska mux.
The interlace flags are useful though, when encoding as interlaced. Otherwise many decoders/players won't deinterlace automatically.

[lexor]

The interlace flags are useful though, when encoding as interlaced. Otherwise many decoders/players won't deinterlace automatically.

Isn't that what interlace patch is for? The one everyone keeps mistaking for hdr replacement.

[nm]

Isn't that what interlace patch is for? The one everyone keeps mistaking for hdr replacement.
Perhaps, but the interlace signaling was originally built on top of the HRD patch, and the versions discussed here contain these modifications, as the name (x264_hrd_pulldown.05_interlace.diff) suggests. I'm just saying that the combined patch isn't as useless for Matroska output as Sagittaire said.

[lexor]

Perhaps, but the interlace signaling was originally built on top of the HRD patch, and the versions discussed here contain these modifications, as the name (x264_hrd_pulldown.05_interlace.diff) suggests. I'm just saying that the combined patch isn't as useless for Matroska output as Sagittaire said.
Actually the origin of that name is that orginal hrd patch didn't work for interlaced, it was expanded (by a different person, I believe) and became x264_hrd_pulldown.interlace.diff. The point is that you don't need hrd for general interlaced footage, you need it for blu-ray/hddvd only.

As x264 has built in interlaced support, I think that should be expanded to tag interlaced stuff correctly, it seems like an omission that should be fixed in git not a patch. HRD patch really isn't there to fix the interlaced stream.

[nm]

Actually the origin of that name is that orginal hrd patch didn't work for interlaced, it was expanded (by a different person, I believe) and became x264_hrd_pulldown.interlace.diff.Yes, that's what I was trying to say. It's just that currently there aren't many builds available that contain the separated interlace signaling patch instead of the HRD version. Not that I care about Windows binaries myself, but Zwitterion was using them above.

The point is that you don't need hrd for general interlaced footage, you need it for blu-ray/hddvd only.
Agreed.

As x264 has built in interlaced support, I think that should be expanded to tag interlaced stuff correctly, it seems like an omission that should be fixed in git not a patch.
Agreed, although there is probably a good reason why the patch is not yet in git.

[bob0r]

The reasons are simple:
1: the bluray/hddvd/other devices specs are not public
2: the universe must explode before pengvado will waste any time regarding interlacing (unless paid sufficient).

I say drop interlacing completely, with enough x264 mkv movies out there, the first company that provides full support may count themselfs rich, very rich.

We should not adapt to the companies, they should adapt to us. And by simply NOT encoding with these useless patching or stupid levels, we will win.
But i guess laziness will overcome all.

[Trahald]

i have to talk to dark shikari -- the ue code on the large bitrate values are foobaring depending on the bit alignment at at that point of the sps (thats why when i testing it seemed ok) im sure due to the size of bitrate and cpb ue values. my brain hurts and i have alot going on.. i'll look at it again.. but for now .. dont patch any binaries until i release .6.

[Dark Shikari]

i have to talk to dark shikari -- the ue code on the large bitrate values are foobaring depending on the bit alignment at at that point of the sps (thats why when i testing it seemed ok) im sure due to the size of bitrate and cpb ue values. my brain hurts and i have alot going on.. i'll look at it again.. but for now .. dont patch any binaries until i release .6.Isn't there a UE_big function just for this purpose?

[CruNcher]

The Real Question is why should Consumer support HD-DVD or Blu-Ray @ all we don't have to , we are independent of this we don't need to restrict ourselves (but i have to admit i also try to stay Blu-Ray compatible most of the time), but i question me myselve for what, wich user is really gonna ever use a Blu-Ray Player that restricts the Quality of his content, hacking firmware (giving us freedom) unrestrict us from them that's what we should do not play their Game. If DivX inc. really means it true they are gonna give us this freedom finaly in the next incarnation of their Ecosystem :)

[Trahald]

ok... i rewrote the scale routine to make smaller values for now until i can figure out why it hates big values. what that means is the precision of the values will be off to the low side.. ie a bitrate of 30000000 hay be stored as 29999995 .. that shouldnt be an issue (high values would be in some cases, low values should be fine).. i'll have a patch file avail in a few mins

[Trahald]

Isn't there a UE_big function just for this purpose?
yeah... thats the routine i use.. and it works sometimes.. but other times depending on the offset it doesnt (ie depending on some values of i_left).. at least thats what a few ours of scratching my head have come up with.. my brain is fried from lack of sleep so i could be wrong

[akupenguin]

As x264 has built in interlaced support, I think that should be expanded to tag interlaced stuff correctly, it seems like an omission that should be fixed in git not a patch.
Be wary of using an argument like that, for I might take it as an argument for dropping interlaced support instead.

[Trahald]

heres a new patch.. again.. use only for testing... i ran a couple quick encodes with different settings and output was correct. (keeping in mind the workaround may use slightly lower values for bitrate and cpb size.)
*edit* attachment removed

[Dark Shikari]

yeah... thats the routine i use.. and it works sometimes.. but other times depending on the offset it doesnt (ie depending on some values of i_left).. at least thats what a few ours of scratching my head have come up with.. my brain is fried from lack of sleep so i could be wrongWhat's the size of the exp-golomb code that it breaks on?

[Trahald]

What's the size of the exp-golomb code that it breaks on?

anything 0x10000 or bigger...

[Dark Shikari]

anything 0x10000 or bigger...static inline void bs_write_ue_big( bs_t *s, unsigned int val )
{
int size = 0;
int tmp = ++val;
if( tmp >= 0x10000 )
{
bs_write32( s, 0 );
tmp >>= 16;
}
if( tmp >= 0x100 )
{
size = 16;
tmp >>= 8;
}
size += x264_ue_size_tab[tmp];
bs_write( s, size, val );
}So you're saying that first if-block fails... that strikes me as odd. Talk to pengvado about this, he wrote that section.

[skystrife]

x264.913.modified.exe (http://www.mediafire.com/?dnc9bhgm4ty)
(Source) (http://www.mediafire.com/?dhbmglwzjfm)

Patches used:

x264_psyRDO_0.5.diff
x264_hrd_pulldown.06_interlace.diff
x264.progress.indication.01.diff

All patches are included with the source.

gcc 3.4.5 fprofiled build.

[lexor]

Be wary of using an argument like that, for I might take it as an argument for dropping interlaced support instead.

Eh? I want it gone, waste of code lines and effort! I thought Avail, not you, are the guys who put interlacing in there, they should've been made to do a better job before it was allowed in.

[Dark Shikari]

Eh? I want it gone, waste of code lines and effort! I thought Avail, not you, are the guys who put interlacing in there, they should've been made to do a better job before it was allowed in.Akupenguin worked at Avail for over two years--and he was the one who wrote the interlacing support ;)

[LoRd_MuldeR]

Well, in an ideal video world interlacing would have gone long ago and no interlacing support would be required.
But in the reality of the video world interlacing is there and it's going to stay for a while. HDTV and AVCHD use it - if we want or not.
Therefore I think ignoring that fact and dropping interlacing support would be a bad idea, now that x264 is one of the most AVC encoders available.
If nobody is willing to improve interlacing support at the moment, which I understand very well, why not keep it as-is and that's it?

If the interlacing code was blocking future improvements in x264, then I would vote for dropping it :)


// General question //

Why not stack the fields of interlaced video, encode the frames progressive and re-weave them at playback?

This would require a "stack fields" filter before/in the encoder, an "unstack fields" filter in/after the decoder and one new flag in the bitstream.
All of the rest could be done 100% identical to progressive encoding. No special interlaced handling would be needed at all. Nothing.
Sounds to me like this could be implemented very easy. So why is it not done in real video formats like H.264 that way ???

[akupenguin]

Why not stack the fields of interlaced video, encode the frames progressive and re-weave them at playback?

This would require a "stack fields" filter in the encoder, an "unstack fields" filter in the decoder and one new flag in the bitstream.
All of the rest could be done 100% identical to progressive encoding. No special interlaced handling would be needed at.
That would indeed make things simple. But it reduces compression, even compared to non-adaptive field-based encoding, because you can't MC from the opposite parity (at least not without coding an excessively long mv), and it screws extrapolation of mvs over the packing boundary (which would otherwise be a frame edge).

[LoRd_MuldeR]

I see that MC is less efficient. Then maybe separating the fields (instead of stacking them) would be the better way MC-wise?
You would encode the double number of (progressive) frames, but each frame is only half of the vertical size. Overhead should be small.
At playback you simply re-weave two consecutive frames after decoding to get an interlaced frame again...

[akupenguin]

Yep. And that's pretty much what non-adaptive PAFF is, except that PAFF somehow made that conceptually simple process very complex. (e.g. by requiring special cases in the reference list generation, and special cases in MCing opposite parity, and special cases in deblocking, and ...)

[Trahald]

ok.. this change to the UE code works better int size = 0;
int tmp = ++val;
if( tmp >= 0x10000 )
{
bs_write( s, 16, 0 ) // CHANGED:[bs_write32( s, 0 );] -- (32 bits of 0's were too many)
size = 16; // ADDED: size wasnt being pushed up causing a truncated 'val' to be written
tmp >>= 16;
}
if( tmp >= 0x100 )
{
size += 16; //CHANGED: to += in case of really long values.
tmp >>= 8;
}
size += x264_ue_size_tab[tmp];
bs_write( s, size, val ); i'll put it in .7 patch in a bit

[akupenguin]

Nothing ever needs to write a value >= 0x1000000 ?

[Trahald]

i made the edit as you were typing i guess... :D

[Trahald]

i'll test that last edit.. as just thought that will pass > 32 bit values into the bitstream writer... i'll see if can handle it...

[akupenguin]

Nope, still tries to write up to 47 bits at once, and the point of the original is that we can't do more than 31.
Try this, which should work up to 0x7ffffffe.

--- a/common/bs.h
+++ b/common/bs.h
@@ -169,16 +169,17 @@ static inline void bs_write_ue_big( bs_t *s, unsigned int val )
int tmp = ++val;
if( tmp >= 0x10000 )
{
- bs_write32( s, 0 );
+ size = 32;
tmp >>= 16;
}
if( tmp >= 0x100 )
{
- size = 16;
+ size += 16;
tmp >>= 8;
}
size += x264_ue_size_tab[tmp];
- bs_write( s, size, val );
+ bs_write( s, size>>1, 0 );
+ bs_write( s, (size>>1)+1, val );
}

/* Only works on values under 255. */

[Dark Shikari]

i'll test that last edit.. as just thought that will pass > 32 bit values into the bitstream writer... i'll see if can handle it...No, it can't. The bitstream writer cannot handle any size larger than 31 bits, I believe.

[Trahald]

Nope, still tries to write up to 47 bits at once, and the point of the original is that we can't do more than 31.
Try this, which should work up to 0x7ffffffe.

--- a/common/bs.h
+++ b/common/bs.h
@@ -169,16 +169,17 @@ static inline void bs_write_ue_big( bs_t *s, unsigned int val )
int tmp = ++val;
if( tmp >= 0x10000 )
{
- bs_write32( s, 0 );
+ size = 32;
tmp >>= 16;
}
if( tmp >= 0x100 )
{
- size = 16;
+ size += 16;
tmp >>= 8;
}
size += x264_ue_size_tab[tmp];
- bs_write( s, size, val );
+ bs_write( s, size>>1, 0 );
+ bs_write( s, (size>>1)+1, val );
}

/* Only works on values under 255. */

works perfect! test large values and semi large (as w/large bitrates) all came out good on the other end.

[Sharktooth]

so, coukd you please link the new patch?

[Trahald]

i was kinda hoping he would commit the ue code changes to the main. all that has to happen is the akus patch be used then .05 after (not .06 which has the workaround) on top of it... i'll post a combined patch in a few mins tho

[Dark Shikari]

i was kinda hoping he would commit the ue code changes to the main. all that has to happen is the akus patch be used then .05 after (not .06 which has the workaround) on top of it... i'll post a combined patch in a few mins thohe already did (http://git.videolan.org/?p=x264.git;a=commit;h=fee2f2ce3cda8e39cc4c123afa726933b6b9b877)

[Trahald]

he already did (http://git.videolan.org/?p=x264.git;a=commit;h=fee2f2ce3cda8e39cc4c123afa726933b6b9b877)

ahh.. excellent... attached is .07 which is really .05 but renamed to prevent confusion.

[Sharktooth]

nice stuff. thanks.
however i still cant understand why the hrd_pulldown is not in the official repo since it's absolutely needed to crete BD compliant bitstreams.
ok, we all know those additional info are not necessary and can be added anytime if needed, however x264 is in a strong position against commercial codecs and it's just a shame it cant produce BD compliant streams by default.

[lexor]

nice stuff. thanks.
however i still cant understand why the hrd_pulldown is not in the official repo since it's absolutely needed to crete BD compliant bitstreams.
ok, we all know those additional info are not necessary and can be added anytime if needed, however x264 is in a strong position against commercial codecs and it's just a shame it cant produce BD compliant streams by default.

last time that was asked, aku said that because the patch is based on stream analysis + guesswork and not backed up by any solid spec, he doesn't want it the main code base.

[Sharktooth]

yeah, i know that too. but most of the OSS is based on black box RE or RE...
so i cant see that one as a valid point.

[skystrife]

x264.914.modified.exe (http://www.mediafire.com/?egggwkonzyy) - Alternate Download (http://skystrife.com/x264/x264.914.modified.exe)
(Source) (http://www.mediafire.com/?bfzbddsbkiz) - Alternate Download (http://skystrife.com/x264/x264.914.modified.source.7z)

Patches used:

x264_psyRDO_0.5.diff
x264_hrd_pulldown.07_interlace.diff
x264.progress.indication.01.diff

All patches are included with the source.

gcc 3.4.5 fprofiled build.

[Sharktooth]

bobor? what about a new patched/modified build? since i still have an internet connection im sure i can upload at least the x264 update to megui auto-update server.
psy RD0 0.5 rox, and the new hrd-pulldown 0.7 is working perfectly.
i have to learn how to crosscompile x264 from linux to win32.

[Sharktooth]

@skystrife: medifire says: NOTICE: No servers are currently available with the requested data on them. Please retry your request in a moment.
could you plaese upload to another service?

[skystrife]

@skystrife: medifire says: NOTICE: No servers are currently available with the requested data on them. Please retry your request in a moment.
could you plaese upload to another service?

That's odd. Yes, I'll put another link up.

EDIT: It's up. =)

[TheRyuu]

x264.914.modified.exe (http://www.mediafire.com/?twzmpzqjsmz)
(alt DL link (http://www.zshare.net/download/156128790c0f3f89/))

GCC 3.4.5 fprofiled build with static-pthreads.
Platform: X86
System: MINGW
asm: yes
avis input: yes
mp4 output: yes
pthread: yes
Everything else (useless for a cli build) is no.

Patches:
psyRDO 0.5
hrd pulldown 0.7 interlace
progress indication

[desta]

I've noticed with these latest builds, that if I include --nal-hrd in the commandline, when I later check the encode in something like avinaptic, I no longer see the list of encoding options I used. If I omit the --nal-hrd option, then everything shows up as normal.

[Dark Shikari]

I've noticed with these latest builds, that if I include --nal-hrd in the commandline, when I later check the encode in something like avinaptic, I no longer see the list of encoding options I used. If I omit the --nal-hrd option, then everything shows up as normal.Sounds like NAL-HRD managed to corrupt the SEI or something...

[desta]

Ah yeah, sorry, just looked back through the topic to see it's already been mentioned. :rolleyes:

[Trahald]

nah.. doesnt corrupt.. purposefully omits... i wrote a --user-data option that will add it back in... will have a diff out tonight.. user data sei message is supposed to be safe as long as buffering sei message is first in the AU. i'll leave it an defaulted off until i get a few all clear reports.

[Dark Shikari]

nah.. doesnt corrupt.. purposefully omits... i wrote a --user-data option that will add it back in... will have a diff out tonight.. user data sei message is supposed to be safe as long as buffering sei message is first in the AU. i'll leave it an defaulted off until i get a few all clear reports.I will not endorse any patch that allows disabling of the user data.

[Trahald]

:(... ok.. the next patch will add it back unconditionally.. i would just say to anyone that uses it for the first time make sure your application (standalone, whatever) doesnt have an issue with it.. it shouldnt.. but you never know.

[bob0r]

yeah, i know that too. but most of the OSS is based on black box RE or RE...
so i cant see that one as a valid point.

1: I saw the patch was still kinda in developement, to dot some i's. Is it done for now?
2: I had horrible isp problems, as you can read on x264.nl
I had 5kb/s upload with timeouts every 200+kb :)
These problems all seem solved.
So if the patch is ready for now, i guess ill update.

But my first thoughts were with you, telling you you should only mind your health and not megui updates before that.
But as now, you quit IRC already :)

[Trahald]

hrd patch no longer omits user data when nal-hrd is used. writes user data in a nal w/buffering period msg. also small change to bs_align_10 code sugstd by pv

[bob0r]

hrd patch no longer omits user data when nal-hrd is used. writes user data in a nal w/buffering period msg. also small change to bs_align_10 code sugstd by pv

Cool, any more plans for the patch any time soon? I'ill compile a new build anyway tomorrow to test!

Edit:
Any plans to get rid of the compiling errors as shown in my build posts?

encoder/set.c: In function `x264_sps_init':
encoder/set.c:217: warning: unused variable `cpbBrVclFactor'
etc..

[skystrife]

x264.914.modified.02.exe (http://www.mediafire.com/?myobctkxd9x) - Alternate Download (http://skystrife.com/x264/x264.914.modified.02.exe)
(Source) (http://www.mediafire.com/?ktihlrmugmd) - Alternate Download (http://skystrife.com/x264/x264.914.modified.02.source.7z)

Patches used:

x264_psyRDO_0.5.diff
x264_hrd_pulldown.08_interlace.diff
x264.progress.indication.01.diff

All patches are included with the source.

gcc 3.4.5 fprofiled build.

[skystrife]

x264.915.modified.exe (http://www.mediafire.com/?1glgjl3czcw) - Alternate Download (http://skystrife.com/x264/x264.915.modified.exe)
(Source) (http://www.mediafire.com/?xhg9hctjn1h) - Alternate Download (http://skystrife.com/x264/x264.915.modified.source.7z)

Patches used:

x264_psyRDO_0.5.diff
x264_hrd_pulldown.09_interlace.diff (http://skystrife.com/x264/x264_hrd_pulldown.09_interlace.diff) - Slight change to get it to patch with r915, /encoder/set.h changes with the validate levels line.
x264.progress.indication.01.diff

All patches are included with the source.

gcc 3.4.5 fprofiled build.

[Sharktooth]

@skystrife: while waiting for an "official" x264.nl ... [removed - no longer necessary]

[Sharktooth]

ok, do it :) ill delete my previous post then

[bob0r]

x264.915.modified.01.exe (http://files.x264.nl/x264.915.modified.01.exe)
libx264-60.915.modified.01.dll (http://files.x264.nl/libx264-60.915.modified.01.dll)

x264-psyrd-0.5.diff
x264_hrd_pulldown.09_interlace.diff
x264.progress.indication.01.diff

[Sharktooth]

done.

[jefrey]

can anyone explain why
boboirs build is ~1-3fps slower than skystrifes build?
used trellis and psy:
boboirs build 915 : 6-7fps
skystrife915 : 7-8 fps

[skystrife]

I would probably say that's within the margin of error, but it may have something to do with the build environment and cflags.

[TheRyuu]

I would probably say that's within the margin of error, but it may have something to do with the build environment and cflags.

AFAIK the only cflag of any particular use is march=pentium2 to enable mmx/cmov support. Anything else won't change anything and even that is trivial (I guess). (aside from the defaults I mean)

Maybe the fprofile is different as well although that shouldn't matter either.

[Sharktooth]

how did you compile pthreads and gpac? what cflags you used for them?
IIRC if you optimize those 2 with MMX too you could get a nice speed boost in certain situations.

[skystrife]

x264.918.modified.exe (http://www.mediafire.com/?l9swnudyglc) - Alternate Download (http://skystrife.com/x264/x264.918.modified.exe)
(Source) (http://www.mediafire.com/?yxglwgsjgwb) - Alternate Download (http://skystrife.com/x264/x264.918.modified.source.7z)

Patches used:

x264_psyRDO_0.5.diff
x264_hrd_pulldown.09_interlace.diff
x264.progress.indication.01.diff

All patches are included with the source.

gcc 3.4.5 fprofiled build.



I don't recall having any extra cflags for pthreads or gpac, so it might be the fprofile like dragon suggested? Who knows.

[akupenguin]

how did you compile pthreads and gpac? IIRC if you optimize those 2 with MMX too you could get a nice speed boost in certain situations.
... No.
If you spend any measurable amount of time in a muxer, you're doing something wrong.
And while there are SSE3 optimizations possible for threading, they're privileged instructions. i.e. the OS can use them but no user-level library can.

[Sharktooth]

optimizing gpac is not necessary, however, i remember (i could be also easily wrong!) when i optimized pthreads there was a around 1-2% increase in x264 encoding speed.
that was so long ago though and i may be wrong as well...
the speed difference may also come from the gcc version used and profiling.
ill upload the skystrife build into megui autoupdate to see if MeGUI users notice any speed difference.

[skystrife]

x264.920.modified.exe (http://www.mediafire.com/?dwxxwcvhe2d) - Alternate Download (http://skystrife.com/x264/x264.920.modified.exe)
(Source) (http://www.mediafire.com/?iwgngyggtit) - Alternate Download (http://skystrife.com/x264/x264.920.modified.source.7z)

Patches used:

x264_psyRDO_0.5.diff
x264_hrd_pulldown.09_interlace.diff
x264.progress.indication.01.diff

All patches are included with the source.

gcc 3.4.5 fprofiled build.

[Sharktooth]

request: modified build with usual patches + new bframes decision patch (if available) for speed testing...

[Dark Shikari]

request: modified build with usual patches + new bframes decision patch (if available) for speed testing...Here's the patch (http://pastebin.com/d495ce2e). Please do not use it any ordinary patched builds--this is just for your testing.

[Sharktooth]

as i said... for testing so i can see the speed difference and test the future megui changes needed to support it.
i will NOT include the build in megui auto-update until it's committed to git ... if this is what you mean...

[bob0r]

FOR TESTING PURPOSES ONLY

x264.920.new.bframes.decision.01.exe (http://files.x264.nl/x264.920.new.bframes.decision.01.exe)

[Sharktooth]

thanx

[bob0r]

I would probably say that's within the margin of error, but it may have something to do with the build environment and cflags.

Can you share your fprofile sample + script used to make your .exe?

Also post how you compile x264.exe
(i use configure and make, or make fprofiled, no extra flags)

Also please test my files: x264 920 gcc 3.4.5 versus 3.4.6, please test! (http://forum.doom9.org/showthread.php?p=1163184)

Edit:
Also what yasm version do you use? Even though pengvado explained to me, a different yasm version cannot make a speed difference.
It can solve bugs, its worth testing. i use 0.6.2.

[Sharktooth]

what's your configure commandline?
try with this:

--enable-avis-input --enable-mp4-output --enable-pthread -march=pentium2 -mmmx -O3 -finline-functions -funroll-loops -ffast-math -fomit-frame-pointer

make fprofiled VIDS="../video.yuv"

some options may be reduntant and can be removed (like -mmmx...)
gcc 3.4 is faster than 4.x. at least on my pc. 3.4.5 and 3.4.6 should produce almost the same speeds. i would use 3.4.6 though.

[kemuri-_9]

practically all of those options are redundant, the configure script automatically checks for gpac and pthread existence when it runs:
pthreads - checks for libpthread(GC2).a in lib dir(s) and pthread.h in include dir(s)
gpac - checks for libgpac_static.a in lib dir(s) and gpac/isomedia.h in include dir(s)
avis input - automaticly enabled when building on MINGW/CYGWIN system.

configure automatically adds -O4 and -ffast-math flags;
-funroll-loops is assumed with fprofiling
-finline-functions is assumed at -O3
-fomit-frame-pointer is assumed at -O and higher
-mmmx should be implied with -march=pentium2 as gcc creates code optimized for the pentium2 which has mmx capabilities.

so the only one out of all of those that actually does something is -march=pentium2
oh and don't forget if you give it a yuv to profile with, it needs the resolution in the name, but since you're more than likely building on mingw for the windows version, you can give it an avisynth script granted you have avisynth installed.

[Dark Shikari]

-fomit-frame-pointer is assumed at -O and higherOnly on 64-bit machines, I think?

But yes, -march=i686 -O3 -fomit-frame-pointer should be fine... and the latter two are already on by default!

[kemuri-_9]

whatever
-O also turns on -fomit-frame-pointer on machines where doing so does not interfere with debugging.
implies on i686-pc-mingw... but yes, it's already in the configure regardless...

oh yes, according to the gcc manual again, march=i686 does not include mmx instructions, so should use march=pentium2 which does have them.

[Adub]

what exactly is the advantage of fprofiling? Is it something that I can do on my x64 gentoo build?

[LoRd_MuldeR]

what exactly is the advantage of fprofiling? Is it something that I can do on my x64 gentoo build?

The code is analyzed while actually running. This allows the compiler to do optimization that cannot be done by just "looking" at the sources.
In software engineering, performance analysis, more commonly profiling, is the investigation of a program's behavior using information gathered as the program runs (i.e. it is a form of dynamic program analysis, as opposed to static code analysis). The usual goal of performance analysis is to determine which parts of a program to optimize for speed or memory usage.

Should be possible to run "make fprofiled" with every build that is made using GCC ...

[kemuri-_9]

you can fprofile on any system by giving it a/several video file(s) the x264 compiled on that system can recognize in the
make fprofiled VIDS=infile1 infile2 ..."
on linux that would be more than likely a .y4m which can created from wine'ing avs2yuv which was created by akupengiun (iirc) for linux based encoding...
that is if you don't already have something that can write .y4m files.

[LoRd_MuldeR]

Or you can grab one of the samples from here:
http://meru.cecs.missouri.edu/free_download/videos/

Simply rename "foreman_cif" to "foreman_cif.352x288.yuv" and that's it ;)

make fprofiled VIDS="/c/samples/foreman_cif.352x288.yuv"

[Selur]

just wondering would it be a good idea to use also high resolution files for fprofile?

[skystrife]

Can you share your fprofile sample + script used to make your .exe?

Also post how you compile x264.exe
(i use configure and make, or make fprofiled, no extra flags)

Also please test my files: x264 920 gcc 3.4.5 versus 3.4.6, please test! (http://forum.doom9.org/showthread.php?p=1163184)

Edit:
Also what yasm version do you use? Even though pengvado explained to me, a different yasm version cannot make a speed difference.
It can solve bugs, its worth testing. i use 0.6.2.

I use a 100 frame 1080p sample from Elephants Dream (image sequence, yay avisynth input), 200 frames 640x480 from Dark Shikari's Lossless Touhou sample (lossless h264, an encoder torture clip; it can be found on here, I can do a search if you want), and a 200 frame 1080p image sequence of a huge crowd running (and now that I think about it, I don't even remember where I got that... I could probably dig around and find it though).

./configure --extra-cflags="-march=pentium2"
make fprofiled VIDS='elephants_dream.avs LosslessTouhou.avs crowd.avs'

YASM version is 0.7.1.

I can upload the fprofile samples somewhere if it's needed, it's just a lot of data.

[Dark Shikari]

I use a 100 frame 1080p sample from Elephants Dream (image sequence, yay avisynth input), 200 frames 640x480 from Dark Shikari's Lossless Touhou sample (lossless h264, an encoder torture clip; it can be found on here, I can do a search if you want), and a 200 frame 1080p image sequence of a huge crowd running (and now that I think about it, I don't even remember where I got that... I could probably dig around and find it though).

./configure --extra-cflags="-march=pentium2"
make fprofiled VIDS='elephants_dream.avs LosslessTouhou.avs crowd.avs'

YASM version is 0.7.1.

I can upload the fprofile samples somewhere if it's needed, it's just a lot of data.The Crowdrun sequence is actually a 2160p sample I posted a while back. LosslessTouhou.mkv can be found here (http://mirror05.x264.nl/Dark/LosslessTouhou.mkv).

[akupenguin]

-O also turns on -fomit-frame-pointer on machines where doing so does not interfere with debugging.
-fomit-frame-pointer does interfere with debugging on x86.
It is theoretically possible for a compiler to record its planned stack offset at every instruction that modifies the stack, and then a debugger can find the stack frames without having a reserved frame pointer. But I don't know of any object format that actually allows that, and so frame pointer is useful for debugging on all architectures I know of.

[kemuri-_9]

The Crowdrun sequence is actually a 2160p sample I posted a while back..

did that originate from
ftp://vqeg.its.bldrdoc.gov/HDTV/SVT_MultiFormat/2160p50_CgrLevels_Master_SVTdec05_/1_CrowdRun_2160p50_CgrLevels_MASTER_SVTdec05_/
?

[Dark Shikari]

did that originate from
ftp://vqeg.its.bldrdoc.gov/HDTV/SVT_MultiFormat/2160p50_CgrLevels_Master_SVTdec05_/1_CrowdRun_2160p50_CgrLevels_MASTER_SVTdec05_/
?Yup, it did.

[LoRd_MuldeR]

ehm, what to do with those .sgi files? :o

[Dark Shikari]

ehm, what to do with those .sgi files? :oimagemagick -> convert to png -> imagesource

[akupenguin]

imagemagick -> convert to yuv -> cat

[LoRd_MuldeR]

imagemagick -> convert to png -> imagesource
imagemagick -> convert to yuv -> cat

:D

I'll try Imagemagick then :thanks:

[Dethis]

imagemagick -> convert to yuv -> cat

Why not sgi2yuv ??

The companion pdf
ftp://vqeg.its.bldrdoc.gov/HDTV/SVT_MultiFormat/SVT_MultiFormat_v10.pdf

suggests just this
http://www.ldv.ei.tum.de/Members/tobias/videotools/sgi2yuv.zip/view?set_language=en

[akupenguin]

Because sgi2yuv is a specialized program. If I had a separate program for each pair of formats I wanted to convert between, I'd need O(N^2) programs total.

[Dethis]

Sorry for not been clear.

Not being familiar whith any of them, i wonder if there are any quality differencies between sgi2yuv/ImageMajic sgi to yuv convertions

[Lux Delux]

Hi, first thanks for the patches :)

Few days ago I switched to Vista x64 and noticed a severe FPS drop in 2nd pass (during first pass it's 1fps slower than in XP). Actually it starts rather normal going from 1.5 fps to somewhere around 2.5 and at about 0.6% of the pass it drops to 0.3 fps and stays around that :eek:

Am encoding an .avs to mkv with Udegrain (with fft3dgpu), latest Megui with last skystrife patched build http://forum.doom9.org/showthread.php?p=1163061#post1163061

Am just wondering if someone has an idea for this strange behaviour and if it's connected to the build or perhaps fft3dgpu not operating properly under x64 (though then I missed the thread completely.)

EDIT: along with the FPS the CPU usage drops basically to idle or none. Thus I assume there's some bottleneck (am in a hurry now gonna try without avs scripts later to see if that's the prob)

Searched the forum but couldn't find anything. Cheers :)

[lexor]

Do you switch user accounts while it's working? Maybe you have it so it goes to user selection screen once it resumes from screen saver? If you do that, it will mess with fft3dgpu. Officially that has been fixed since 0.6. Unofficially if you still get it (like me) you are screwed. Just make sure you don't switch users (not necessarily load other users, just going to the user selection screen is enough to break it).

[Adub]

Thanks very much for the info. I'll wait till i get back to Uni, and then download those samples and get fprofiling!!

[Ranguvar]

I had the same problem as Lux Deluxe... Thanks, lexor!

[Lux Delux]

That wasn't my problem though... but it seems my own stupidity as I put FFTW3.DLL in system32 instead of sysWOW64 DOH!:o Seems to be running fine now.

Anyways sorry for going off topic since it turned out to be a an avs prob. Cheers again to all for the hard work with x264 :)

[skystrife]

x264.920.modified.02.exe (http://www.mediafire.com/?lxgztx3yg3y) - Alternate Download (http://skystrife.com/x264/x264.920.modified.02.exe)
(Source) (http://www.mediafire.com/?wxll0xwe0yy) - Alternate Download (http://skystrife.com/x264/x264.920.modified.02.source.7z)

Patches used:

x264_psyRDO_0.5.diff
x264_hrd_pulldown.09_interlace.diff
x264.progress.indication.01.diff
x264_new_bframe_decision_02.diff <-- This patch is highly experimental and has caused crashes on my end. It is enabled by adding --b-adapt 2 to the command line. I would recommend only doing this for testing.

All patches are included with the source.

gcc 3.4.5 fprofiled build.

EDIT: To be fair, it might be a confliction with the patches. I have no idea, to be honest. =P

[kemuri-_9]

If anyone wanted that 2160p50fps crowdrun sample but didn't want the hassle of going through all the downloading and converting for it, I converted it to xvid q2 which drastically brought the size down from the original 23 GB to about 625 MB.

I couldn't manage to grab the last few frames though, they kept giving me permission denied....
http://kemuri9.net/dev/x264/samples/crowdrun_xvid_q2.avi
if you want it.
if you just want a couple frames in png, then can also get them from
http://kemuri9.net/dev/x264/samples/crowdrun/

[LoRd_MuldeR]

If anyone wanted that 2160p50fps crowdrun sample but didn't want the hassle of going through all the downloading and converting for it, I converted it to xvid q2 which drastically brought the size down from the original 23 GB to about 625 MB.

I couldn't manage to grab the last few frames though, they kept giving me permission denied....
http://kemuri9.net/dev/x264/samples/crowdrun_xvid_q2.avi
if you want it.
if you just want a couple frames in png, then can also get them from
http://kemuri9.net/dev/x264/samples/crowdrun/

:thanks:

[bob0r]

x264.922.modified.01.exe (http://files.x264.nl/x264.922.modified.01.exe)
libx264-60.922.modified.01.dll (http://files.x264.nl/libx264-60.922.modified.01.dll)

x264-psyrd-0.5.diff
x264_hrd_pulldown.09_interlace.diff
x264.progress.indication.01.diff

[TL0]

Can someone compile a version with x264_new_bframe_decision patch?

:thanks:

[gigah72]

Can someone compile a version with x264_new_bframe_decision patch?

:thanks:

http://www.mediafire.com/?zb0dgxly1gc

with:
bframe patch: http://pastebin.com/m2a557e16
x264-psyrd-0.5.diff
x264_hrd_pulldown.09_interlace.diff
x264.progress.indication.01.diff

[gav1577]

Hi the above build ^ does not work for me can anyone confirm ? thanks

[martino]

Works fine here.

[gav1577]

Works fine here.
Thats odd does not work for me with --b-adapt 2 However skystrife's 920 Build does :confused:

EDIT: I found the problem the build for some reason will not work with a custom cqm where as skystrife's build will. I know its not recommended to use a cqm with psyrd but thought i should let it be known just in case its a bug :-)

[bob0r]

x264.928.modified.01.exe (http://files.x264.nl/x264.928.modified.01.exe)
libx264-60.928.modified.01.dll (http://files.x264.nl/libx264-60.928.modified.01.dll)

x264-psyrd-0.5.diff
x264_hrd_pulldown.09_interlace.diff
x264.progress.indication.01.diff

[le_canz]

I apologise if I'm asking a dumb question, but....

I try to keep following x264 development, and I'm wondering why the HRD patch isn't commited into git, as it is required to generate blu-ray compliant streams ?

Or maybe I have completely misunderstood how blu-ray compliant streams are outputed ?

Anyway, thanks to all the people involved in x264 ; developpers as well as providers of experimental / patched builds :thanks:

[bkman]

Just a note that I also get a crash, at the very start of pass 2 with this build http://forum.doom9.org/showthread.php?p=1164702#post1164702 and --b-adapt 2 enabled.

commandline:
"C:\Apps\megui\tools\x264\x264.exe" --pass 2 --bitrate 1918 --stats "H:\Encoding\Commando\hfyu_Commando3.stats" --level 4.1 --min-keyint 24 --ref 5 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --b-rdo --bime --weightb --direct auto --filter -2,-1 --subme 7 --trellis 2 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --ratetol 2 --me umh --merange 24 --threads auto --thread-input --sar 629:450 --progress --no-dct-decimate --output "H:\Encoding\Commando\hfyu_Commando301.mkv" "H:\Encoding\Commando\hfyu_Commando3.avs" --keyint 1500 --b-adapt 2

[gigah72]

removed,
build crashes on 2-pass encode

[skystrife]

x264.928.modified.exe (http://www.mediafire.com/?yxjg93s1lys) - Alternate Download (http://skystrife.com/x264/x264.928.modified.exe)
libx264-61.928.modified.dll (http://www.mediafire.com/?9xscjgmn2cj) - Alternate Download (http://skystrife.com/x264/libx264-61.928.modified.dll)
(Source) (http://www.mediafire.com/?ud9gdgvdctg) - Alternate Download (http://skystrife.com/x264/x264.928.modified.source.7z)

Patches used:

x264_psyRDO_0.5.diff
x264_hrd_pulldown.09_interlace.diff
x264.progress.indication.01.diff
x264_new_bframe_decision_03.diff <-- This patch is highly experimental, but no longer crashes on my end. Thank you Dark Shikari!

All patches are included with the source.

gcc 3.4.5 fprofiled build.

[gav1577]

Thanks for the ^build^ skystrife ;)

[elguaxo]

thanks skystrife!

[MythCreator]

@Skystrife:

Where could I get x264_new_bframe_decision_03.diff ? Thanks~

[Yoshiyuki Blade]

@Skystrife:

Where could I get x264_new_bframe_decision_03.diff ? Thanks~

It's in the 7zip file along with the source and other patches (3rd link) :p

[MythCreator]

There is something strange..I Set bitrate=4640Kbps ，Two passes，but the final bitrate is 4822.92Kbps..

Settings:

1st pass:
--cqmfile "M4G_High_Detail_V3.1.cfg" --no-fast-pskip --no-dct-decimate --mixed-refs --scenecut 40 -I 90 -i 25 --me umh --merange 32 --sar 1:1 --threads 3 -r 6 --nr 0 -f -2:-1 -b 16 --direct "auto" --bime --b-bias 0 --b-pyramid -w --deadzone-inter 4 --deadzone-intra 6 --aq-mode 0 --chroma-qp-offset 0 --direct-8x8 1 -p 1 -B 4640 --qpmin 10 --qpmax 51 --8x8dct -A p8x8,p4x4,b8x8,i8x8,i4x4 --ipratio 1.400000 --pbratio 1.300000 -m 7 --b-rdo --ratetol 1.000000 --vbv-init 0.9

2nd pass:
--cqmfile "M4G_High_Detail_V3.1.cfg" --no-fast-pskip --no-dct-decimate --mixed-refs --scenecut 40 -I 90 -i 25 --me umh --merange 32 --sar 1:1 --threads 3 -r 6 --nr 0 -f -2:-1 -b 16 --direct "auto" --bime --b-bias 0 --b-pyramid -w --deadzone-inter 4 --deadzone-intra 6 --aq-mode 0 --chroma-qp-offset 0 --direct-8x8 1 -p 3 -B 4640 --qpmin 10 --qpmax 51 --qpstep 4 --qcomp 0.900000 --ipratio 1.400000 --pbratio 1.300000 --8x8dct -A p8x8,p4x4,b8x8,i8x8,i4x4 -m 7 --b-rdo --ratetol 1.000000 --vbv-init 0.9


Log：


x264 [info]: slice I:9 Avg QP:18.00 size: 98327 PSNR Mean Y:53.52 U:52.63 V:51.76 Avg:52.89 Global:51.94
x264 [info]: slice P:144 Avg QP:18.23 size: 52380 PSNR Mean Y:51.69 U:52.74 V:52.10 Avg:51.87 Global:51.31
x264 [info]: slice B:348 Avg QP:19.81 size: 14616 PSNR Mean Y:50.94 U:52.43 V:51.92 Avg:51.28 Global:50.59
x264 [info]: consecutive B-frames: 6.1% 14.2% 6.7% 16.3% 16.3% 35.4% 2.8% 0.0% 0.0% 0.0% 2.2% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0%
x264 [info]: mb I I16..4: 22.1% 72.2% 5.8%
x264 [info]: mb P I16..4: 6.8% 14.1% 0.8% P16..4: 48.9% 10.9% 5.9% 0.1% 0.0% skip:12.5%
x264 [info]: mb B I16..4: 0.6% 0.9% 0.1% B16..8: 34.0% 1.0% 1.2% direct: 1.9% skip:60.4% L0:46.9% L1:43.6% BI: 9.5%
x264 [info]: final ratefactor: 20.15
x264 [info]: 8x8 transform intra:65.8% inter:30.6%
x264 [info]: direct mvs spatial:93.4% temporal:6.6%
x264 [info]: ref P L0 73.8% 15.9% 5.7% 2.2% 1.3% 1.0%
x264 [info]: ref B L0 82.9% 11.5% 3.6% 1.4% 0.6%
x264 [info]: ref B L1 95.8% 4.2%
x264 [info]: SSIM Mean Y:0.9947734
x264 [info]: PSNR Mean Y:51.201 U:52.521 V:51.966 Avg:51.479 Global:50.809 kb/s:5173.88


x264 [info]: slice I:9 Avg QP:17.11 size:102517 PSNR Mean Y:53.82 U:52.51 V:51.71 Avg:52.99 Global:52.51
x264 [info]: slice P:144 Avg QP:19.10 size: 47634 PSNR Mean Y:51.47 U:52.48 V:51.80 Avg:51.63 Global:51.34
x264 [info]: slice B:348 Avg QP:20.53 size: 13832 PSNR Mean Y:50.75 U:52.30 V:51.75 Avg:51.10 Global:50.79
x264 [info]: consecutive B-frames: 6.1% 14.2% 6.7% 16.3% 16.3% 35.4% 2.8% 0.0% 0.0% 0.0% 2.2% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0%
x264 [info]: mb I I16..4: 20.2% 74.5% 5.3%
x264 [info]: mb P I16..4: 7.0% 14.0% 0.6% P16..4: 49.3% 9.0% 5.4% 0.1% 0.0% skip:14.6%
x264 [info]: mb B I16..4: 0.5% 0.8% 0.1% B16..8: 32.8% 0.8% 0.9% direct: 1.6% skip:62.4% L0:47.0% L1:41.8% BI:11.2%
x264 [info]: 8x8 transform intra:66.1% inter:29.0%
x264 [info]: direct mvs spatial:88.5% temporal:11.5%
x264 [info]: ref P L0 72.6% 17.2% 5.7% 2.2% 1.3% 1.1%
x264 [info]: ref B L0 82.7% 12.0% 3.3% 1.3% 0.6%
x264 [info]: ref B L1 96.2% 3.8%
x264 [info]: SSIM Mean Y:0.9947686
x264 [info]: PSNR Mean Y:51.014 U:52.352 V:51.766 Avg:51.286 Global:50.967 kb/s:4822.15


encoded 501 frames, 0.65 fps, 4822.92 kb/s




using skystrife's build

[buzzqw]

@MythCreator

please try without a custom matrix

BHH

[Sharktooth]

501 frames. the clip is too short.

[kemuri-_9]

--deadzone-inter 4 --deadzone-intra 6 --aq-mode 0 --qcomp 0.900000

I would speculate the reason would lie in those settings, though i'm not exactly sure what your cqmfile contains.

[gav1577]

x264.928.modified.exe (http://www.mediafire.com/?yxjg93s1lys) - Alternate Download (http://skystrife.com/x264/x264.928.modified.exe)
libx264-61.928.modified.dll (http://www.mediafire.com/?9xscjgmn2cj) - Alternate Download (http://skystrife.com/x264/libx264-61.928.modified.dll)
(Source) (http://www.mediafire.com/?ud9gdgvdctg) - Alternate Download (http://skystrife.com/x264/x264.928.modified.source.7z)

Patches used:

x264_psyRDO_0.5.diff
x264_hrd_pulldown.09_interlace.diff
x264.progress.indication.01.diff
x264_new_bframe_decision_03.diff <-- This patch is highly experimental, but no longer crashes on my end. Thank you Dark Shikari!

All patches are included with the source.

gcc 3.4.5 fprofiled build.

Hi this build also crashes for me at the beginning of the second pass the odd thing is it does not crash if just doing small clips but will crash if doing a whole movie btw build x264.920.modified.02.exe seems fine

[ajp_anton]

Why does these builds crash on the 2nd pass? The b-frame patch doesn't do anything in the 2nd pass, right?

[LoRd_MuldeR]

Why does these builds crash on the 2nd pass? The b-frame patch doesn't do anything in the 2nd pass, right?

I made a similar experience. With b_adapt=2 it will always crash near the end of the second pass.
But after a comment by Dark Shikari I thought that it's an Avidemux specific problem. Do you get the crash with x264.exe ???

[Dark Shikari]

I've had no issues with --b-adapt 2 on second pass... maybe I haven't tested enough or something? It strikes me as odd...

[elguaxo]

Do you get the crash with x264.exe ???

I ran a couple of small tests and it was fine with --b-adapt 2 (1st and 2nd pass). Now I'm encoding a DVD with some insane settings so it will take some time to see if it crashes on the second pass. :scared: :p

[gav1577]

Does seem odd clips seem fine but whole movies crash must be something to do with changes made after x264.920.modified.02 because that build seems stable so far :) btw i haven't tried dvd only a rip of my bluray movie

[DeeGee]

Same problem here. Build 928 crashes right on the beginning of pass 2, but build 920 seems to be working (only just begun the encoding. ~4 hours to go).

E:\DVD\TGTBTU_D124\VIDEO_TS>x264 --bframes 5 --b-adapt 2 --b-pyramid --ref 5 --d
eblock -2:0 --bitrate 932 --pass 1 --partitions none --direct auto --weightb --m
e dia --subme 1 --b-rdo --psy-rd 1.2 --bime --8x8dct --trellis 0 --sar 64:45 --p
rogress --threads auto --thread-input --output NUL "The Good, The Bad and The Ug
ly.avs"
avis [info]: 704x432 @ 25.00 fps (257037 frames)
x264 [info]: using SAR=64/45
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: slice I:2060 Avg QP:22.69 size: 28632 PSNR Mean Y:41.53 U:47.83
V:47.99 Avg:42.78 Global:42.00
x264 [info]: slice P:97892 Avg QP:24.83 size: 7824 PSNR Mean Y:39.06 U:46.43
V:46.61 Avg:40.42 Global:39.67
x264 [info]: slice B:157085 Avg QP:26.99 size: 2361 PSNR Mean Y:38.47 U:46.37
V:46.57 Avg:39.88 Global:39.28
x264 [info]: consecutive B-frames: 3.6% 25.6% 55.7% 9.8% 3.6% 1.7%
x264 [info]: mb I I16..4: 11.7% 40.9% 47.4%
x264 [info]: mb P I16..4: 10.8% 0.0% 0.0% P16..4: 71.6% 0.0% 0.0% 0.0% 0
.0% skip:17.7%
x264 [info]: mb B I16..4: 1.6% 0.0% 0.0% B16..8: 19.6% 0.0% 0.0% direct:
15.6% skip:63.3% L0:36.4% L1:46.8% BI:16.8%
x264 [info]: final ratefactor: 23.02
x264 [info]: 8x8 transform intra:5.6% inter:65.2%
x264 [info]: direct mvs spatial:99.9% temporal:0.1%
x264 [info]: ref P L0 56.0% 21.1% 9.5% 6.5% 6.9%
x264 [info]: ref B L0 66.7% 20.0% 8.8% 4.5%
x264 [info]: ref B L1 90.6% 9.4%
x264 [info]: SSIM Mean Y:0.9557316
x264 [info]: PSNR Mean Y:38.723 U:46.406 V:46.598 Avg:40.107 Global:39.442 kb/s:
930.45

encoded 257037 frames, 33.01 fps, 930.52 kb/s

E:\DVD\TGTBTU_D124\VIDEO_TS>x264 --bframes 5 --b-adapt 2 --b-pyramid --ref 5 --d
eblock -2:0 --bitrate 932 --pass 2 --partitions all --direct auto --weightb --me
umh --subme 7 --b-rdo --psy-rd 1.2 --bime --8x8dct --trellis 2 --sar 64:45 --pr
ogress --threads auto --thread-input --output "The Good, The Bad and The Ugly_vi
deo.mp4" "The Good, The Bad and The Ugly.avs"
avis [info]: 704x432 @ 25.00 fps (257037 frames)
x264 [info]: using SAR=64/45
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
--------Crash--------

-----Change to build 920-------
E:\DVD\TGTBTU_D124\VIDEO_TS>x264 --bframes 5 --b-adapt 2 --b-pyramid --ref 5 --d
eblock -2:0 --bitrate 932 --pass 2 --partitions all --direct auto --weightb --me
umh --subme 7 --b-rdo --psy-rd 1.2 --bime --8x8dct --trellis 2 --sar 64:45 --pr
ogress --threads auto --thread-input --output "The Good, The Bad and The Ugly_vi
deo.mp4" "The Good, The Bad and The Ugly.avs"
avis [info]: 704x432 @ 25.00 fps (257037 frames)
x264 [info]: using SAR=64/45
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
mp4 [info]: initial delay 2 (scale 25)
encoded frames: 6426/257037 (2.5%), 18.58 fps, eta 3:44:47

[G_M_C]

My version (skystrife's build) is working fine, with both --b-adapt 2 --weightb in both passes.

It's @ 60% of a 2 hours long film (@1080p) in the second pass. It is quite slow thought, even if i try to get it all @ L4.1 and BR compatabillity (3-bframes, 4 refs etc.), it's only going @ 2,8 ~ 3 fps.

[kemuri-_9]

though i'm using my own build with the same patches, everything is working normally with --b-adapt 2 on both passes.

[Soichiro]

I've never had any crashes either with skystrife's build or my own build.

[elguaxo]

I ran a couple of small tests and it was fine with --b-adapt 2 (1st and 2nd pass). Now I'm encoding a DVD with some insane settings so it will take some time to see if it crashes on the second pass. :scared: :p

no crashes during a DVD encode using --b-adapt 2 on the 1st and 2nd pass! :)

[woah!]

Same problem here. Build 928 crashes right on the beginning of pass 2, but build 920 seems to be working (only just begun the encoding. ~4 hours to go).

E:\DVD\TGTBTU_D124\VIDEO_TS>x264 --bframes 5 --b-adapt 2 --b-pyramid --ref 5 --d
eblock -2:0 --bitrate 932 --pass 1 --partitions none --direct auto --weightb --m
e dia --subme 1 --b-rdo --psy-rd 1.2 --bime --8x8dct --trellis 0 --sar 64:45 --p
rogress --threads auto --thread-input --output NUL "The Good, The Bad and The Ug
ly.avs"
avis [info]: 704x432 @ 25.00 fps (257037 frames)
x264 [info]: using SAR=64/45
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: slice I:2060 Avg QP:22.69 size: 28632 PSNR Mean Y:41.53 U:47.83
V:47.99 Avg:42.78 Global:42.00
x264 [info]: slice P:97892 Avg QP:24.83 size: 7824 PSNR Mean Y:39.06 U:46.43
V:46.61 Avg:40.42 Global:39.67
x264 [info]: slice B:157085 Avg QP:26.99 size: 2361 PSNR Mean Y:38.47 U:46.37
V:46.57 Avg:39.88 Global:39.28
x264 [info]: consecutive B-frames: 3.6% 25.6% 55.7% 9.8% 3.6% 1.7%
x264 [info]: mb I I16..4: 11.7% 40.9% 47.4%
x264 [info]: mb P I16..4: 10.8% 0.0% 0.0% P16..4: 71.6% 0.0% 0.0% 0.0% 0
.0% skip:17.7%
x264 [info]: mb B I16..4: 1.6% 0.0% 0.0% B16..8: 19.6% 0.0% 0.0% direct:
15.6% skip:63.3% L0:36.4% L1:46.8% BI:16.8%
x264 [info]: final ratefactor: 23.02
x264 [info]: 8x8 transform intra:5.6% inter:65.2%
x264 [info]: direct mvs spatial:99.9% temporal:0.1%
x264 [info]: ref P L0 56.0% 21.1% 9.5% 6.5% 6.9%
x264 [info]: ref B L0 66.7% 20.0% 8.8% 4.5%
x264 [info]: ref B L1 90.6% 9.4%
x264 [info]: SSIM Mean Y:0.9557316
x264 [info]: PSNR Mean Y:38.723 U:46.406 V:46.598 Avg:40.107 Global:39.442 kb/s:
930.45

encoded 257037 frames, 33.01 fps, 930.52 kb/s

E:\DVD\TGTBTU_D124\VIDEO_TS>x264 --bframes 5 --b-adapt 2 --b-pyramid --ref 5 --d
eblock -2:0 --bitrate 932 --pass 2 --partitions all --direct auto --weightb --me
umh --subme 7 --b-rdo --psy-rd 1.2 --bime --8x8dct --trellis 2 --sar 64:45 --pr
ogress --threads auto --thread-input --output "The Good, The Bad and The Ugly_vi
deo.mp4" "The Good, The Bad and The Ugly.avs"
avis [info]: 704x432 @ 25.00 fps (257037 frames)
x264 [info]: using SAR=64/45
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
--------Crash--------

-----Change to build 920-------
E:\DVD\TGTBTU_D124\VIDEO_TS>x264 --bframes 5 --b-adapt 2 --b-pyramid --ref 5 --d
eblock -2:0 --bitrate 932 --pass 2 --partitions all --direct auto --weightb --me
umh --subme 7 --b-rdo --psy-rd 1.2 --bime --8x8dct --trellis 2 --sar 64:45 --pr
ogress --threads auto --thread-input --output "The Good, The Bad and The Ugly_vi
deo.mp4" "The Good, The Bad and The Ugly.avs"
avis [info]: 704x432 @ 25.00 fps (257037 frames)
x264 [info]: using SAR=64/45
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
mp4 [info]: initial delay 2 (scale 25)
encoded frames: 6426/257037 (2.5%), 18.58 fps, eta 3:44:47

long shot but is it a VC1 source? if so are you using ffdshow codec wmv9. if so try using libavcodec instead in the codec list.

[gav1577]

long shot but is it a VC1 source? if so are you using ffdshow codec wmv9. if so try using libavcodec instead in the codec list.

Hi i have the same problem as DeeGee crashes rite at the beginning of the second pass i am using ripbot264 with a modified cmd the source is an bluray 1080p MPEG-2 i will test with megui and ffdshow i think ripbot uses DGindex for MPEG-2. i cant see dgindex being a problem though as 920 works fine :confused:

EDIT: tried megui and ffdshow same result crashed at the beginning of second pass :(. will stick with 920

[DeeGee]

Yep, using dgindex for dvd source. Build 920 finished encoding without problems.

[Sharktooth]

Hi i have the same problem as DeeGee crashes rite at the beginning of the second pass i am using ripbot264 with a modified cmd the source is an bluray 1080p MPEG-2 i will test with megui and ffdshow i think ripbot uses DGindex for MPEG-2. i cant see dgindex being a problem though as 920 works fine :confused:

EDIT: tried megui and ffdshow same result crashed at the beginning of second pass :(. will stick with 920
easy, dont use that patch for "production".
you were already warned.
also if you use megui, keep the x264 build that comes with the autoupdate.

[G_M_C]

My version (skystrife's build) is working fine, with both --b-adapt 2 --weightb in both passes.

It's @ 60% of a 2 hours long film (@1080p) in the second pass. It is quite slow thought, even if i try to get it all @ L4.1 and BR compatabillity (3-bframes, 4 refs etc.), it's only going @ 2,8 ~ 3 fps.


Yep, my encode came out fine too. Quality is very good; I havent been making X264's long, but i'm impressed.

1 small question: Skystrife's build did have --psyRDO on by default didn't it ?

My compliments go out to Dark Shikari, Akupenguin and other developers for all their quality-improving paches !

[martino]

1 small question: Skystrife's build did have --psyRDO on by default didn't it ?
All builds with the patch do, unless someone modifies the source code to do the opposite.

[lexor]

1 small question: Skystrife's build did have --psyRDO on by default didn't it ?

Only if you used --subme 6 or 7.

[LoRd_MuldeR]

Only if you used --subme 6 or 7.

Because Psy RDO cannot work at subme < 6 :p

[lexor]

Because Psy RDO cannot work at subme < 6 :p

Was that irony in attempt to correct, or just a note? I can't tell.

[LoRd_MuldeR]

Was that irony in attempt to correct, or just a note? I can't tell.

You said that Psy RDO is on by default, but only when --subme 6 or 7 is used. Well, that is correct. But it sounds like one could still enforce Psy RDO at subme < 6, it just won't be enabled by default at subme < 6. And that assumption would be wrong. So I wanted to make clear that Psy RDO can never work at subme < 6. That's it...

[G_M_C]

Only if you used --subme 6 or 7.

Well ... i did, so i'm good :p

[kemuri-_9]

x264 --(long)help by default prints out the default options in [] for many parameters for when they are not specified explicitly on the command line, i.e.:

--psy-rd Strength of mode decision psychovisual optimization ["1.000000"]
Does nothing at subme < 6.
so if you ever have questions about if it's on, off, or what the value is, just consult the generated --longhelp

[skystrife]

x264.928.modified.02.exe (http://www.mediafire.com/?b8pgyufbqih) - Alternate Download (http://skystrife.com/x264/x264.928.modified.02.exe)
libx264-61.928.modified.02.dll (http://www.mediafire.com/?babhbhnaaqz) - Alternate Download (http://skystrife.com/x264/libx264-61.928.modified.02.dll)
(Source) (http://www.mediafire.com/?vnxv0iqpnmv) - Alternate Download (http://skystrife.com/x264/x264.928.modified.02.source.7z)

Patches used:

x264_psyRDO_0.5+psytrellis.diff <-- This patch is experimental. See the PsyRDO thread for more details.
x264_new_bframe_decision_03.diff <-- This patch is highly experimental.
x264_hrd_pulldown.09_interlace.diff
x264.progress.indication.01.diff

All patches are included with the source.

gcc 3.4.5 fprofiled build.

[gav1577]

Can someone please compile the new trellis patch in a regular build
without the bframe_decision patch for testing Thanks :)

[Dark Shikari]

Can someone please compile the new trellis patch in a regular build
without the bframe_decision patch for testing Thanks :)You know, you can just use --b-adapt 1 for the regular B-frame decision ;). In fact, I think its default.

[shon3i]

@DS, i realy confused how to turn on psytrellis? what switch?

[Dark Shikari]

@DS, i realy confused how to turn on psytrellis? what switch?Its just a modification to trellis that activates when psy-rd is on. To activate it, just have psy-rd and trellis both on.

[shon3i]

trellis 1 or 2?

[Yoshiyuki Blade]

trellis 1 or 2?

I'm pretty sure either mode will work.

[gav1577]

You know, you can just use --b-adapt 1 for the regular B-frame decision ;). In fact, I think its default.

Thanks i forgot about the --b-adapt 1 :)

[gav1577]

One question in have though is with the new patch is there any point in lowering the
chroma QP offset as i usually do now that it scales automatically ?

[martino]

trellis 1 or 2?
psy-rd is off with 1.

[Sharktooth]

D_S said the modified version of trellis (psy-trellis) can be both 1 or 2 when psy-rdo is enabled.
while the old/normal trellis version will be:
0 - disabled
1 - enabled on the final encode of macroblock if subme < 6, automatically disabled if subme >=6, always enabled on the final encode of macroblock if psy-rd is disabled (--psy-rd 0).
2 - always enabled on all all RD calls, in the final encode of macroblock and in any case.
psy-rd is enabled by defualt and always on unless you turn it off with --psy-rd 0

[Dark Shikari]

D_S said the modified version of trellis (psy-trellis) can be both 1 or 2 when psy-rdo is enabled.
while the old/normal trellis version will be:
0 - disabled
1 - enabled on I frames if subme < 6, automatically disabled if subme >=6. always enabled on I frames if psy-rd is disabled.
2 - always enabled on all kind of frames and in any case.
psy-rd is enabled by defualt and always on unless you turn it off with --psy-rd 0I'm noticing this a lot, but please don't respond unless you actually know the correct answer. It has nothing to do with frametype. Trellis 1 acts on the final encode of a macroblock--always. Trellis 2 acts on every RD call, in addition to the final encode.psy-rd is off with 1.No its not...One question in have though is with the new patch is there any point in lowering the
chroma QP offset as i usually do now that it scales automatically ?Probably not.

[Sharktooth]

argh... sorry, ill correct it (done), i confused it with another thing from another encoder...
today i have a bit of confusion in my head... i hope it is only a temporary effect of the meds.

[skystrife]

x264.930.modified.exe (http://www.mediafire.com/?ijadanmuaal) - Alternate Download (http://skystrife.com/x264/x264.930.modified.exe)
libx264-61.930.modified.dll (http://www.mediafire.com/?idjiacazwt4) - Alternate Download (http://skystrife.com/x264/libx264-61.930.modified.dll)
(Source) (http://www.mediafire.com/?87fkhdhj8ix) - Alternate Download (http://skystrife.com/x264/x264.930.modified.source.7z)

Patches used:

x264_psy_rdo.0.5+psy_trellis_01_r929.diff <-- This patch is experimental. See the PsyRDO thread for more details.
x264_new_bframe_decision_03.diff <-- This patch is highly experimental.
x264_hrd_pulldown.09_interlace.diff
x264.progress.indication.01.diff

All patches are included with the source.

gcc 3.4.5 fprofiled build.

[martino]

I see that nobody has posted yet a build without psy-trellis, so here (http://www.mediafire.com/?d4rjwwvqvrk) is one; r930 modified, for those that like them less experimental...

Patches:
x264.progress.indication.01.diff
x264.psyrdo.0.5.r929.diff (modified by kemuri)

gcc 3.4.5 fprofiled.

[DeeGee]

Seems like all the builds after (skystrife's) 920 keep crashing on pass 2. I guess i need to do some testing to isolate what causes it.

[edit] After doing all kinds of testing I couldn't get it to crash anymore... I guess I did something Stupid™ the first time around.

[gigah72]

Seems like all the builds after (skystrife's) 920 keep crashing on pass 2. I guess i need to do some testing to isolate what causes it.

is this happening on all your sources or just some, what kind of source do you have?
what x264 settings do you use?

[kemuri-_9]

I've been trying sky's builds for benchmarking against my own and they work for me on the settings i use for both passes.

didn't most of the people who were having crashes say they were using DGIndex/DGDecode?

[Blue_MiSfit]

I'm running Skystrife's patched 930 build tonight on a CRF20 SD encode, with most settings maxed out... We'll see if it turns out okay! 12fps and it's saturating my Q6600 (no filtering).

~MiSfit

[gav1577]

I see that nobody has posted yet a build without psy-trellis, so here (http://www.mediafire.com/?d4rjwwvqvrk) is one; r930 modified, for those that like them less experimental...

Patches:
x264.progress.indication.01.diff
x264.psyrdo.0.5.r929.diff (modified by kemuri)

gcc 3.4.5 fprofiled.

Thanks for the build ;)

[Ranguvar]

*wishes for an r934 build with DS's VAQ2, Psy RDO, Psy-Trellis, progress indication, nal-hrd, and the new b-frame decision patch* =]

Zanku!!

[skystrife]

x264.934.modified.exe (http://www.mediafire.com/?evnbmckbedf) - Alternate Download (http://skystrife.com/x264/x264.934.modified.exe)
libx264-61.934.modified.dll (http://www.mediafire.com/?iaabgzqapvk) - Alternate Download (http://skystrife.com/x264/libx264-61.934.modified.dll)
(Source) (http://www.mediafire.com/?dhu40zlwtiy) - Alternate Download (http://skystrife.com/x264/x264.934.modified.source.7z)

Patches used:

x264_psy_rdo.0.5+psy_trellis_01_r929.diff <-- This patch is experimental. See the PsyRDO thread for more details.
x264_new_bframe_decision_03.diff <-- This patch is highly experimental.
x264_hrd_pulldown.09_interlace.diff
x264.progress.indication.01.diff

All patches are included with the source.

gcc 3.4.5 fprofiled build.

[ajp_anton]

Using the build from the post above, I'm getting some strange artifacts when using multithreading. Is this kinda "known" or should I post pics?

[Dark Shikari]

Using the build from the post above, I'm getting some strange artifacts when using multithreading. Is this kinda "known" or should I post pics?You should upload a stream.

[ajp_anton]

I see differences between identical encodes, and not just small ones, and only in small parts of the picture. They are done on different computers (still a bug but could narrow it down).
Splitting them up into >1MB parts with mkvmerge creates 6, 12 and 16 parts for the 3 "identical" encodes.
Will do some more testing before I upload anything. I've noticed something strange with the official build too.

The streams should only be completely identical if multithreading is off, right?

[Dark Shikari]

The streams should only be completely identical if multithreading is off, right?Yes, two encodes with the same build and same settings and same source and same statsfile with no threads should be exactly the same.

[ajp_anton]

Did some test encodes over the night:

- Two of my computers produce identical streams while the 3rd is a bit different. Source is lagarith+avisource. Saved the avisynth stream into avi with VDub (direct stream copy) on all computers and they were all identical. Any ideas?
E4300 and X2 4400+ are identical, 3rd one is E4300 (just to show that it's not about the CPU).

- You'd think the artifacts (just some insane blocking (like 16x16 pixels of a single color)) comes from the somewhat low bitrate, but they just aren't there in singlethreaded encodes. But I was able to recreate them with... *drumroll*... --pre-scenecut. Making the first (and only the first) pass singlethreaded seems to help.
edit: The test clip I used has lots of <1s scenes, --min-keyint = 1s
edit: Oh, and this only occurs with --pre-scenecut and only with the patched build.

[Dark Shikari]

Did some test encodes over the night:

- Two of my computers produce identical streams while the 3rd is a bit different. Source is lagarith+avisource. Saved the avisynth stream into avi with VDub (direct stream copy) on all computers and they were all identical. Any ideas?
E4300 and X2 4400+ are identical, 3rd one is E4300 (just to show that it's not about the CPU).

- You'd think the artifacts (just some insane blocking (like 16x16 pixels of a single color)) comes from the somewhat low bitrate, but they just aren't there in singlethreaded encodes. But I was able to recreate them with... *drumroll*... --pre-scenecut. Making the first (and only the first) pass singlethreaded seems to help.
edit: The test clip I used has lots of <1s scenes, --min-keyint = 1s
edit: Oh, and this only occurs with --pre-scenecut and only with the patched build.Post the streams; are you using VBV? If so, its possible that the artifacting is due to VBV; x264 tries rather hard in 1pass mode to obey VBV strictly, which can result in significant quality drops. Don't use 1pass VBV unless you cannot use 2pass for some reason.

[ajp_anton]

Meh, VBV was it. Feels a bit stupid after all these tests and never even thinking of VBV. Well it's still a little strange when bitrate is 6000 and both VBV at 15000 (2-pass). Wonder why they even were 15000...
Anyway... I'm still a bit surprised how much --pre-scenecut changes things, and I still have no idea why this one computer's lagarith-avisynth output is different when using x264 but identical to the others' with VDub. Oh well, it's not that I can see the differences anyway...

[skystrife]

x264.935.modified.exe (http://www.mediafire.com/?rdmzpzu2jh0) - Alternate Download (http://skystrife.com/x264/x264.935.modified.exe)
libx264-61.935.modified.dll (http://www.mediafire.com/?db7hy1d2n7v) - Alternate Download (http://skystrife.com/x264/libx264-61.935.modified.dll)
(Source) (http://www.mediafire.com/?ojwl3gxj0e5) - Alternate Download (http://skystrife.com/x264/x264.935.modified.source.7z)

Patches used:

x264_psy_rdo.0.5+psytrellis_02.diff <-- This patch is experimental. See the PsyRDO thread for more details. Now allows controlling the strength of psyrdo and psytrellis individually.
x264_new_bframe_decision_04.diff (http://skystrife.com/x264/x264_new_bframe_decision_04.diff) <-- This patch is highly experimental. Only change from 03 is to remove the change of X264_BUILD in x264.h because the psytrellis patch already changes it.
x264_hrd_pulldown.09_interlace.diff
x264.progress.indication.01.diff

All patches are included with the source.

gcc 3.4.5 fprofiled build.

[Sharktooth]

request: r935 -> CLI build for megui
patches: psy-rdo
hrd-pulldown
progress indicarion - optional.
usual fprofiled build with gcc 3.4.x

[techouse]

Here you go Shark:

x264_x86_r935_techouse (http://techouse.project357.com/builds/x264_x86_r935_techouse.7z)

Source: x264 r935 GIT (git://git.videolan.org/x264.git)

Applied patches (current versions):

x264_progress.diff

x264_psy_rdo.0.5+psy_trellis_01_r929.diff

x264_hrd_pulldown.09_interlace.diff


Please check http://forum.doom9.org/showthread.php?t=130364 and http://git.videolan.org/gitweb.cgi?p=x264.git;a=shortlog for more info

Compiled by techouse on August 15th 2008, 16:00 CEST with GCC-4.3.1 on Windows Vista Ultimate SP-1 32-bit.

Commandline used: ./configure --extra-cflags="-march=core2 -pipe" && make fprofiled

Platform: X86
System: MINGW
asm: yes
avis input: yes
mp4 output: yes
pthread: yes
gtk: no
debug: no
gprof: no
PIC: no
shared: no
visualize: no

[Sharktooth]

-march=core2 ... no gprof.... :( sorry cant use it for megui autoupdate.
thanks anyway.

[gav1577]

Hi i have a request please for the latest build without psy trellis
just psy rdo Thanks :)

[Dark Shikari]

Hi i have a request please for the latest build without psy trellis
just psy rdo Thanks :)Latest psy-RD build lets you disable psy trellis... :p

[gav1577]

Latest psy-RD build lets you disable psy trellis... :p

Thanks for the info dark shikari :). so just to clarify to use old trellis and disable the new would this be correct --psy-rd 1:0 ? i am still still quite a noob at all this Thanks

[Dark Shikari]

Thanks for the info dark shikari :). so just to clarify to use old trellis and disable the new would this be correct --psy-rd 1:0 ? i am still still quite a noob at all this ThanksCorrect

[Sharktooth]

i think i will include the psy-trellis enabled build in megui. so i have to disable psy-trellis in presets or is almost safe to use it at default settings?

[Dark Shikari]

i think i will include the psy-trellis enabled build in megui. so i have to disable psy-trellis in presets or is almost safe to use it at default settings?Well hopefully I'm going to commit this soon so the bickering about it can stop. :p

[bob0r]

-march=core2 ... no gprof.... :( sorry cant use it for megui autoupdate.
thanks anyway.

gprof: no
All my builds have that too (its not fprofiled if you think that), do you?

[martino]

Hi i have a request please for the latest build without psy trellis
just psy rdo Thanks :)
If you still want one despite what DS said...

x264 r935 modified (http://users.shinsen-subs.org/martino/x264/x264.935.7z)

x264.progress.01
x264.psyrdo.05.r929.diff

gcc 3.4.5 fprofiled.

[skystrife]

x264.936.modified.exe (http://www.mediafire.com/?uc5xlvdtblh) - Alternate Download (http://skystrife.com/x264/x264.936.modified.exe)
libx264-61.936.modified.dll (http://www.mediafire.com/?a0qa6wbaqm0) - Alternate Download (http://skystrife.com/x264/libx264-61.936.modified.dll)
(Source) (http://www.mediafire.com/?mbplvdr0day) - Alternate Download (http://skystrife.com/x264/x264.936.modified.source.7z)

Patches used:

x264_psy_rdo.0.5+psytrellis_02.diff <-- This patch is experimental. See the PsyRDO thread for more details. Now allows controlling the strength of psyrdo and psytrellis individually.
x264_new_bframe_decision_04.diff (http://skystrife.com/x264/x264_new_bframe_decision_04.diff) <-- This patch is highly experimental. Only change from 03 is to remove the change of X264_BUILD in x264.h because the psytrellis patch already changes it.
x264_hrd_pulldown.09_interlace.diff
x264.progress.indication.01.diff

All patches are included with the source.

gcc 3.4.5 fprofiled build.

[Sharktooth]

gprof: no
All my builds have that too (its not fprofiled if you think that), do you?
profiling = very, very slight speed advantage but for free.

[bob0r]

profiling = very, very slight speed advantage but for free.

Unrelated?

[Sharktooth]

well, not properly. lets say fprofiling could be usefull for those running x264 on old PCs or using insane settings.
however, my request was for a fprofiled generuic build.
march=core2 isnt generic and that build was not fprofiled.

[kemuri-_9]

I've also noticed that profiled builds are usually smaller than non:

non profiled builds run about 1.18-1.2 MB,
profiled builds run about 1 MB
this has been my experience with them at least.

btw, gprofiling and fprofling are different profiling methods too, so be sure not to confuse them:
GNU gprof vs GCC flags: -fprofile-generate/-fprofile-use
x264 configure can accept gprof and compile with gprofile enabled code, but default is to use fprofiling through 'make fprofiled'

[Sharktooth]

"g" and "f" keys are really close on the keyoard... and my left hand and fingers are actually not so accurate... i usually edit my posts several times to correct the typos but i just cant catch some of them
i meant fprofiled btw.

[skystrife]

x264.937.modified.exe (http://www.mediafire.com/?rhacap8ja1e) - Alternate Download (http://skystrife.com/x264/x264.937.modified.exe)
libx264-61.937.modified.dll (http://www.mediafire.com/?yazcfgy3iv0) - Alternate Download (http://skystrife.com/x264/libx264-61.937.modified.dll)
(Source) (http://www.mediafire.com/?nenhokfdomb) - Alternate Download (http://skystrife.com/x264/x264.937.modified.source.7z)

Patches used:

x264_psy_rdo_0.6.diff <-- Just a name change, no different from the patch used in 936 modified (this means it includes psytrellis).
x264_new_bframe_decision_04.diff <-- This patch is highly experimental, only enabled with --b-adapt 2.
x264_hrd_pulldown.09_interlace.diff
x264.progress.indication.01.diff

All patches are included with the source.

gcc 3.4.5 fprofiled build.

[qyqgpower]

@skystrife
Could you include revision number in x264.exe , or I can't identify which build is used to encode the specified file. Maybe I should put revision number in the names of the encoded files? :)
your build:
x264 --version
x264 0.61.x

Jarod's build:
x264 --version
x264 0.60.928M 4816918

[bob0r]

x264.937.modified.01.exe (http://files.x264.nl/x264.937.modified.01.exe)
libx264-61.937.modified.01.dll (http://files.x264.nl/libx264-61.937.modified.01.dll)

x264-psyrd-0.6.diff (on by default, adjust with: --psy-rd)
x264.new.bframes.decision.04.diff (highly experimental, enabled with: --b-adapt 2)
x264_hrd_pulldown.09_interlace.diff
x264.progress.indication.01.diff

[Sharktooth]

bobor, is it fprofiled?

[bob0r]

bobor, is it fprofiled?

You even have to ask?
When i put an url on http://x264.nl yes it's fprofiled.

[kemuri-_9]

@skystrife
Could you include revision number in x264.exe , or I can't identify which build is used to encode the specified file. Maybe I should put revision number in the names of the encoded files? :)
your build:
x264 --version
x264 0.61.x

Jarod's build:
x264 --version
x264 0.60.928M 4816918

if the build doesn't include the revision number which it's automatically configured to do on compilation, then it doesn't have access to some CLI utils:
GIT CLI : git-rev-list, git-status
binutils: awk (usually via gawk or mawk), grep, head, join, sed, sort, wc
be sure these binaries are on the PATH environment variable or it won't be able to include the revision number within the build.

[skystrife]

Thanks for the heads up qyqgpower, and kemuri for the explanation, this further builds from me will have this issue fixed. =)

And I feel really dumb for not catching that earlier.

[tobinaka]

May I introduce Japanese current patches here? Sorry for the bother, but I thought this thread best to tell you them. Though I'm just a Japanese x264 user, not a programmer, I want to tell you about them because I've not found them in the forum. The author gave me OK.


In Japan, Seraphy (http://seraphy.fam.cx/~seraphy/)'s builds may be the most popular because he provides them also as x264 GUI plug-ins for AviUtl (http://spring-fragrance.mints.ne.jp/aviutl/). (AviUtl is a video editor free-software developed by KEN and is very popular in Japan. I'll explain it more on a proper thread If you want.)

Seraphy's builds have 3 version: no-patched, MixAQ and OreAQ. There is no need for talking about no-patched one. The other two are applied particular AQ patches in addition to common ones (thread_pool, selectable arranged QNS, Psy RDO, ME-prepass, RDO by DeathTheSheep, new B-frame dicision, updated arranged vaq2mod_fgo). The difference between the latter two versions is just which patches is selected for AQ. Both AQ patches were made for encoding animes.


MixAQ:

MixAQ mixes VAQ and Halli's AQ. In a word, MixAQ is -VAQ +HAQ. My understanding of VAQ is that VAQ allocates bits more to flat area and less to changeful area. But that is when --aq-strength has a positive value. If the negative value is possible for --aq-strength? Seraphy tried it and then saw VAQ with negative values allocated bits less to flat area and more to changeful area. That is good to encode animes. And what is more, worried for execive cut-down and allocating shortage, he added Haali's AQ for support. Finally, MixAQ makes -VAQ allow HAQ to allocate bits more to bright blue area and dark area. To use MixAQ, set --aq2-strength and --aq2-sensitivity for HAQ in addition. It's possible to use only VAQ by setting --aq2-strength 0.


OreAQ:

OreAQ is also a arranged mod from VAQ and HAQ, but is different from MixAQ ("Ore" means "I" in Japanese.) OreAQ is focused on luma and chroma, especially on the former. OreAQ classifies MBs into 4 types: Bright, Middle, Dark, M.Dark (maybe stand for Mega-Dark). OreAQ tends to lower or keep QPs with middle luma to protect gradations. About the others, it lowers QPs only when necessary and basically raises QPs. That is because color noises stand out rather than gradations in areas of high and low lumas. Chroma values are used for diciding whether QPs need to lower or not. The luma of M.Dark MB is near or at zero, so we can hardly see anything there even if there is any color noise. Thus, OreAQ raises QPs at M.Dark MBs. OreAQ is good to encode animes, and more bit-economical than MixAQ maybe.


You can get Seraphy's builds and their diffs here (http://seraphy.fam.cx/~seraphy/program/x264/%E3%81%8A%E3%81%BE%E3%81%91/). "x264patch" includes MixAQ, 7 common patches I described above, and their diffs. "x264OreAQ" includes OreAQ, 7 common patches and OreAQ diff. The files "x264gui.auo" and "x264gui.ini" are the plug-ins for AviUtl.

Since rev928, he has added --aq-debug option to both patched versions. This puts the log of QP's variations caused by AQ and enable us to see the changes on AviUtl. It's also possible to simulate AQ changes moving --aq-strength and --aq-sensitivity up and down. That is very useful but needs futher explanations as this post is already long enough.

As x264 builds by Japanese, VFR maniac's Experimental builds (http://www.esnips.com/web/VFRmaniac-Softwares) are available, too. That includes MixAQ and OreAQ. MixAQ is his idea.

I hope you are interested in Japanese usages and this post contribute to x264's discussions. Thanks!

[elguaxo]

sounds interesting. thanks tobinaka!

[bob0r]

x264.938.modified.01.exe (http://files.x264.nl/x264.938.modified.01.exe)
libx264-61.938.modified.01.dll (http://files.x264.nl/libx264-61.938.modified.01.dll)

x264-psyrd-0.6.diff (on by default, adjust with: --psy-rd)
x264.new.bframes.decision.04.diff (highly experimental, enabled with: --b-adapt 2)
x264_hrd_pulldown.09_interlace.diff
x264.progress.indication.01.diff

[G_M_C]

x264.938.modified.01.exe (http://files.x264.nl/x264.938.modified.01.exe)
libx264-61.938.modified.01.dll (http://files.x264.nl/libx264-61.938.modified.01.dll)

x264-psyrd-0.6.diff (on by default, adjust with: --psy-rd)
x264.new.bframes.decision.04.diff (highly experimental, enabled with: --b-adapt 2)
x264_hrd_pulldown.09_interlace.diff
x264.progress.indication.01.diff


thx bob0r

[shon3i]

As x264 builds by Japanese, VFR maniac's Experimental builds are available, too. That includes MixAQ and OreAQ. MixAQ is his idea.
I just downloaded this build, and it have four different AQ's, FGO, PsyRD+Psy Trellis. I definitly must try this on some very low bitrate :)

[skystrife]

r940 has been reported to have a bad threading issue. Please revert to using r938 for the time being.





x264.940.modified.exe (http://www.mediafire.com/?eaamdijaaaa) - Alternate Download (http://skystrife.com/x264/x264.940.modified.exe)
libx264-61.940.modified.dll (http://www.mediafire.com/?sjiecjeibdb) - Alternate Download (http://skystrife.com/x264/libx264-61.940.modified.dll)

Patches used:

x264_psy_rdo_0.6.diff
x264_new_bframe_decision_04.diff <-- This patch is highly experimental, only enabled with --b-adapt 2.
x264_hrd_pulldown.09_interlace.diff
x264.progress.indication.01.diff

All patches are included with the source.

gcc 3.4.5 fprofiled build.

[Sharktooth]

thanks. got it's way into megui auto-update.

[tobinaka]

sounds interesting. thanks tobinaka!
Thanks for your quick reply. MixAQ is really interesting and worth trying.:) If you can, take your time to entertain their accumulated improvements.
I've found MixAQ wise because If I want I can use normal VAQ on MixAQ. In this way, MixAQ can deal with encoding both animes and non-animes like live-actions better than normal VAQ.

-to use -VAQ+HAQ: --aq-strength <negative> --aq2-strength <positive>
e.g.) --aq-strength -1.0 --aq2-strength 0.7

-to use only normal VAQ: --aq-strength <positive> --aq2-strength <zero>
e.g.) --aq-strength 1.0 --aq2-strength 0

I just downloaded this build, and it have four different AQ's, FGO, PsyRD+Psy Trellis. I definitly must try this on some very low bitrate
As you know, Japanese are good for dealing with something low like cars of low-fuel consumption.:)

Anyway, VFR maniac's Experimental builds is really experimental as its name. He's built them to check for conflicts among codes of official and patches as well as seeing how they affect speed/output. He's made MixAQ and OreAQ really both stable and reliable. His advantages appear on the info.txt in his builds. He subdivides diffs by functions: his improving zones, Seraphy's correct stack alignment, etc.

Not only that, he's noticed some bugs in official opitions. At any rate, see VFR maniac's site (http://www.esnips.com/web/VFRmaniac-Softwares), read his comments in english. But they should be talked about on another proper thread.

[Dark Shikari]

Anyway, VFR maniac's Experimental builds is really experimental as its name. He's built them to check for conflicts among codes of official and patches as well as seeing how they affect speed/output. He's made MixAQ and OreAQ really both stable and reliable. His advantages appear on the info.txt in his builds. He subdivides diffs by functions: his improving zones, Seraphy's correct stack alignment, etc.

Not only that, he's noticed some bugs in official opitions. At any rate, see VFR maniac's site (http://www.esnips.com/web/VFRmaniac-Softwares), read his comments in english. But they should be talked about in another proper thread.It would be nice if such people made the minimal effort to submit patches to the developers rather than relying on the faint hope that someone else will do it for them (or, as I have seen in some places, believing that the official developers don't care about them and therefore monopolizing the patches...)

And language is not an excuse, we have multiple Japanese speakers in the official IRC channel, including (afaik) akupenguin himself.

[CruNcher]

MixAQ sounds great indeed exactly what i thought off when we discussed VAQ way back then :) (tough DS said it isn't possible to mix them, so nice to see that someone pulled it of)
Now we have to see how it does Visualy compared vs VAQ alone, tough wouldn't HAQ interfer heavily with VAQ in --aq-mode 2 now ?

[Sharktooth]

x264 r940 is broken with threads > 1. i already reverted the megui auto-update to r938. so even the modified patched builds are affected. x264 devs are working on a fix.
sadly the r940 was up on the megui auto-update for few hours. so i hope it didnt give too much headaches to megui users.
im really sorry, it's totally my fault. in the future i will test the builds using multiple threads (i usually do it with 1 thread) before uploading them into the auto-update server.

edit: r941 has just been commited with a fix.

[Dark Shikari]

x264 r940 is broken with threads > 1. i already reverted the megui auto-update to r938. so even the modified patched builds are affected. x264 devs are working on a fix.
sadly the r940 was up on the megui auto-update for few hours. so i hope it didnt give too much headaches to megui users.
im really sorry, it's totally my fault. in the future i will test the builds using multiple threads (i usually do it with 1 thread) before uploading them into the auto-update server.No, its my fault for not testing threads before I committed the fix (and a tiny bit akupengiun's for not noticing it when he approved my commit of the patch).

Its fixed (http://git.videolan.org/?p=x264.git;a=commitdiff;h=ae8da3e5c85562d1018b9f85c601884022f070a3) though.

[tobinaka]

It would be nice if such people made the minimal effort to submit patches to the developers rather than relying on the faint hope that someone else will do it for them (or, as I have seen in some places, believing that the official developers don't care about them and therefore monopolizing the patches...)

And language is not an excuse, we have multiple Japanese speakers in the official IRC channel, including (afaik) akupenguin himself.

I agree. Certainly it's efficient that one to bring it up should come it into action. If I could write codes, I would, but regrettably I can't. About other Japanese, wait for a moment. Even my introductions here must be unusual until now. I've seen they have felt thier patches little worth for Doom9's Forum developers. I've never felt so, then I introduced them here... I really agree with you, Dark Shikari. My postings are partially to encourage them. But it needs some time and steps.

In Japan, free-software developments in a group are still uncommon. I would have to say that SourceFourge.jp has only begun even if it launched in 2002. Many tools have been developed privately, and anonymous users have discussed on them in 2ch-forum and so on. That's paticular... often inefficient... but that's Japanese common style. Open-sourced projects are still less fashionalbe in Japan. Then, many Japanese free-software developers are not used to joining and discussing in Doom9's-Forum-like forums. The same can be said for IRC. Not to monopolize their patches.

Actually, language is not an excute. Even my poor English has been read kindly by you all (Thanks a lot!!). And I found the official IRC really easy to join and discuss on when I tried it, even I've not known akupenguin could use Japanese.:) The problem should be customs. That makes things difficult. But things must be better gradually, then the different cultures will make things interesting. You're right. But it needs some time and steps, like this discussions between you and I. I'll promote Japanese developers to join the official discussions. For now, consider their patches.

[Dark Shikari]

Actually, language is not an excute. Even my poor English has been read kindly by you all (Thanks a lot!!).Poor English? Your English is quite good; slightly awkward at times but overall very good for a non-native speaker. I don't think you have to worry about not being understood ;)

[skystrife]

x264.941.modified.exe (http://www.mediafire.com/?erarzojaidh) - Alternate Download (http://skystrife.com/x264/x264.941.modified.exe)
libx264-61.941.modified.dll (http://www.mediafire.com/?hdah9uwdjyz) - Alternate Download (http://skystrife.com/x264/libx264-61.941.modified.dll)

Patches used:

x264_psy_rdo_0.6.diff
x264_new_bframe_decision_04.diff <-- This patch is highly experimental, only enabled with --b-adapt 2.
x264_hrd_pulldown.09_interlace.diff
x264.progress.indication.01.diff

All patches are included with the source.

gcc 3.4.5 fprofiled build.

[kemuri-_9]

working on patching r942, due to the whitespace cosmetic changes, ended up having to use the -l option in patch (ignore whitespace distinctions) to get them to apply without rejections.
just as a heads up for the others.

[skystrife]

x264.942.modified.exe (http://www.mediafire.com/?alccau1e6qj) - Alternate Download (http://skystrife.com/x264/x264.942.modified.exe)
libx264-61.942.modified.dll (http://www.mediafire.com/?ujidb9cywxn) - Alternate Download (http://skystrife.com/x264/libx264-61.942.modified.dll)

Patches used:

x264_psy_rdo_0.6.diff
x264_new_bframe_decision_04.diff <-- This patch is highly experimental, only enabled with --b-adapt 2.
x264_hrd_pulldown.09_interlace.diff
x264.progress.indication.01.diff

All patches are included with the source.

gcc 3.4.5 fprofiled build.

[G_M_C]

This is probably a very obvious question .... but :o .... what's the .DLL for ?

[Shinigami-Sama]

This is probably a very obvious question .... but :o .... what's the .DLL for ?

stuff like ffmpeg and avidemux

[skystrife]

r946 won't fprofile properly on my end with the patches I have been using in my previous builds. x264 randomly will "stop working."

Does this happen for anyone else?

[TL0]

I read some of the posts by VFR maniac at his site and he mentions a bug in the zone option.

I noticed the bug at x264's zones.
When you use zones, x264_validate_parameters is called twice from two functions.
The one is x264_encoder_open, the other is x264_encoder_reconfig.
So, VAQ_GLOBAL + zones has the bug, which modifies qcomp twice.
I patched it as follows.
if( h->param.rc.f_aq_strength <= 0 )
h->param.rc.i_aq_mode = 0;
/* VAQ effectively replaces qcomp, so qcomp is raised towards 1 to compensate. */
- if( h->param.rc.i_aq_mode == X264_AQ_GLOBAL )
+ if( h->param.rc.i_aq_mode == X264_AQ_GLOBAL && ((h->param.rc.psz_zones && !h->param.rc.i_zones) || !h->param.rc.psz_zones) )
h->param.rc.f_qcompress = x264_clip3f(h->param.rc.f_qcompress + h->param.rc.f_aq_strength / 0.7, 0, 1);
h->param.analyse.i_noise_reduction = x264_clip3( h->param.analyse.i_noise_reduction, 0, 1<<16 );

But the bug was not able to be removed by it completely.
How can we remove this bug?

does anybody know if this is correct and if it has any negative effect on quality if zone option is used currently?

[gigah72]

r946 won't fprofile properly on my end with the patches I have been using in my previous builds. x264 randomly will "stop working."

Does this happen for anyone else?

i tried to build fprofiled, but i get a crash in nasm on 945 & 946 (others i didn't try and with the usual patches) in both in deblock-a.asm.
http://img235.imageshack.us/img235/2919/nasmcrashro5.png (http://imageshack.us)
http://img235.imageshack.us/img235/2919/nasmcrashro5.9af9d64905.jpg (http://g.imageshack.us/g.php?h=235&i=nasmcrashro5.png)

[Sharktooth]

use yasm.

[gigah72]

use yasm.

thanks, now it works. funny that i never had a problem before.

if someone wants to try (at you own risk) 946 (exe & lib with patches):

http://www.mediafire.com/?sharekey=40642d9359c527a2ab1eab3e9fa335cae43ea9d1ebf82fba

[bob0r]

r946 won't fprofile properly on my end with the patches I have been using in my previous builds. x264 randomly will "stop working."

Does this happen for anyone else?

Confirmed:
it crashes at the begin on the fourth fprofile run.
Trying to figure out whats the cause right now.

[Sagekilla]

Sorry but, where is r946? When I goto x264.nl I only see r944.

[wyti]

in Git, actually cause r946 cause problem to fprofiling there is no build at this time.

[kemuri-_9]

r946 is in the GIT, x264.nl often gets behind and needs bob0r's magic touch to get it updated.

fprofiling works for me, though i alter the profiles to include some patch profiling too:
./x264.exe --crf 30 -b1 -m1 -r1 --thread-input --psy-rd 0.0:0.0 --me dia --aq-mode 0 --asm 890 --no-cabac --pre-scenecut --direct temporal --no-ssim --no-psnr ../x264_build1.y4m --progress -o NUL ;
./x264.exe --crf 16 -b2 -m3 -r3 --thread-input --psy-rd 0.0:0.0 --me hex -8 --direct spatial --aq-mode 1 --no-dct-decimate ../x264_build1.y4m --progress -o NUL ;
./x264.exe --crf 26 -b2 -m5 -r2 --thread-input --psy-rd 0.0:0.0 --me hex -8 -w --cqm jvt --b-adapt 2 --nr 100 ../x264_build1.y4m --progress -o NUL ;
./x264.exe --crf 18 -b3 -m7 -r5 --thread-input --psy-rd 0.0:0.0 --me umh -8 -t1 -A all --mixed-refs --b-rdo -w --b-pyramid --direct auto --bime --no-fast-pskip ../x264_build1.y4m --progress -o NUL ;
./x264.exe --crf 22 -b3 -m6 -r4 --thread-input --psy-rd 1.0:1.0 --me esa -8 -t2 -A all --mixed-refs --b-rdo --bime ../x264_build1.y4m --progress -o NUL ;
./x264.exe --frames 50 --crf 24 -b3 -m7 -r3 --thread-input --psy-rd 0.2:0.2 --me tesa -8 -t1 --mixed-refs --b-rdo --bime ../x264_build1.y4m --progress -o NUL ;
./x264.exe --frames 50 -q0 -m6 -r2 --thread-input --psy-rd 0.0:0.0 --me hex -Aall ../x264_build1.y4m --progress -o NUL ;
./x264.exe --frames 50 -q0 -m2 -r1 --thread-input --psy-rd 1.0:0.0 --me hex --no-cabac ../x264_build1.y4m --progress -o NUL ;

yuv4mpeg: 640x480@30/1fps, 0:0
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSE3 Cache64
x264 [info]: slice I:88 Avg QP:27.98 size: 8050:00:00
x264 [info]: slice P:3073 Avg QP:29.79 size: 7024
x264 [info]: slice B:1189 Avg QP:31.87 size: 1412
x264 [info]: consecutive B-frames: 44.2% 55.8%
x264 [info]: mb I I16..4: 73.4% 0.0% 26.6%
x264 [info]: mb P I16..4: 23.4% 0.0% 16.1% P16..4: 25.2% 7.0% 1.3% 0.0% 0.0% skip:27.0%
x264 [info]: mb B I16..4: 1.4% 0.0% 0.0% B16..8: 18.4% 1.0% 0.6% direct: 5.9% skip:72.7% L0:30.1% L1:47.4% BI:22.5%
x264 [info]: kb/s:1322.5
encoded 4350 frames, 18.65 fps, 1322.67 kb/s

yuv4mpeg: 640x480@30/1fps, 0:0
x264 [info]: using cpu capabilities: MMX2 SSE2Fast
x264 [info]: slice I:100 Avg QP:13.55 size: 28448 PSNR Mean Y:60.31 U:65.29 V:63.54 Avg:60.51 Global:51.84
x264 [info]: slice P:2893 Avg QP:15.79 size: 26977 PSNR Mean Y:48.61 U:50.65 V:49.32 Avg:48.89 Global:46.93
x264 [info]: slice B:1357 Avg QP:18.02 size: 10265 PSNR Mean Y:47.05 U:49.56 V:47.97 Avg:47.41 Global:45.27
x264 [info]: consecutive B-frames: 44.0% 32.5% 23.5%
x264 [info]: mb I I16..4: 37.7% 23.3% 39.0%
x264 [info]: mb P I16..4: 7.5% 18.1% 23.3% P16..4: 23.3% 9.3% 5.6% 0.0% 0.0% skip:12.8%
x264 [info]: mb B I16..4: 2.6% 0.0% 0.0% B16..8: 37.5% 5.4% 6.1% direct:21.4% skip:27.0% L0:32.4% L1:35.5% BI:32.1%
x264 [info]: 8x8 transform intra:35.4% inter:51.2%
x264 [info]: ref P L0 83.1% 10.6% 6.3%
x264 [info]: ref B L0 85.0% 15.0%
x264 [info]: SSIM Mean Y:0.9937623
x264 [info]: PSNR Mean Y:48.394 U:50.647 V:49.228 Avg:48.698 Global:46.404 kb/s:5231.35
encoded 4350 frames, 17.79 fps, 5231.54 kb/s

yuv4mpeg: 640x480@30/1fps, 0:0
x264 [info]: using cpu capabilities: MMX2 SSE2Fast
x264 [info]: slice I:102 Avg QP:21.87 size: 12615 PSNR Mean Y:53.33 U:61.89 V:59.56 Avg:54.03 Global:43.66
x264 [info]: slice P:2175 Avg QP:27.03 size: 8669 PSNR Mean Y:41.43 U:46.78 V:43.84 Avg:42.07 Global:38.96
x264 [info]: slice B:2073 Avg QP:29.66 size: 3576 PSNR Mean Y:38.77 U:44.53 V:41.68 Avg:39.55 Global:37.79
x264 [info]: consecutive B-frames: 19.7% 28.4% 51.9%
x264 [info]: mb I I16..4: 35.9% 45.9% 18.2%
x264 [info]: mb P I16..4: 9.0% 29.7% 6.3% P16..4: 23.9% 6.8% 1.4% 0.0% 0.0% skip:22.8%
x264 [info]: mb B I16..4: 8.4% 0.0% 0.0% B16..8: 24.5% 2.1% 1.2% direct:13.9% skip:50.0% L0:34.9% L1:48.5% BI:16.6%
x264 [info]: 8x8 transform intra:55.1% inter:54.6%
x264 [info]: ref P L0 84.3% 15.7%
x264 [info]: SSIM Mean Y:0.9750468
x264 [info]: PSNR Mean Y:40.440 U:46.065 V:43.178 Avg:41.146 Global:38.422 kb/s:1520.28
encoded 4350 frames, 10.20 fps, 1520.46 kb/s

yuv4mpeg: 640x480@30/1fps, 0:0
x264 [info]: using cpu capabilities: MMX2 SSE2Fast
x264 [info]: slice I:59 Avg QP:13.21 size: 12098 PSNR Mean Y:65.26 U:67.45 V:66.05 Avg:65.31 Global:53.06
x264 [info]: slice P:2880 Avg QP:19.08 size: 16859 PSNR Mean Y:46.19 U:48.18 V:46.52 Avg:46.34 Global:44.63
x264 [info]: slice B:1411 Avg QP:21.95 size: 5156 PSNR Mean Y:44.71 U:47.14 V:45.33 Avg:44.97 Global:43.01
x264 [info]: consecutive B-frames: 44.5% 32.1% 8.5% 14.9%
x264 [info]: mb I I16..4: 54.2% 40.2% 5.7%
x264 [info]: mb P I16..4: 8.7% 29.7% 3.4% P16..4: 27.5% 11.1% 6.0% 0.5% 0.2% skip:12.9%
x264 [info]: mb B I16..4: 0.5% 2.2% 0.3% B16..8: 37.9% 2.6% 2.5% direct: 6.4% skip:47.6% L0:36.4% L1:41.5% BI:22.1%
x264 [info]: 8x8 transform intra:69.6% inter:79.5%
x264 [info]: direct mvs spatial:96.3% temporal:3.7%
x264 [info]: ref P L0 76.9% 12.0% 6.0% 2.8% 2.4%
x264 [info]: ref B L0 79.3% 14.6% 4.1% 2.1%
x264 [info]: ref B L1 96.5% 3.5%
x264 [info]: SSIM Mean Y:0.9911334
x264 [info]: PSNR Mean Y:45.965 U:48.105 V:46.398 Avg:46.152 Global:44.083 kb/s:3119.60
encoded 4350 frames, 4.97 fps, 3119.76 kb/s

yuv4mpeg: 640x480@30/1fps, 0:0
x264 [info]: using cpu capabilities: MMX2 SSE2Fast
x264 [info]: slice I:58 Avg QP:15.85 size: 10880 PSNR Mean Y:63.58 U:67.26 V:66.06 Avg:64.16 Global:50.41
x264 [info]: slice P:2881 Avg QP:23.00 size: 13992 PSNR Mean Y:43.68 U:47.95 V:46.21 Avg:44.39 Global:42.51
x264 [info]: slice B:1411 Avg QP:26.08 size: 3472 PSNR Mean Y:42.42 U:46.86 V:44.90 Avg:43.10 Global:40.98
x264 [info]: consecutive B-frames: 44.5% 32.1% 8.5% 14.9%
x264 [info]: mb I I16..4: 53.1% 41.5% 5.4%
x264 [info]: mb P I16..4: 7.9% 28.6% 2.2% P16..4: 28.9% 9.9% 7.0% 0.3% 0.1% skip:15.2%
x264 [info]: mb B I16..4: 0.5% 1.9% 0.1% B16..8: 37.4% 1.4% 1.9% direct: 4.1% skip:52.6% L0:35.0% L1:46.1% BI:18.8%
x264 [info]: 8x8 transform intra:72.5% inter:67.3%
x264 [info]: ref P L0 80.3% 10.3% 6.2% 3.2%
x264 [info]: ref B L0 83.8% 11.1% 5.2%
x264 [info]: SSIM Mean Y:0.9860930
x264 [info]: PSNR Mean Y:43.539 U:47.854 V:46.052 Avg:44.234 Global:41.993 kb/s:2529.25
encoded 4350 frames, 3.97 fps, 2529.42 kb/s

yuv4mpeg: 640x480@30/1fps, 0:0
x264 [info]: using cpu capabilities: MMX2 SSE2Fast
x264 [info]: slice I:1 Avg QP:10.00 size: 94 PSNR Mean Y:100.00 U:100.00 V:100.00 Avg:100.00 Global:100.00
x264 [info]: slice P:23 Avg QP:23.41 size: 3554 PSNR Mean Y:46.98 U:55.16 V:54.38 Avg:48.36 Global:46.55
x264 [info]: slice B:26 Avg QP:25.98 size: 421 PSNR Mean Y:43.66 U:51.86 V:49.06 Avg:44.96 Global:44.52
x264 [info]: consecutive B-frames: 16.3% 36.7% 6.1% 40.8%
x264 [info]: mb I I16..4: 100.0% 0.0% 0.0%
x264 [info]: mb P I16..4: 11.3% 21.4% 0.4% P16..4: 29.3% 3.2% 0.6% 0.0% 0.0% skip:33.8%
x264 [info]: mb B I16..4: 0.3% 0.3% 0.0% B16..8: 16.6% 0.0% 0.1% direct: 0.9% skip:81.8% L0:26.9% L1:68.3% BI: 4.8%
x264 [info]: 8x8 transform intra:57.0% inter:85.0%
x264 [info]: ref P L0 94.1% 4.2% 1.7%
x264 [info]: ref B L0 95.8% 4.2%
x264 [info]: SSIM Mean Y:0.9878109
x264 [info]: PSNR Mean Y:46.310 U:54.342 V:52.526 Avg:47.624 Global:45.449 kb/s:445.32
encoded 50 frames, 7.88 fps, 448.37 kb/s

yuv4mpeg: 640x480@30/1fps, 0:0
x264 [info]: using cpu capabilities: MMX2 SSE2Fast
x264 [info]: slice I:1 Avg QP: 0.00 size: 12900
x264 [info]: slice P:49 Avg QP: 0.00 size: 59494
x264 [info]: mb I I16..4: 99.9% 0.0% 0.1%
x264 [info]: mb P I16..4: 3.2% 0.0% 20.9% P16..4: 35.0% 8.0% 9.1% 1.3% 0.9% skip:21.5%
x264 [info]: ref P L0 77.2% 22.8%
x264 [info]: kb/s:13993.5
encoded 50 frames, 13.85 fps, 14018.52 kb/s

yuv4mpeg: 640x480@30/1fps, 0:0
x264 [info]: using cpu capabilities: MMX2 SSE2Fast
x264 [info]: slice I:1 Avg QP: 0.00 size: 95400
x264 [info]: slice P:49 Avg QP: 0.00 size: 73169
x264 [info]: mb I I16..4: 99.9% 0.0% 0.1%
x264 [info]: mb P I16..4: 22.5% 0.0% 20.1% P16..4: 33.1% 11.5% 8.5% 0.0% 0.0% skip: 4.3%
x264 [info]: kb/s:17213.9
encoded 50 frames, 40.00 fps, 17216.06 kb/s


Skystrike & bob0r: are you two profiling with avs scripts?
if so then you might be hitting the 2GB mem limit causing x264 to silent crash/quit.

[Sharktooth]

gcc 4.3.1 profiling works...
gcc 3.4.6 profiling crashes...
gcc 3.4.6 debug works...
gcc 3.4.6 debug with -O3 crashes...

Program received signal SIGSEGV, Segmentation fault.
0x0042d96b in block_residual_write_cabac (h=0x1af, cb=0x22cfc0,
i_ctxBlockCat=5, i_idx=0, l=0xed8790, i_count=64) at ./common/bs.h:225
225 if( val < 255 )
:confused:
devz working on it.

[LoRd_MuldeR]

r946 won't fprofile properly on my end with the patches I have been using in my previous builds. x264 randomly will "stop working."

Does this happen for anyone else?

The "Psy RDO v0.6" patch won't apply to r946 at all :(

$ patch -p1 < ../x264-psyrd-0.6.diff
patching file `common/common.c'
patching file `common/common.h'
Hunk #1 succeeded at 381 (offset 4 lines).
Hunk #2 succeeded at 460 (offset 4 lines).
patching file `common/dct.h'
patching file `encoder/analyse.c'
patching file `encoder/encoder.c'
patching file `encoder/macroblock.c'
Hunk #2 FAILED at 121.
Hunk #4 succeeded at 447 with fuzz 2.
Hunk #5 succeeded at 495 with fuzz 2.
1 out of 5 hunks FAILED -- saving rejects to encoder/macroblock.c.rej
patching file `encoder/macroblock.h'
patching file `encoder/rdo.c'
Hunk #1 FAILED at 50.
1 out of 5 hunks FAILED -- saving rejects to encoder/rdo.c.rej
patching file `x264.c'
patching file `x264.h'

[gigah72]

see here:
http://forum.doom9.org/showpost.php?p=1173030&postcount=716

[LoRd_MuldeR]

see here:
http://forum.doom9.org/showpost.php?p=1173030&postcount=716

Sorry, I missed that post. With that option the patch applies successfully and compiles successfully... :)

[MythCreator]

x264.947.modified.exe (http://www.mediafire.com/?awyqlgnaja2)

Patches used:

x264_psy_rdo_0.6.diff
x264_new_bframe_decision_04.diff <-- This patch is highly experimental, only enabled with --b-adapt 2.
x264_hrd_pulldown.09_interlace.diff
x264.progress.indication.01.diff


gcc 4.2.4 fprofiled build.

[bob0r]

x264.947.modified.01.exe (http://files.x264.nl/x264.947.modified.01.exe)
libx264-61.947.modified.01.dll (http://files.x264.nl/libx264-61.947.modified.01.dll)

x264-psyrd-0.6.diff (on by default, adjust with: --psy-rd) <-- patch using -l parameter (ignore whitespaces): patch -p1 -l < x264-psyrd-0.6.diff

x264_hrd_pulldown.09_interlace.diff
x264.progress.indication.01.diff

Not using x264.new.bframes.decision.04.diff (highly experimental, enabled with: --b-adapt 2) because it fails --no-b-adapt

[tobinaka]

does anybody know if this is correct and if it has any negative effect on quality if zone option is used currently?

VFR maniac himself wrote its diff. Get it here (http://www.esnips.com/web/VFRmaniac-Softwares).

x264_fix_extended_zones.diff

This patch removes bugｓ of aq-mode=2 + zones, and extended zones doesn't function (for some options). And this deduplicates unnecessary warnings. Support using AQ in the zones.

Oh, VFR maniac's English message does make some contrary senses against his comment on his Japanese blog.
He actually want to say that: his diff will remove "the bugs in aq-mode 2 + zones", "failure functions of extending zones for some options" and "unnecessarily duplicated warnings".

The current zones usage increases qpcomp by the value of aq-strength twice. That's because zones call x264_validate_parametes, where some operations are done. He corrects it by adding another argument to x264_validate_parametes and determining if it's called in zones or not. He wants at least this AQ part to be commited.

He said he straggled to write it up because you developers caught him by my link ;) Japanese have just some reasons of hesitating to use official supports. But they will be pleased if they can help x264 development by their own efforts like you all! (go easy on them/us, DS:))

[Ranguvar]

This new interest in odd patches is good :) People like Komisar666 and these new Japanese devs have amassed a ton of patches, and while some (VAQ2mod, anyone?) seem rather useless, I'd definitely like to hear what the developers think of them.

[skystrife]

I think I'd be more inclined to do testing with some of the new VAQ patches if they weren't written with fgo and/or other patches required, but were a patch against the direct source code.

[Ranguvar]

http://sites.google.com/site/ranguvar13/x264-builds

Direct Download (http://sites.google.com/site/ranguvar13/x264-builds/rang_x264_r0948.7z?attredirects=0), Mirrors (http://www.uploadjockey.com/download/3658403/rang_x264_r0948.7z)

x264 r948 from Git.

Open this archive with the free, multi-platform tool 7-Zip or p7zip. Compressed with LZMA.
The src folder contains the patched source code.
The bin folder contains a binary for most Windows PCs, and a binary optimized for Core 2 CPUs. The latter provides a performance increase of ~6% in my testing. Will vary.

Official source can be found at: http://x264.nl/
Changelog: http://git.videolan.org/gitweb.cgi?p=x264.git;a=shortlog
Patches and discussion at Doom9's forum: http://forum.doom9.org/


Applied patches (included, unchanged, in the patches folder):

x264.progress.indication.01.diff
x264_hrd_pulldown.09_interlace.diff
x264-psyrd-0.6.diff
x264.new.bframes.decision.04.diff


Compiled by Ranguvar on August 22nd, 2008, with GCC 4.3.1 on Windows XP Professional x64 SP2.

CLI used for generic build: ./configure --extra-cflags="-pipe" && make fprofiled VIDS="../enctests/deadline_cif.y4m ../enctests/foreman_cif.y4m ../enctests/garden_sif.y4m ../enctests/grandma_qcif.y4m ../enctests/husky_cif.y4m ../enctests/mobile_cif.y4m ../enctests/suzie_qcif.y4m"
CLI used for Core 2 build: ./configure --extra-cflags="-march=core2 -pipe" && make fprofiled VIDS="same_as_above"

Platform: X86
System: MINGW
asm: yes
avis input: yes
mp4 output: yes
pthread: yes
gtk: no
debug: no
gprof: no
PIC: no
shared: no
visualize: no

[wyti]

Thanks for the build, it's nice too see all the details of your patch ;)

[martino]

I've been wondering whether anyone tried to do speed comparisons between a build compiled by GCC 3.4.5 and 4.3.*, since I got the 3.4.5 one to encode faster and would like to know whether anyone else experienced the same, or something different.

[Ranguvar]

3.4.x seems to create faster builds than 4.3.x in my experience (though not by much). This should change eventually. However, the 4.3.x series adds better Core 2 optimization, and trounces 3.4.x when creating a Core 2-optimized build.

http://blog.alphagemini.org/2008/03/icc-vs-gcc-43.html

ICC still beats both out though, by a fair amount... I'm going to be getting it soon, unless x264 has incompatibilities with it. :)

[Dark Shikari]

ICC still beats both out though, by a fair amount... I'm going to be getting it soon, unless x264 has incompatibilities with it. :)ICC has (afaik) the same stack alignment problem that MSVC does.

[Ranguvar]

ICC has (afaik) the same stack alignment problem that MSVC does.
Crap.

[kemuri-_9]

ICC doesn't really help those of us on the AMD side of the fence either :rolleyes:

[Ranguvar]

Yeah, but I already provide a generic and a Core 2 build, so I'd probably do something similar; the generic one would be GCC and the Core 2 one would be ICC.

So, ICC-compiled code does not work on AMD? Or there's just a slowdown? Enough to make GCC faster?

[gigah72]

about how much faster are you guys talking, as the most important stuff is already in asm?
in my comparisons between my builds (march=pentium2) and the others linked here, i never got noteworthy differences ...
someone wrote about a gain of 1,1% between plain make and make fprofiled. so if i encode 600min i win ~6min, but fprofiled takes also time ...
now i'm using a short clip, that will make fprofiled take longer by 5 min then without, but i get smaller exe.
what is your experiance with differnt vids for fprofiled?
and how much is difference you talk about between gcc 3.4.5 and 4.3.1 or others?

[martino]

However, the 4.3.x series adds better Core 2 optimization, and trounces 3.4.x when creating a Core 2-optimized build.
Interesting. I guess this is worth a re-test for me...

@gigah72
For me it was negligible in 1st pass, but 2nd was about 2-3fps faster on 704x480 video, with trellis 2, subme 7, partitions all, ref 8, bframes 5, and not sure about the rest, but probably defaults.


EDIT:
ICC has (afaik) the same stack alignment problem that MSVC does.
What does this mean in practical terms?

[akupenguin]

However, the 4.3.x series adds better Core 2 optimization,
Not really. x264 compiled with gcc 4.2.3 march=k8, 4.3.1 march=k8, and 4.3.1 march=core2 are all within about 0.2% speed of each other on core2... and sometimes it's the k8 ones that are faster.
4.3.x did improve autovectorization (from nonexistent to atrocious), but that doesn't matter to us.

[gigah72]

Interesting. I guess this is worth a re-test for me...

@gigah72
For me it was negligible in 1st pass, but 2nd was about 2-3fps faster on 704x480 video, with trellis 2, subme 7, partitions all, ref 8, bframes 5, and not sure about the rest, but probably defaults.


EDIT:

What does this mean in practical terms?

well, that's a lot, but i have different scenario, i'm encoding to 1280x720 with crf18 or 20 with something like sharktooths megui ps3-xbox360 profile ... maybe that's why i don't see such difference

[Shinigami-Sama]

What does this mean in practical terms?

its slower... because it has to use slower functions, or a whole other function to re-align the data

[Ranguvar]

its slower... because it has to use slower functions, or a whole other function to re-align the data

Slower to compile? Or the compiled app is slower?

[Shinigami-Sama]

Slower to compile? Or the compiled app is slower?

...srsly?...
slower to run...

[kemuri-_9]

the stack align problem causes some sse2 assembly functions to be unusable or crashes will occur:
namely the

x264_deblock_v_luma_sse2
x264_deblock_h_luma_sse2
x264_deblock_v_luma_intra_sse2
x264_deblock_h_luma_intra_sse2

x264_pixel_avg_weight_16x16_sse2
x264_pixel_avg_weight_16x8_sse2
x264_pixel_avg_weight_8x16_sse2
x264_pixel_avg_weight_8x8_sse2
x264_pixel_avg_weight_8x4_sse2

functions, so a good number of them become fubar when compiled in MSVC (and apparently ICC from above statements)....
so it will encode slower without these.

However, if your computer is so old it doesn't even have sse2, you won't notice a thing :cool:

[ajp_anton]

I've been wondering whether anyone tried to do speed comparisons between a build compiled by GCC 3.4.5 and 4.3.*, since I got the 3.4.5 one to encode faster and would like to know whether anyone else experienced the same, or something different.All 4.x.x builds I've tried crashes on Win2003 Server x64. They work on all 32-bit XPs I have. How do I find out why?

[kemuri-_9]

get/generate a debug build and see what the error is when it crashes.

running through gdb would help too

[tobinaka]

does anybody know if this is correct and if it has any negative effect on quality if zone option is used currently?

VFR maniac said that when using zones, fgo offsets pbratio twice. It would seem that with zones usage, the relatively-recent options of changing parameters cause problems.

ICC has (afaik) the same stack alignment problem that MSVC does.

Seraphy, a Japanese x264 builder, has noticed some stack alignment problems and tried to solve them. I'm sorry I can't understand the details of them even if I read readme.txt in his patched builds (http://seraphy.fam.cx/~seraphy/program/x264/%E3%81%8A%E3%81%BE%E3%81%91/) because of my no background. VFR maniac provides Seraphy's stack alignment correction patch "x264_aligned.diff" in his experimental builds (http://www.esnips.com/web/VFRmaniac-Softwares).

I told those two to join the official supports but I don't know if they will or not. Anyway, for now, this diff may help the discussion. Try it.

[skystrife]

I just did some testing, and a gcc 4.3.1 fprofiled build with --extra-cflags="-march=core2" was not any faster (in my case) than a gcc 3.4.5 fprofiled build with --extra-cflags="-march=pentium2". (In fact, in this particular case, the gcc 3.4.5 build ran faster by 0.17 fps for the first pass, and by 0.05 fps on the second pass... I'd call that pretty negligible though.)

Source was 720x480, ran with pretty maxed settings (16 ref, 16 bframes, subme 7, trellis 2, partitions all, 8x8dct, me umh, merange 24, 1.2 aq-strength).

[Sharktooth]

march=pentium2 ... it's all you need. using core2 or other fancy stuff is not needed at all for x264 since all the heavy stuff is already optimized by hand...
ICL and MSVS = crap.
is it that so difficult to :search: ?!?!?!? it has already been discussed to death...

[Ranguvar]

ICC doesn't seem crap at all, it consistently beats out GCC in all the tests I've seen so far. And there are ways to de-cripple the binaries so that they are not significantly slower on AMD.

That aside, I'll now be using -march=pentium2, thanks...
Just to make sure, as I can't find any definitive info (the gcc man isn't specific enough), will march=pentium2 binaries run on any i686-family CPU with MMX support? And if so, can I safely use it as the only build I provide, since x264 only supports non-MMX CPUs with no asm anyways?

[kemuri-_9]

pentium2
Intel Pentium2 CPU based on PentiumPro core with MMX instruction set support.

In other words it's for all computers with at least MMX support.

even the MMX asm can not be used by tossing --asm 0 at x264, disabling all asm usage completely, so for an -march=i686 build (yes it's different than pentium2), they could use --asm 0 and still use x264 on their stone age computers

Edit:
like some of the others, ran and logging tests comparing -march and a couple gcc versions, will be able to post them soon when they finish.
so everyone can see the cold hard facts for themselves.

[akupenguin]

even the MMX asm can not be used by tossing --asm 0 at x264, disabling all asm usage completely
Never use --asm unless you're me :). It can only disable things that are valid on your cpu, or enable things that are valid but slow (like shuffles on core2), since the autodetection already chooses optimally.
And neither --asm nor autodetection can entirely disable mmx, since some functions are inlined.

[kemuri-_9]

ah ha, i had forgotten about the inlining!
well i use --asm when i profile, so i can force some on/off compared to the autodetect, to get a more overall profile,
since x264.h gives away the formula for what is what pretty well

My current test run is done, i just have the fprofiling save to log, easiest way of showing the diffs:

GCC 3.4.5 series:
k8 (http://kemuri9.net/dev/x264/x264_profile.gcc-3.4.5.k8.log), pentium2 (http://kemuri9.net/dev/x264/x264_profile.gcc-3.4.5.pentium2.log), prescott (http://kemuri9.net/dev/x264/x264_profile.gcc-3.4.5.prescott.log)

GCC 4.3.1 series:
amdfam10 (http://kemuri9.net/dev/x264/x264_profile.gcc-4.3.1.amdfam10.log), core2 (http://kemuri9.net/dev/x264/x264_profile.gcc-4.3.1.core2.log), k8 (http://kemuri9.net/dev/x264/x264_profile.gcc-4.3.1.k8.log), pentium2 (http://kemuri9.net/dev/x264/x264_profile.gcc-4.3.1.pentium2.log), prescott (http://kemuri9.net/dev/x264/x264_profile.gcc-4.3.1.prescott.log)

all binaries available for dl:
http://kemuri9.net/dev/x264/

overall examination:
use 3.4.x; use pentium2 or k8.
since these are on my AMD Phenom (amdfam10), it's fully understandable to see k8 > pentium2;
now if someone on a core2 would compare a -march=k8 to a -march=pentium2 and see what the results are, we can settle this completely.

maybe i'll try a gcc 4.4.0 suite and see if my computer explodes while trying to do it :sly:

[Sharktooth]

ICC doesn't seem crap at all, it consistently beats out GCC in all the tests I've seen so far. And there are ways to de-cripple the binaries so that they are not significantly slower on AMD.
since we're talking about x264... ICC=crap for building x264...
the reason is: https://forum.doom9.org/showthread.php?p=1174147#post1174147 coz of this: https://forum.doom9.org/showthread.php?p=1174093#post1174093

[Ranguvar]

Okay, it's crap at this specific time, for one specific app. That doesn't mean the whole thing is crap. Every app has its bugs.

[Sharktooth]

exactly... since we're in the x264 thread, ICC is crap and also it's uber crap for non-intel x86 CPUs in any case...

[Ranguvar]

it's uber crap for non-intel x86 CPUs in any case

http://www.server01.org/patch-AuthenticAMD.html

[kemuri-_9]

ICC can be considered, but until the supposed (as i have no knowledge on this outside of this thread) stack alignment problem it should remain on the back burner from lack of complete ASM support.

[Sharktooth]

http://www.server01.org/patch-AuthenticAMD.html
........
But you are warned that modifying, disassembling or reverse engineering the Intel C++ compiler goes against the Intel EULA (End User License Agreement). So do at your own risk.
illegal... also ICC is payware... while gcc is free (and faster for x264). so i dont know why you're bothering acclaiming ICC when it is a total crap for x264.

[Disabled]

illegal...
Thats just for patching the ICC itself. Patching your own compiled binaries would be legal for sure.
also ICL is payware
ICC for Linux is free for non commercial projects:
http://www.intel.com/cd/software/products/asmo-na/eng/download/eval/219771.htm

Your other arguments still hold though.

[Sharktooth]

only for linux and for non commercial use.
also patching binaries for non-intel CPUs... every time... is a painfull process...

[Disabled]

I wrote Linux only even in my original post and I never knew x264 was a commercial product.
And patching binaries is painfull... like writing one extra line into the makefile?
If ICC would generate faster x264 binaries I'm sure these would be the mainly used binaries even on windows. But as it doesn't - I agree with you - this discussion is useless.

[bob0r]

x264.949.modified.01.exe (http://files.x264.nl/x264.949.modified.01.exe)
libx264-61.949.modified.01.dll (http://files.x264.nl/libx264-61.949.modified.01.dll)

x264-psyrd-0.6.diff (on by default, adjust with: --psy-rd) <-- patch using -l parameter (ignore whitespaces): patch -p1 -l < x264-psyrd-0.6.diff

x264_hrd_pulldown.09_interlace.diff
x264.progress.indication.01.diff

Not using x264.new.bframes.decision.04.diff (highly experimental, enabled with: --b-adapt 2) because it fails --no-b-adapt

[Sharktooth]

I wrote Linux only even in my original post and I never knew x264 was a commercial product.
And patching binaries is painfull... like writing one extra line into the makefile?
If ICC would generate faster x264 binaries I'm sure these would be the mainly used binaries even on windows. But as it doesn't - I agree with you - this discussion is useless.
x264 can be licensed and used as a commercial product...
however the point is quite different. IIRC ICC for linux wont produce binaries for windows... so it's quite useless for windows users also, icc for windows is a fully commercial product that will cost $$$. the evaluation version is fully working but it's time limited...
on the other side we have gcc, that's free/OSS, multiplatform and produces faster x264 binaries.
It's quite obvious what to choose...

[kemuri-_9]

Not using x264.new.bframes.decision.04.diff (highly experimental, enabled with: --b-adapt 2) because it fails --no-b-adapt

i worked on it a bit and got it to where it will accept --no-b-adapt properly
x264_new_bframe_decision_04.5.diff (http://kemuri9.net/dev/x264/patches/x264_new_bframe_decision_04.5.diff)
Would like to have DS and/or akupenguin look at it as it could probably be simplified
(I just couldn't manage to simplify it as i had tried in a few ways)

[skystrife]

x264.949.modified.exe (http://www.mediafire.com/?mknq4m3wtm9) - Alternate Download (http://skystrife.com/x264/x264.949.modified.exe)
libx264-61.949.modified.dll (http://www.mediafire.com/?aqaauaambww) - Alternate Download (http://skystrife.com/x264/libx264-61.949.modified.dll)

Patches used:

x264_psy_rdo_0.6.diff
x264_new_bframe_decision_04.5.diff <-- This patch is highly experimental, only enabled with --b-adapt 2. The --no-b-adapt parameter now works.
x264_hrd_pulldown.09_interlace.diff
x264.progress.indication.01.diff

gcc 3.4.5 fprofiled build.

[elguaxo]

thank you both! :)

[tobinaka]

Thank you Kemuri_09! I've just failed my encoding test through inattention of using --no-b-adapt with new B-frame decision patch.
And, thank you skystrife! Your continual posts help me follow the specific changes of patches in the past.
Of course, all the developers, too!

[Sagekilla]

Just my 2 cents, I don't know if it's done already but --no-b-aapt should be aliased to --b-adapt 0 ;)

[J_Darnley]

i worked on it a bit and got it to where it will accept --no-b-adapt properly
x264_new_bframe_decision_04.5.diff (http://kemuri9.net/dev/x264/patches/x264_new_bframe_decision_04.5.diff)
Would like to have DS and/or akupenguin look at it as it could probably be simplified
(I just couldn't manage to simplify it as i had tried in a few ways)

Another way to fix that --no-b-adapt problem is with the following changes to x264.c (pruned):
#define OPT_PROGRESS 261
#define OPT_VISUALIZE 262
#define OPT_LONGHELP 263
+#define OPT_NO_B_ADAPT 264
Add a one-of-these so that you can get a special case when parsing arguments/options

+ { "b-adapt", required_argument, NULL, 0 },
+ { "no-b-adapt", no_argument, NULL, OPT_NO_B_ADAPT },
Add the case into the option structure

param->i_scenecut_threshold = -1;
- param->b_bframe_adaptive = 0;
+ param->i_bframe_adaptive = X264_B_ADAPT_NONE;
break;
+ case OPT_NO_B_ADAPT:
+ param->i_bframe_adaptive = X264_B_ADAPT_NONE;
+ break;
Add the case and what to do.

Full diff based on the 03 patch (the one that has the X264_BUILD change): http://pastebin.com/m290ab8ae
I called it x264_newBframe_0.31.diff here but you guys can argue over that.

Since the --no-b-adapt option is removed from the help, there is always the option of just removing that option and having x264 error with "unknown option -- no-b-adapt". I guess that is not desired because that is not really different to the current behavior except that it now has the scary words "invalid argument: no-b-adapt = (null)" to scare people away.

Oh, I also have a white space corrected psyRDO patch that avoids using the --ignore-whitespace (-l for you terse people) if anyone feels there is a need for it.

[Ranguvar]

x264 can be licensed and used as a commercial product...
however the point is quite different. IIRC ICC for linux wont produce binaries for windows... so it's quite useless for windows users also, icc for windows is a fully commercial product that will cost $$$. the evaluation version is fully working but it's time limited...
on the other side we have gcc, that's free/OSS, multiplatform and produces faster x264 binaries.
It's quite obvious what to choose...

I like supporting open source projects, and GCC is no exception. I never said ICC was better than GCC -- just faster, usually. I also never said ICC should replace GCC. I just wanted to note that ICC is far from crap. Everything has its limitations. GCC tends to be slower, ICC gets the short end of the stick in almost everything else. The entire idea was just an odd thought anyways. If, somehow, x264 started working with ICC at several times the speed (obviously just an analogy) then I think even you would be anxious to test it out... a 'free' speedup for as much as ICC has done with other apps makes me very anxious to check it out with x264.

Again, this was all just a whim :rolleyes:

@kemuri-_9: Thanks very much for the patch! :)

[kemuri-_9]

Since the --no-b-adapt option is removed from the help, there is always the option of just removing that option and having x264 error with "unknown option -- no-b-adapt". I guess that is not desired because that is not really different to the current behavior except that it now has the scary words "invalid argument: no-b-adapt = (null)" to scare people away.

It's wanted for backwards compatibility for those who are using it with --no-b-adapt still
a patch can provide new features but should not ruin compatibility with unpatched builds - removing still usable options.

I figured out what i was trying to do after looking over it a bit more, updated it on my site - super simplified now, even more than how you were doing it.

the critical change is now
- p->b_bframe_adaptive = atobool(value);
+ {
+ p->i_bframe_adaptive = atobool(value);
+ if( !b_error ) return 0;
+ b_error = 0;
+ p->i_bframe_adaptive = atoi(value);
+ }

basically says
1. try and accept this as a boolean (as it originally was - maintaining backwards compatibility)
2. if it works accept the value and leave/stop.
3. if it breaks, reset the error (so x264 doesn't cry and /wrists on us)
4. accept as an int (gaining the new --b-adapt <int> functionality)

Edit: I've been editing the pissfire out of this post :<

[martino]

now if someone on a core2 would compare a -march=k8 to a -march=pentium2 and see what the results are, we can settle this completely.
Well, I was hoping that someone other than the lazy me would have done it, but seems like my hopes were short-lived, so here goes one test that I did with all the binaries that you put up.

http://martino.pastebin.com/f7caae7e8
(the last one, x264_mine, was just my own build, without any flags specified)

This was on a C2D E6750 @ 3.2 GHz.


UPDATE: http://martino.pastebin.com/f55e48a4a (5000 frames of the same clip)

[Adub]

That's interesting, considering yours is the fastest on the 1st pass. Not quite so, on the second, but close enough.

So, no flags beats flags? o_0

[akupenguin]

http://martino.pastebin.com/f55e48a4a
Fail: one run of each is never statistically significant. And I seriously doubt your times are repeatable to within 0.1%, which is what they'd need to be to get the same ordering after averaging a bunch of trials.
Also, x264_mine produced different results (different frametype even), so it's not the same code. Either that or gcc screwed up, but given the number of patches around I think the former is more likely.

[martino]

Oh yes indeed, I forgot that my one didn't have the bframe patch... :/

[Sharktooth]

That's interesting, considering yours is the fastest on the 1st pass. Not quite so, on the second, but close enough.

So, no flags beats flags? o_0
not properly... his build had no b-frame patch...
however, with x264 optimization flags are almost useless, so are the "core2" or "k8" optimized builds... so are the ICC builds... etc.
all the hard stuff is optimized by and in asm, so the compiler wont make any noticeable difference.

[Adub]

Ah, that's right. I had forgotten that he excluded the b-frames patch.

[Ranguvar]

bob0r, skystrife, may I ask how you are compiling the DLL? I know how to do it, but x264 seems to need some modifications (http://avidemux.org/admForum/viewtopic.php?pid=28804) before the DLL will work in AviDemux. Is that exactly what you have done?

[LoRd_MuldeR]

bob0r, skystrife, may I ask how you are compiling the DLL? I know how to do it, but x264 seems to need some modifications (http://avidemux.org/admForum/viewtopic.php?pid=28804) before the DLL will work in AviDemux. Is that exactly what you have done?

gcc 3.4.5 fprofiled build.

They use GCC 3.4.5/3.4.6, hence it can not work with Avidemux. You need to use GCC 4.x.x plus the "DLL Aligment-Fix" patch in order to get a working x264 DLL.
Also any patches other than "Psy RDO" will break compatibility to Avidemux, except for patches that don't change the API. Without "Psy RDO" it won't work either.
Finally the new B-Frames patch causes weird things in Avidemux: The last few frames are lost in CRF and 2-Pass will crash at the end of the second pass...

I provide Avidemux compatible builds here regularly:
http://forum.doom9.org/showthread.php?p=1175312#post1175312

[Ranguvar]

Alright, thanks for the info.

Is there a diff for the alignment fix available? That way, I can at least create working DLLs for other apps that use it.

[LoRd_MuldeR]

Alright, thanks for the info.

Is there a diff for the alignment fix available? That way, I can at least create working DLLs for other apps that use it.

In fact all you need to do is adding one single line with __attribute__((force_align_arg_pointer)) right before the "x264_encoder_encode" function :)

Here is the diff, which I currently use:
diff --git a/encoder/encoder.c b/encoder/encoder.c
index cffaeeb..34cbe8c 100644
--- a/encoder/encoder.c
+++ b/encoder/encoder.c
@@ -1222,6 +1222,7 @@ static int x264_slices_write( x264_t *h )
* B 5 2*4
* B 6 2*5
****************************************************************************/
+__attribute__((force_align_arg_pointer))
int x264_encoder_encode( x264_t *h,
x264_nal_t **pp_nal, int *pi_nal,
x264_picture_t *pic_in,

It shows a warning while patching, but does work anyway ^^

[Ranguvar]

Thanks :) I knew what line to add, but I was hoping to get a diff, since I have a script set up to compile x264, and just doing a diff patch is simple :)

[Ranguvar]

http://sites.google.com/site/ranguvar13/x264-builds

Direct download (http://sites.google.com/site/ranguvar13/x264-builds/rang_x264_r0949.7z?attredirects=0), Mirrors (http://www.uploadjockey.com/download/2880965/rang_x264_r0949_1.7z)

x264 r949 from Git (patched).

Open this archive with the free, multi-platform tool 7-Zip or p7zip. Compressed with LZMA.
The src folder contains the patched source code.
The bin folder contains a binary executable for all i686-compatible Windows PCs with MMX support,
and a DLL for usage in some applications (with the notable exception of AviDemux).

Official source and vanilla builds: http://x264.nl/
Changelog: http://git.videolan.org/gitweb.cgi?p=x264.git;a=shortlog
Patches and discussion at Doom9's forum: http://forum.doom9.org/


Applied patches (included, unchanged, in the patches folder):

patch -p1 < ../x264diffs/x264_dll_alignment_fix.01.diff
patch < ../x264diffs/x264.progress.indication.01.diff
patch -p1 < ../x264diffs/x264_hrd_pulldown.09_interlace.diff
patch -p1 -l < ../x264diffs/x264-psyrd-0.6.diff
patch -p1 < ../x264diffs/x264_new_bframe_decision_04.5.diff


Compiled by Ranguvar on August 26th, 2008, with GCC 4.3.1 on Windows XP Professional x64 SP2.

CLI used: ./configure --enable-shared --extra-cflags="-march=pentium2 -pipe" && make fprofiled VIDS="../enctests/deadline_cif.y4m"

Platform: X86
System: MINGW
asm: yes
avis input: yes
mp4 output: yes
pthread: yes
gtk: no
debug: no
gprof: no
PIC: no
shared: yes
visualize: no

[kemuri-_9]

however, with x264 optimization flags are almost useless, so are the "core2" or "k8" optimized builds... so are the ICC builds... etc.

actually if you looked at the logs i generated from the profiling, the k8 was rather consistently faster than the pentium2 on my AMD cpu.
so it looks like
intel line -> -march=pentium
amd line -> -march=k8
(boy wouldn't that normally be obvious?)

but the core2 side of things seems to need a bit more testing between the k8 and pentium2.

I don't have a core2, so would be asking someone else these tasks.
and my logs also consistently showed that 3.4.x was faster than 4.3.1,
so only if you need that dll would you choose 4.3.1 for compiling it, should still use 3.4.x for the binary.

[Sharktooth]

but was the speed gain worth it?
i mean if you were to release a generic build, what would you choose?

[kemuri-_9]

yeah for an overall generic build i would probably do a pentium2, but if you can offer both, then do that too...

couldn't you write some C# (in megui... it's C# right?) to check the Windows environment vars to see what the processor is and give them one matching their CPU?

i mean, there's gotta be something that can grab and check the PROCESSOR_IDENTIFIER variable and see if it contains 'AMD' or 'Intel'

should try a -march=k6 build and see how it does, since it's practically the AMD version of the p2. guess i'll get on that later.

[Ranguvar]

I'm gonna guess that if march=k8 is faster on AMD CPU's, it's because of the 3dNOW! and 3dNOW!+.

So, march=athlon should be the best choice for AMD, as it works with both of those but doesn't require much else :)

[LoRd_MuldeR]

couldn't you write some C# (in megui... it's C# right?) to check the Windows environment vars to see what the processor is and give them one matching their CPU?

You could simply run "cpuinfo.exe" (download (http://oss.netfarm.it/mplayer-win32.php)) and parse the console output...

[skystrife]

Just a note for all the patchers:

.:8:44.04pm:. ( skystrife ) psyrd haet commit
.:8:44.12pm:. ( Dark_Shikari ) skystrife: it does.
.:8:44.27pm:. ( Dark_Shikari ) I will have to do a significant but trivial rewrite of psy-RD

x264_psyrdo_0.6.diff won't patch with r950.

[skystrife]

x264.950.modified.exe (http://www.mediafire.com/?vecakajaaqy) - Alternate Download (http://skystrife.com/x264/x264.950.modified.exe)
(discontinuing dll unless someone was using it for something other than avidemux and had it working as I was building it; I'm not shifting from 3.4.5)

Patches used:

x264_psy_rdo_0.6_r950.diff <-- Updated to patch with r950 (check psyRDO thread).
x264_new_bframe_decision_04.5.diff <-- This patch is highly experimental, only enabled with --b-adapt 2. The --no-b-adapt parameter now works. Updated version.
x264_hrd_pulldown.09_interlace.diff
x264.progress.indication.01.diff

gcc 3.4.5 fprofiled build.

[kemuri-_9]

So, march=athlon should be the best choice for AMD, as it works with both of those but doesn't require much else :)
confirmed ;)

pentium2 (for ez link access) (http://kemuri9.net/dev/x264/x264_profile.gcc-3.4.5.pentium2.log)
AMD Series:
k6 (http://kemuri9.net/dev/x264/x264_profile.gcc-3.4.5.k6.log), k6-2 (http://kemuri9.net/dev/x264/x264_profile.gcc-3.4.5.k6-2.log), athlon (http://kemuri9.net/dev/x264/x264_profile.gcc-3.4.5.athlon.log)

k6 was slow to p2.
k6-2 was better, but still slower than p2.
athlon was where it hit faster than p2 on a nearly consistent basis.

[Ranguvar]

http://sites.google.com/site/ranguvar13/x264-builds

Direct download (http://sites.google.com/site/ranguvar13/x264-builds/rang_x264_r0950.7z?attredirects=0), Mirrors (http://www.rapidspread.com/file.jsp?id=nznfhwe88u)

x264 r950 from Git (patched).

Open this archive with the free, multi-platform tools 7-Zip or p7zip. Compressed with LZMA.
The src folder contains the patched source code.
The bin folder contains a binary executable for Athlon and later AMD CPUs (those with 3DNow! and 3DNow!+ support),
and one for those without. There are also DLLs for those apps that use them (NOT for AviDemux).

Official source and vanilla builds: http://x264.nl/
Changelog: http://git.videolan.org/gitweb.cgi?p=x264.git;a=shortlog
Patches and discussion at Doom9's forum: http://forum.doom9.org/


Applied patches (included, unchanged, in the patches folder):

patch -p1 < ../x264diffs/x264_dll_alignment_fix.01.diff
patch < ../x264diffs/x264.progress.indication.01.diff
patch -p1 < ../x264diffs/x264_hrd_pulldown.09_interlace.diff
patch -p1 < ../x264diffs/x264-psyrd-0.6.r950.diff
patch -p1 < ../x264diffs/x264.new.bframes.decision.04.5.diff


Compiled by Ranguvar on August 27th, 2008, with GCC 4.3.1 on Windows XP Professional x64 SP2.

CLI used for non-AMD build: ./configure --enable-shared --extra-cflags="-march=pentium2 -pipe" && make fprofiled VIDS="../enctests/deadline_cif.y4m"
CLI used for AMD build: ./configure --enable-shared --extra-cflags="-march=athlon -pipe" && make fprofiled VIDS="../enctests/deadline_cif.y4m"

Platform: X86
System: MINGW
asm: yes
avis input: yes
mp4 output: yes
pthread: yes
gtk: no
debug: no
gprof: no
PIC: no
shared: yes
visualize: no

[Ranguvar]

Thanks, kemuri, for the continued research! :D

[gigah72]

ot:
where can i get the needed package/tools to add the version info to the build?
or can someone upload the needed files?

[Ranguvar]

Kemuri, I believe, posted the list of stuff needed a while back. Find that and then use Google. First search with "mingw" added to see if there's a binary out there, otherwise, compile from source.

Hint: I believe everything you need is on the MinGW Sourceforge page, except for Git, which can be found by installing msysgit and then grabbing its stuff. Doing a ./configure will tell you if you're missing something.

[bob0r]

bob0r, skystrife, may I ask how you are compiling the DLL? I know how to do it, but x264 seems to need some modifications (http://avidemux.org/admForum/viewtopic.php?pid=28804) before the DLL will work in AviDemux. Is that exactly what you have done?


My .dll has no modifications, other than the patches themself.
Compared to the GIT-code.

[kemuri-_9]

if the build doesn't include the revision number which it's automatically configured to do on compilation, then it doesn't have access to some CLI utils:
GIT CLI : git-rev-list, git-status
binutils: awk (usually via gawk or mawk), grep, head, join, sed, sort, wc
be sure these binaries are on the PATH environment variable or it won't be able to include the revision number within the build.

many of these are part of Msys:
https://sourceforge.net/project/showfiles.php?group_id=2435&package_id=24963
coreutils package: head, join, sort, wc
msysCORE package: sed
gawk package: awk (via gawk)

the GIT CLI i have via msysgit:
http://code.google.com/p/msysgit/downloads/list
msysgit has LOTS of stuff in it besides just git cli binaries as well...
as it can fully create a working bash shell to for cli usage if you don't want to use the gui and don't want to have it in your windows PATH variable to use within the command prompt.
in fact msysgit comes with awk (via gawk), grep, head, sed, sort, wc (only missing join for needed purposes)

[Ranguvar]

@bob0r: OK, so your DLL is b0rked, too... read back a few pages :)

[gigah72]

many of these are part of Msys:
https://sourceforge.net/project/showfiles.php?group_id=2435&package_id=24963
coreutils package: head, join, sort, wc
msysCORE package: sed
gawk package: awk (via gawk)

the GIT CLI i have via msysgit:
http://code.google.com/p/msysgit/downloads/list
msysgit has LOTS of stuff in it besides just git cli binaries as well...
as it can fully create a working bash shell to for cli usage if you don't want to use the gui and don't want to have it in your windows PATH variable to use within the command prompt.
in fact msysgit comes with awk (via gawk), grep, head, sed, sort, wc (only missing join for needed purposes)

thanks,
i put all the files together, but now this:
fatal: Not a git repository

any idea what's wrong in the setup?

[Ranguvar]

@gigah72: You need to download x264 from Git, and make sure not to delete the .git folder in the downloaded files. (git clone git://git.videolan.org/x264.git)

@all: r950 was b0rked until now, only use binaries compiled after this post...

[Dark Shikari]

Warning to all: r950 was b0rked until now, only use binaries compiled after this post...Correct, I made a typo in the commit and modified history in order to fix it. You'll have to re-update your sources and recompile.

[Ranguvar]

http://sites.google.com/site/ranguvar13/x264-builds

Direct download (http://sites.google.com/site/ranguvar13/x264-builds/rang_x264_r0950-2.7z?attredirects=0), Mirrors (http://www.rapidspread.com/file.jsp?id=rsk1zh9m1w)

x264 r950 (NON-B0RKED VERSION) from Git (patched).

Open this archive with the free, multi-platform tools 7-Zip or p7zip. Compressed with LZMA.
The src folder contains the patched source code.
The bin folder contains a binary executable for Athlon and later AMD CPUs (those with 3DNow! and 3DNow!+ support),
and one for those without. There are also DLLs for those apps that use them (NOT for AviDemux).

Official source and vanilla builds: http://x264.nl/
Changelog: http://git.videolan.org/gitweb.cgi?p=x264.git;a=shortlog
Patches and discussion at Doom9's forum: http://forum.doom9.org/


Applied patches (included, unchanged, in the patches folder):

patch -p1 < ../x264diffs/x264_dll_alignment_fix.01.diff
patch < ../x264diffs/x264.progress.indication.01.diff
patch -p1 < ../x264diffs/x264_hrd_pulldown.09_interlace.diff
patch -p1 < ../x264diffs/x264-psyrd-0.6.r950.diff
patch -p1 < ../x264diffs/x264.new.bframes.decision.04.5.diff


Compiled by Ranguvar on August 27th, 2008, with GCC 4.3.1 on Windows XP Professional x64 SP2.

CLI used for non-AMD build: ./configure --enable-shared --extra-cflags="-march=pentium2 -pipe" && make fprofiled VIDS="../enctests/deadline_cif.y4m"
CLI used for AMD build: ./configure --enable-shared --extra-cflags="-march=athlon -pipe" && make fprofiled VIDS="../enctests/deadline_cif.y4m"

Platform: X86
System: MINGW
asm: yes
avis input: yes
mp4 output: yes
pthread: yes
gtk: no
debug: no
gprof: no
PIC: no
shared: yes
visualize: no

[egrimisu]

hi where can i get the latest and a good one x264 encoder with psyrdo 0.6?

[alfadude]

hi where can i get the latest and a good one x264 encoder with psyrdo 0.6?
In this thread only a few posts back.

[egrimisu]

In this thread only a few posts back.

and who's build would you recomad?

[alfadude]

Skystrife builds them to my satisfaction. :-)

[egrimisu]

Skystrife builds them to my satisfaction. :-)

is there a optimized version for core2duo?

is renguvar release better than hte one you like? i saw that your preferd one's latest version has some bframa i don't know what in experimental mode!!!

[alfadude]

Try it and you will see which one you like best.

The new bframes method is slow when used with many bframes but as standard all builds still use the old method. If you want to test the new method put --b-adapt 2 in your command line.

This is not new information, it was all already answered for those who like to read.

[akupenguin]

I'm gonna guess that if march=k8 is faster on AMD CPU's, it's because of the 3dNOW! and 3dNOW!+.
gcc doesn't use 3dnow nor mmx, not even if -march / -mmmx / -m3dnow allow it. (The rationale (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14552) is that using mmregs requires emms and gcc is too stupid to figure out where to put emms.) This statement applies not only to autovectorization, but even to generic vector intrinsics (__attribute__((vector_size))). Only explicit 3dnow intrinsics use 3dnow.

[Sharktooth]

is there a optimized version for core2duo?

is renguvar release better than hte one you like? i saw that your preferd one's latest version has some bframa i don't know what in experimental mode!!!
here we go... again...get a generic build.

[skystrife]

x264.950.modified.02.exe (http://www.mediafire.com/?e030nattaca) - Alternate Download (http://skystrife.com/x264/x264.950.modified.02.exe)
(discontinuing dll unless someone was using it for something other than avidemux and had it working as I was building it; I'm not shifting from 3.4.5)

Patches used:

x264_psy_rdo_0.6_r950.diff <-- Updated to patch with r950 (check psyRDO thread).
x264_new_bframe_decision_04.5.diff <-- This patch is highly experimental, only enabled with --b-adapt 2. The --no-b-adapt parameter now works. Updated version.
x264_hrd_pulldown.09_interlace.diff
x264.progress.indication.01.diff

gcc 3.4.5 fprofiled build.

[kemuri-_9]

gcc doesn't use 3dnow nor mmx, not even if -march / -mmmx / -m3dnow allow it. (The rationale (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14552) is that using mmregs requires emms and gcc is too stupid to figure out where to put emms.) This statement applies not only to autovectorization, but even to generic vector intrinsics (__attribute__((vector_size))). Only explicit 3dnow intrinsics use 3dnow.

if that's true, then what is gcc doing with -march=athlon to make it faster for AMDs than -march=pentium2?

*Removed all profiling logs and binaries for builds besides -march=athlon and -march=pentium2 from my site.*

[akupenguin]

Instruction choice and scheduling. Very often there are several possible instructions that fill the same role, such as add/shift/lea/mul, and different combinations are faster on different cpus.

[bob0r]

@skystrife:
x264_new_bframe_decision_04.5.diff where to get?

[Ranguvar]

Kemuri posted it a while back in this thread.

But it's not patching with r951 right now...

[cyberbeing]

@skystrife:
x264_new_bframe_decision_04.5.diff where to get?
kemuri-_9 posted it here: http://forum.doom9.org/showpost.php?p=1175019&postcount=774

[J_Darnley]

Look up, to post #774 (http://forum.doom9.org/showthread.php?p=1175019#post1175019).

[kemuri-_9]

I just tried it on r951, has a rejection, see if i can fix it.

EDIT:
r951 had this alteration
index 3b720af..5217253 100644
@@ -299,9 +299,11 @@ void x264_frame_init_lowres( x264_t *h, x264_frame_t *frame )
i_stride, frame->i_stride_lowres, frame->i_width_lowres, frame->i_lines_lowres );
x264_frame_expand_border_lowres( frame );

- for( y=0; y<16; y++ )
- for( x=0; x<16; x++ )
- frame->i_cost_est[y][x] = -1;
+ memset( frame->i_cost_est, -1, sizeof(frame->i_cost_est) );
+
+ for( x = 0; x < h->param.i_bframe + 2; x++ )
+ for( y = 0; y < h->param.i_bframe + 2; y++ )
+ frame->i_row_satds[y][x][0] = -1;
}

static void frame_init_lowres_core( uint8_t *src0, uint8_t *dst0, uint8_t *dsth, uint8_t *dstv, uint8_t *dstc,

which creates a rejection for the new bframe patch located at
@@ -299,9 +299,7 @@ void x264_frame_init_lowres( x264_t *h, x264_frame_t *frame )
i_stride, frame->i_stride_lowres, frame->i_width_lowres, frame->i_lines_lowres );
x264_frame_expand_border_lowres( frame );

- for( y=0; y<16; y++ )
- for( x=0; x<16; x++ )
- frame->i_cost_est[y][x] = -1;
+ memset( frame->i_cost_est, -1, sizeof(frame->i_cost_est) );
}

static void frame_init_lowres_core( uint8_t *src0, uint8_t *dst0, uint8_t *dsth, uint8_t *dstv, uint8_t *dstc,

so.... functionally, the change was already added in (or reads to me that way), so the fix is to strike the mc.c sections from the .diff:
x264_new_bframe_decision_04.6.diff -- link removed
DS/akupenguin, is this reasoning correct?

[Ranguvar]

I (with Kovensky's help) just did :)

http://pastebin.com/f4c77facb


EDIT: NVM, that one fails upon compile. Here's Sharktooth's.

http://www.webalice.it/f.corriga/x264/x264_new_bframe_decision_04.6.diff

[kemuri-_9]

you still have the

- int x, y;
+ int y;

section, the new r951 code still uses x; so that section needs to be removed too (as i did in mine)

[Ranguvar]

http://sites.google.com/site/ranguvar13/x264-builds

Direct download (http://sites.google.com/site/ranguvar13/x264-builds/rang_x264_r0951.7z?attredirects=0), Mirrors (http://www.rapidspread.com/file.jsp?id=uatst2lss5)

x264 r951 from Git (patched).

Open this archive with the free, multi-platform tools 7-Zip or p7zip. Compressed with LZMA.
The src folder contains the patched source code.
The bin folder contains a binary executable for Athlon and later AMD CPUs (those with 3DNow! and 3DNow!+ support),
and one for those without. There are also DLLs for those apps that use them (NOT for AviDemux).

Official source and vanilla builds: http://x264.nl/
Changelog: http://git.videolan.org/gitweb.cgi?p=x264.git;a=shortlog
Patches and discussion at Doom9's forum: http://forum.doom9.org/


Applied patches (included, unchanged, in the patches folder):

patch -p1 < ../x264diffs/x264_dll_alignment_fix.01.diff
patch < ../x264diffs/x264.progress.indication.01.diff
patch -p1 < ../x264diffs/x264_hrd_pulldown.09_interlace.diff
patch -p1 < ../x264diffs/x264-psyrd-0.6.r950.diff
patch -p1 < ../x264diffs/x264.new.bframes.decision.04.6.diff


Compiled by Ranguvar on August 27th, 2008, with GCC 4.3.1 on Windows XP Professional x64 SP2.

CLI used for non-AMD build: ./configure --enable-shared --extra-cflags="-march=pentium2 -pipe" && make fprofiled VIDS="../enctests/deadline_cif.y4m"
CLI used for AMD build: ./configure --enable-shared --extra-cflags="-march=athlon -pipe" && make fprofiled VIDS="../enctests/deadline_cif.y4m"

Platform: X86
System: MINGW
asm: yes
avis input: yes
mp4 output: yes
pthread: yes
gtk: no
debug: no
gprof: no
PIC: no
shared: yes
visualize: no

[LoRd_MuldeR]

Ranguvar, what does --extra-cflags="-pipe" do ???

[Sharktooth]

speed up compiling using pipes... binaries are unchanged.
expecially useful on multicore CPUs.
-pipe

Use pipes rather than temporary files for communication between the various
stages of compilation. This fails to work on some systems where the assembler
is unable to read from a pipe; but the GNU assembler has no trouble.

[alexins]

Safe Cflags (http://gentoo-wiki.com/Safe_Cflags)

[kemuri-_9]

all of those who use gcc 4.3.1 should start looking for mingw versions of gcc 4.3.2 soon, since 4.3.2 released today.

[Ranguvar]

Thanks for the heads-up, kemuri :) 4.3.2 looks nice.

I'll wait until TDM posts a build.

[Underground78]

Does somebody know why the "git-status" command gives me this result :
# On branch master
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
#
# modified: build/win32/libx264.vcproj
# modified: build/win32/x264.sln
# modified: build/win32/x264.vcproj
# modified: gtk/fr.po
#
no changes added to commit (use "git add" and/or "git commit -a")

after a "git clone git://git.videolan.org/x264.git" without changing any of these files ?

[egrimisu]

Hi,

i tested ranguvar' 951-2 x264 with bob0r's 928. But i'm confunsed, since i have a small monitor right now (crt 14") i can't realy tell the diference for 2 encodes one rangulars and the other bob0r's . Another dilemma is that i set ~1800kbits/s for boths encodes, same settings and instead of a 314MB output with bob0r's i get 150mb and with ranguvar's i get a 250mb. Why the output can't be 314 as i set it? The speed is kind of the same, can't tell exactly since i done some other stuff with the meenwhile. Witch release would you recomand for anime encoding aprox 1700-2000kb with allmost all setting maxed out? the speed aprox is 3 hours (1pass) for a 24min anime.

[Ranguvar]

Hi,

i tested ranguvar' 951-2 x264 with bob0r's 928. But i'm confunsed, since i have a small monitor right now (crt 14") i can't realy tell the diference for 2 encodes one rangulars and the other bob0r's .
So? My build is newer, there's been quite a few changes since r928 (but note that bob0r also has newer builds). So, it should be higher quality at the same bitrate, yes. But that of course depends on your settings. Or, the bitrate may just be too high to see the difference.

Another dilemma is that i set ~1800kbits/s for boths encodes, same settings and instead of a 314MB output with bob0r's i get 150mb and with ranguvar's i get a 250mb. Why the output can't be 314 as i set it?

It could be a multitude of things. We'd need your settings to give more insight. And that belongs in its own thread, really...


Witch release would you recomand for anime encoding aprox 1700-2000kb with allmost all setting maxed out? the speed aprox is 3 hours (1pass) for a 24min anime.

Just grab a recent build with the patches you want. I of course prefer my own builds, but there's generally very little difference between builds of the same revision with the same patches.

[techouse]

thanks for the heads-up, kemuri :) 4.3.2 looks nice.

I'll wait until tdm posts a build.
+1 :)

P.S.: MSYS got updated yesterday as well ;) http://sourceforge.net/forum/forum.php?forum_id=860793

[Ranguvar]

Thanks for that, too ;)

Although I believe I already have that version, since msys died (again) and I re-did everything from scratch.

[skystrife]

x264.953.modified.exe (http://www.mediafire.com/?nv5cgawxeow) - Alternate Download (http://skystrife.com/x264/x264.953.modified.exe)

Patches used:

x264_psy_rdo_0.6_r953.diff (http://skystrife.com/x264/x264_psy_rdo_0.6_r953.diff) <-- Updated to patch with r953, removes changing X264_BUILD.
x264_new_bframe_decision_04.6.diff <-- This patch is highly experimental, only enabled with --b-adapt 2. The --no-b-adapt parameter now works. Updated version.
x264_hrd_pulldown.09_interlace.diff
x264.progress.indication.01.diff

gcc 3.4.5 fprofiled build.

[kemuri-_9]

nooooo.... now all my .stat files are poo with r953+ :(

[Sagekilla]

Could x264 have a modification to check if itex and ptex are both present, and if they are to use the sum of both?

[burfadel]

Skystrife, there's something wrong with your latest 953 build!

Settings used in all cases were:
--crf 24 --keyint 450 --ref 5 --mixed-refs --bframes 5 --b-pyramid --b-rdo --bime --weightb --direct auto --subme 7 --trellis 2 --partitions all --8x8dct --me umh --threads 4 --progress --thread-input --no-psnr --no-ssim --b-adapt 2

Except for the vanilla x264 which was the same without --b-adapt2, aka:
--crf 24 --keyint 450 --ref 5 --mixed-refs --bframes 5 --b-pyramid --b-rdo --bime --weightb --direct auto --subme 7 --trellis 2 --partitions all --8x8dct --me umh --threads 4 --progress --thread-input --no-psnr --no-ssim

With the vanilla 953, the encoding speed was 22.5fps

With 950 your build the speed was (remember with --b-adapt 2)
17.97 fps

With 953 your build the speed was 2.5fps!!
(actually I stopped the encode, the speed was continually dropping)!!

The clip was a short clip with high motion, but the same differences applies to all clips... your 953 build being chronically slow with those settings! Going by your 950 and the vanilla 953 build speeds, this must be due to a compiling/compliance (any modifications you made for the patch to work) induced by the 953 revision.

The processor used is a core 2 duo e6600.

Thanks!

[burfadel]

Out of interest, I did some tests with Ranguvar's x264 951 versions, again with the same settings as in the post above (different clip, high motion though):
--crf 24 --keyint 450 --ref 5 --mixed-refs --bframes 5 --b-pyramid --b-rdo --bime --weightb --direct auto --subme 7 --trellis 2 --partitions all --8x8dct --me umh --threads 4 --progress --thread-input --no-psnr --no-ssim --b-adapt 2

The AMD build got 15.64 and the non-AMD build got 15.32.

So the AMD build is faster on a core 2 than the non AMD build! :)

Skystrife's 950 build also got 15.64!

[techouse]

x264_x86_r953_techouse (http://techouse.project357.com/builds/x264_x86_r953_techouse.7z)
Source: x264 r953 GIT (git://git.videolan.org/x264.git)

Applied patches (current versions):

x264_progress.diff

x264_psy_rdo.0.6_r953.diff

x264_hrd_pulldown.09_interlace.diff

x264_new_bframe_decision_04.6.diff


Please check http://forum.doom9.org/showthread.php?t=130364 and http://git.videolan.org/gitweb.cgi?p=x264.git;a=shortlog for more info

Compiled by techouse on August 30th 2008, 14:13:32 CEST with GCC-4.3.2 on Windows Vista Business SP-1 64-bit.

Commandline used: ./configure --extra-cflags="-march=core2 -pipe" && make fprofiled

Platform: X86
System: MINGW
asm: yes
avis input: yes
mp4 output: yes
pthread: yes
gtk: no
debug: no
gprof: no
PIC: no
shared: no
visualize: no

P.S.: I've found it to be 4% faster than my r951 built with gcc 4.3.1 and the generic march option.

[LoRd_MuldeR]

x264 SVN-r953 + Psy RD (Psy Trellis) v0.6 + Gruntster's Alignment-Fix:
http://www.mediafire.com/?z9pj84ly2kg

Compiled with MinGW GCC 4.3.1-tdm-1 (fprofiled). Cannot notice any major speed-drop.

[burfadel]

The speed drop was definitely anomalous with the test I did earlier, I tried to show that :) I don't know what coudl have caused it, but its only with that one build that it occurred. The rest of the builds show speed along the lines that one would expect!... I've also tried more than one 953 modded build as well :)

[LoRd_MuldeR]

x264 SVN-r953 + Psy RD (Psy Trellis) v0.6 + Gruntster's Alignment-Fix:
http://www.mediafire.com/?emoikztuc7o

Compiled with MinGW GCC 4.3.2-tdm-1 (fprofiled). It seems GCC 4.3.2 doesn't break it :)

[kemuri-_9]

lol it's not on SVN anymore, so should probably get your tag right
and why are you doing the alignment fix if gcc doesn't have the problem?

[LoRd_MuldeR]

lol it's not on SVN anymore, so should probably get your tag right
and why are you doing the alignment fix if gcc doesn't have the problem?

Because my "x264.exe" is simply a waste-product when building the libx264.dll for Avidemux :D

And I stick to SVN revision numbers, because everybody is using them and because those git hashcodes are not very user friendly...

[skystrife]

The speed drop was definitely anomalous with the test I did earlier, I tried to show that :) I don't know what coudl have caused it, but its only with that one build that it occurred. The rest of the builds show speed along the lines that one would expect!... I've also tried more than one 953 modded build as well :)

So another r953 build with the same patches doesn't exhibit the issue? Was it compiled with gcc 4?

[burfadel]

The build of 953 that I tried was Kemuri's. Kemuri's 953 is built with GCC 3.4.5 according to the text file on the website

Techouse's build shown at post 847 is built with GCC-4.3.2. and that DOES have the same problem as yours (Skstrife's)!

Lord_mulder's build also works fine (without --b-adapt 2 of course, since that build doesn't include that patch)

After taking out --b-adapt 2 your build works fine! so it must be something relating to the way the b-frame decision patch is applied.

Whatever Kemuri has done differently could be the key...

[skystrife]

The builds of 953 that I tried were Kemuri's and Techouse's. Kemuri's 953 is built with GCC 3.4.5 according to the text file on the website, and techouse build shown at post 847 is GCC-4.3.2.

Both of those builds worked fine!

Lord_mulder's build also works fine (without --b-adapt 2 of course, since that build doesn't include that patch)

Confirmed bug, I had a broken patch it seems. Making a new build now.

EDIT:

x264.953.modified.02.exe (http://www.mediafire.com/?qcjlxdaciei) - Alternate Download (http://skystrife.com/x264/x264.953.modified.02.exe)

Apologies for not catching the bug earlier.

[burfadel]

Thanks! just did a quick test (about 10 seconds worth)! and now it works fine! I made a mistake in my earlier post that you referenced (I corrected it), the Techouse build did exhibit the same issue as yours.

[kemuri-_9]

Hmm... looking back at my profiling logs with r953, -march=athlon is now slower than -march=pentium2...
so i tried some other AMD -march types, and athlon-xp (the next higher chip) was back to being faster than pentium2 again....

logs:
pentium2 (http://kemuri9.net/dev/x264/x264_profile.i686.gcc-3.4.5.pentium2.log)
athlon (http://kemuri9.net/dev/x264/x264_profile.i686.gcc-3.4.5.athlon.log), athlon-xp (http://kemuri9.net/dev/x264/x264_profile.i686.gcc-3.4.5.athlon-xp.log), k8 (http://kemuri9.net/dev/x264/x264_profile.i686.gcc-3.4.5.k8.log)

really weird at how -march=athlon slowed down drastically on the average from r951 to r953....
might have been related to the giant rceq code scrapping, but i wouldn't know for sure.

Once again this is only relevant for people on AMD CPUs.
you Intel folk can just ignore the jibber :p

[skystrife]

Could x264 have a modification to check if itex and ptex are both present, and if they are to use the sum of both?

http://skystrife.com/x264/x264_itex_ptex_compatibility_sum.01.diff

I know quite literally next to nothing about coding in C, so someone let me know if that's an absolutely, completely and utterly retarded way of accomplishing this.

A sample binary (psyrd, new bframe, hrd, progress, and the above patch):

x264.953.modified.03.exe (http://www.mediafire.com/?oejvdrw2luk) - Alternate Download (http://skystrife.com/x264/x264.953.modified.03.exe)

[kemuri-_9]

imo it would be more practical to write a conversion program to just convert the old format to the new one, rather than actually having it scan for both which would slow down the reading/scanning section some.

if you want to continue doing a double format scanner, it would be easier to use
if (strstr(p, "itex") != NULL)
as a detecter to detect if it's the old format

[akupenguin]

perl -pi~ -e 's/itex:(\d+) ptex:(\d+)/"tex:".($1+$2)/e'

[LoRd_MuldeR]

Why do people want to use old stats files anyway?

Isn't it highly recommended to create the stats file with the same revision that is used to do the final encode ???

[kemuri-_9]

the differences between r951 and r953 were pretty much the rceq removal and the .stats change,
otherwise there was no functional difference;
if you had a bunch of .stats made from r951, you wouldn't want to spend the time remaking them now would you?

are you trying to say that i should knowingly use an old revision of x264 when there's plenty of feature updates and bug fixes that can still use the old stats file in a new revision?
that's basically shooting yourself in the foot.

[LoRd_MuldeR]

the differences between r951 and r953 were pretty much the rceq removal and the .stats change,
otherwise there was no functional difference;
if you had a bunch of .stats made from r951, you wouldn't want to spend the time remaking them now would you?

are you trying to say that i should knowingly use an old revision of x264 when there's plenty of feature updates and bug fixes that can still use the old stats file in a new revision?
that's basically shooting yourself in the foot.

Unless there was a "major" change, it should be save to use old stats files, yes.
However you could simply stick to the older version to complete your encode in that case.

And if there was a "major" change, you should repeat both passes with the new version...

[kemuri-_9]

the 1st pass /.stats are pretty much only used for frame decisions (as far as i've gathered),
so unless there was a change in the way frames are decided from one revision to the next, you can update without a hitch.

[LoRd_MuldeR]

the 1st pass /.stats are pretty much only used for frame decisions (as far as i've gathered),
so unless there was a change in the way frames are decided from one revision to the next, you can update without a hitch.

I'm pretty sure the information from the stats file are also used to calculate the bitrate distribution during the second pass.
And the bitrate can change significantly with new features like VAQ, Psy RDO/Trellis. There's a reason why Psy + VAQ should already be ON in the first pass.

[Sharktooth]

psy-rdo isnt needed in the first pass. also bitrate is computed in the second pass (IIRC). however, i still cant understand why you should reuse the stats files. i usually delete them when im finished encoding.

[kemuri-_9]

for anime related things, we do things by the release candidate system, often the video can get re-encoded a few times.

edit:
for those that don't wanna install a scripting language to convert to the new format:
stat_convert.php (http://kemuri9.net/dev/x264/stat_convert.php)

[MythCreator]

a problem“
I set --asm sse3， but CLI still using SSE2

And then,Just a advice, please add SSE4A support...

[Sharktooth]

why it's an advice? are you sure sse4a will add to the encoder speed? i think not... if it was usefull it would have been added...
however what's --asm sse3?

[MythCreator]

--asm <integer> Override CPU detection

[LoRd_MuldeR]

I set --asm sse3 but CLI still using SSE2

Because there is no SSE3 code in x264 yet !?!?

And then,Just a advice, please add SSE4A support...

Do you know any function in x264 that would actually benefit from SSE4A instructions? :rolleyes:

[Sharktooth]

--asm <integer> Override CPU detection
--asm <integer>
integer is an integer value ... not a string...

@lord_mulder: there is SSE3 in x264...

[LoRd_MuldeR]

@lord_mulder: there is SSE3 in x264...

I think there only is SSSE3 code in x264 at the moment...

From my Q6600 system:
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64

The CPU has "SSE3" as well as "SSSE3", but x264 only uses the latter.

[komisar]

--asm <integer>
integer is an integer value ... not "sse3"...

@lord_mulder: there is SSE3 in x264...
Try this for you:
x264 --asm Altivec,MMX2
This also work...
All recognized flags:Altivec,MMX2,MMXEXT,SSE2Slow,SSE2,SSE2Fast,SSE3,SSSE3,PHADD,SSE4,Cache32,Cache64,Slow_mod4_stack

[akupenguin]

--asm sse3,cache64 if you want to force it to use a version of the sad function that is slower than what it picks automatically...
sse3 works only on pentium4D. it is completely useless on all other cpus, including core2 and k8.

[skystrife]

x264.955.modified.exe (http://www.mediafire.com/?xd334ayvaut) - Alternate Download (http://skystrife.com/x264/x264.955.modified.exe)

Patches used:

x264_psy_rdo_0.6_r953.diff
x264_new_bframe_decision_04.6.diff <-- This patch is highly experimental, only enabled with --b-adapt 2. The --no-b-adapt parameter now works.
x264_hrd_pulldown.09_interlace.diff
x264.progress.indication.01.diff

gcc 3.4.5 fprofiled build.

[Avenger007]

x264_new_bframe_decision_04.6.diff <-- This patch is highly experimental, only enabled with --b-adapt 2. The --no-b-adapt parameter now works.
What is "highly experimental" about the new_bframe_decision patch? :confused:

[LoRd_MuldeR]

What is "highly experimental" about the new_bframe_decision patch? :confused:

It's really slow when allowing a high number of consecutive b-frames. Future improvements might solve this problem...
Also it causes crazy things when used with Avidemux, I still wonder why :confused:

[burfadel]

With numerous tests, it seems around 5 to 6 b-frames with the new patch is ideal for both speed and output... (3 or 4 still provides excellent results though)! Any higher even with anime didn't seem to make much different, except for the slowdown :)

[bob0r]

you still have the

- int x, y;
+ int y;

section, the new r951 code still uses x; so that section needs to be removed too (as i did in mine)


Any proper x264_new_bframe_decision_04.X.diff then?

[kemuri-_9]

i looked at the results from a build with keeping the modifying the r951 section to one that removed it.
there was no difference in results in my tests,
so i would say to just remove it, which is how the one Sharktooth posted is.

[bob0r]

i looked at the results from a build with keeping the modifying the r951 section to one that removed it.
there was no difference in results in my tests,
so i would say to just remove it, which is how the one Sharktooth posted is.

Ok, you should edit your post or remove your link for clearness. Usually you guys have to modify dead projects to make .diff files work, but Dark is still very active on both psyrdo and new-b-frame, so i have aksed him if he can check the patches and if needed modify so we got the correct patches. (New build coming up after some vbv-speed issue patch is commited, should be r956 and soon :D)

[bob0r]

x264.956.modified.01.exe (http://files.x264.nl/x264.956.modified.01.exe)
libx264-61.956.modified.01.dll (http://files.x264.nl/libx264-61.956.modified.01.dll)

x264_psy_rdo_0.6_r953.diff (on by default, adjust with: --psy-rd)
x264_new_bframe_decision_04.7.diff (highly experimental, enabled with: --b-adapt 2, changes: removed the mc.c hunk, based on Dark_Shikari's words)
x264_hrd_pulldown.09_interlace.diff
x264.progress.indication.01.diff


Patchting process:
patch -p1 -l < x264_psy_rdo_0.6_r953.diff (http://files.x264.nl/x264_patches/x264_psy_rdo_0.6_r953.diff) ( -l parameter = ignore whitespaces )
patch -p1 < x264_new_bframe_decision_04.7.diff (http://files.x264.nl/x264_patches/x264_new_bframe_decision_04.7.diff)
patch -p1 < x264_hrd_pulldown.09_interlace.diff (http://files.x264.nl/x264_patches/x264_hrd_pulldown.09_interlace.diff)
patch -p0 < x264.progress.indication.01.diff (http://files.x264.nl/x264_patches/x264.progress.indication.01.diff)

Quote:

[20:52] (x'Dark_Shikari): .......
[20:52] (x'Dark_Shikari): for( x = 0; x < h->param.i_bframe + 2; x++ )
[20:52] (x'Dark_Shikari): - for( y = 0; y < h->param.i_bframe + 2; y++ )
[20:52] (x'Dark_Shikari): - frame->i_row_satds[y][x][0] = -1;
[20:52] (x'Dark_Shikari): WHO IS MAKIN THESE PATCHES? <-- refering to x264_new_bframe_decision_04.6.diff
[20:53] (x'Dark_Shikari): *MAKING
[20:53] (x'Dark_Shikari): gg breaking VBV again


It had to be said, before more bad patches are created.

Revision 956 should solve the speed issues.... it did for me!

TEST BEFORE PUTTING THIS IN YOUR ENCODING TOOLS/GUIS

My results:
x264.956M.hq.mkv (http://x264.nl/x264.956M.hq.mkv)
x264.956M.tv.mkv (http://x264.nl/x264.956M.tv.mkv)
If you told me this was x264 + this bitrate a year ago, i would have laughed at you :D

[kemuri-_9]

ah ha, there's that code from r951 that sharktooth's patch removed.

so it was necessary after all... i turned out to be right and had no idea i was...

[Ranguvar]

http://sites.google.com/site/ranguvar13/x264-builds

Direct download (http://sites.google.com/site/ranguvar13/x264-builds/rang_x264_r0956.7z?attredirects=0), Mirrors (http://www.rapidspread.com/file.jsp?id=l6ou1hqkae)

x264 r956 (fixes speed issues) from Git (patched).
Compiled by Ranguvar on September 1st, 2008, with GCC 4.3.2 on Windows XP Professional x64 SP2.

Open this archive with the free, multi-platform tools 7-Zip or p7zip. Compressed with LZMA.
The src folder contains the patched source code.
The bin folder contains a binary executable for Athlon and later AMD CPUs, and one for those without.
There are also DLLs for those apps that use them (NOT for AviDemux - get those from LoRd_MuldeR).

Git: git://git.videolan.org/x264.git
Info, and source tarballs: http://www.videolan.org/developers/x264.html
Changelog: http://git.videolan.org/gitweb.cgi?p=x264.git
Vanilla builds: http://x264.nl/
Discussion: http://forum.doom9.org/forumdisplay.php?f=77
http://forum.doom9.org/showthread.php?t=130364


Applied patches (included, unchanged, in the patches folder):

patch -p1 < ../x264diffs/x264_dll_alignment_fix.01.diff
patch < ../x264diffs/x264.progress.indication.01.diff
patch -p1 < ../x264diffs/x264_hrd_pulldown.09_interlace.diff
patch -p1 < ../x264diffs/x264_psy_rdo_0.6_r953.diff
patch -p1 < ../x264diffs/x264_new_bframe_decision_04.7.diff


CLI used for non-AMD build: ./configure --enable-shared --extra-cflags="-march=pentium2 -pipe"
make fprofiled VIDS="../enctests/deadline_cif.y4m"
CLI used for AMD build: ./configure --enable-shared --extra-cflags="-march=athlon -pipe"
make fprofiled VIDS="../enctests/deadline_cif.y4m"

Platform: X86
System: MINGW
asm: yes
avis input: yes
mp4 output: yes
pthread: yes
gtk: no
debug: no
gprof: no
PIC: no
shared: yes
visualize: no

[Avenger007]

It's really slow when allowing a high number of consecutive b-frames.
Does that really fall under "highly experimental"? I thought highly experimental meant it was alpha and had lots of potential bugs.
Efficiency isn't a bug -- it's a direct consequence of the algorithm chosen.

[Soichiro]

I still have reason to believe that there are bugs in it, but the devs seem to believe that I'm loony.

After all, having 99% of b-frames in an ep in 16 frame sequences is completely normal.

Not that that happens every time, of course, but there have been reports, and even one occurrence of a bug is too many.

[LoRd_MuldeR]

Does that really fall under "highly experimental"? I thought highly experimental meant it was alpha and had lots of potential bugs.
Efficiency isn't a bug -- it's a direct consequence of the algorithm chosen.

Well, unless the speed-loss is worth the quality-gain, extreme slowness can be considered a bug. Also the slowness of the algorithm chosen is caused by certain limitations in x264 - the frame-decision is not multi-threaded yet. In case they "fix" that problem, the new algo should become much faster. Last but not least, DS said he's working on some heuristics to speed-up the algo. So at the moment this patch simply isn't something everybody should use blindly and it's not in a final state yet. Thus it's called "(highly) experimental" ...

[Avenger007]

Well, unless the speed-loss is worth the quality-gain, extreme slowness can be considered a bug. Also the slowness of the algorithm chosen is caused by certain limitations in x264 - the frame-decision is not multi-threaded yet. In case they "fix" that problem, the new algo should become much faster. Last but not least, DS said he's working on some heuristics to speed-up the algo. So at the moment this patch simply isn't something everybody should use blindly and it's not in a final state yet. Thus it's called "(highly) experimental" ...
Thus it should be called "inefficient" not "(highly) experimental".
Essentially you're saying the algorithm is a "bug" even though it works functionally as far as I can tell.

[LoRd_MuldeR]

Thus it should be called "inefficient" not "(highly) experimental".
Essentially you're saying the algorithm is a "bug" even though it works functionally as far as I can tell.

I don't say it is a bug. I just say it's currently less efficient than it could be and it's not in a state were everybody should start using it blindly.
And I said that a patch (not this one) could be called "buggy", if it causes an extreme slowdown for a minimal quality-gain.

After all it doesn't matter whether the b-frame patch is labeled "(highly) experimental", "inefficient" or something else.
If you want to use it, then you can feel free to use it. And if you are afraid to test "experimental" stuff, then keep away from it...

[Avenger007]

If you want to use it, then you can feel free to use it. And if you are afraid to test "experimental" stuff, then keep away from it...
That's what I want to know... what is there to be afraid of?
Is efficiency the only/main reason why the patch hasn't been committed as yet?

[kemuri-_9]

That's what I want to know... what is there to be afraid of?
Is efficiency the only/main reason why the patch hasn't been committed as yet?

yes, it works perfectly fine outside of the fact it grows incredibly slower with more b-frames

[Ranguvar]

I believe so, I think aku/DS were saying they could optimize it a little more, so it's probably not being committed until then.

[Sharktooth]

ah ha, there's that code from r951 that sharktooth's patch removed.

so it was necessary after all... i turned out to be right and had no idea i was...
uh? what code i removed?
i just manually did what patch command didnt... i looked at the rejected changes and done them manually by removing the lines with a minus sign in front of them... so i definatly didnt remove any code that the previous patch (0.4.5) didnt already remove...

[kemuri-_9]

the code that the pre r951 patch removed was different than the code that there was for r951. the code looked similar but was actually different:
pre r951 patch - '4.5'
- for( y=0; y<16; y++ )
- for( x=0; x<16; x++ )
- frame->i_cost_est[y][x] = -1;


r951 patch - your '4.6'
- for( x = 0; x < h->param.i_bframe + 2; x++ )
- for( y = 0; y < h->param.i_bframe + 2; y++ )
- frame->i_row_satds[y][x][0] = -1;


In the end, DS came and settled the situation, so it's all fine now.

[Sharktooth]

oh... then something went wrong during the creation of the .rej file... or im just blind (that could be possible as well since my left eye is recently almost really blind...).

edit: i confirm the .rej file is wrong, so my "patch" bin is definatly screwed...

[Quark.Fusion]

options: --qp 0 --ref 2 --subme 3 --no-cabac --mixed-refs --progress --threads 6 --thread-input
avis [info]: 320x240 @ 23.98 fps (2280 frames)

——————————

x264 - core 61 r955kVAQmod.PsyRDO d4265bb
x264 [info]: kb/s:4033.9

BROKEN FILE

——————————

x264 - core 61 r956 7b71d58
x264 [info]: kb/s:5985.2

PLAYABLE

——————————

x264 - core 61 r956kVAQmod.PsyRDO 7b71d58
x264 [info]: kb/s:4033.9

BROKEN FILE

——————————

options: --aq-mode 0 --qp 0 --ref 2 --subme 3 --no-cabac --mixed-refs --progress --threads 6 --thread-input
x264 - core 61 r956kVAQmod.PsyRDO 7b71d58
x264 [info]: slice I:16 Avg QP: 0.00 size: 25373
x264 [info]: kb/s:4033.9

BROKEN FILE

——————————

options: --qp 0 --ref 2 --subme 3 --no-cabac --mixed-refs --progress --threads 1 --thread-input
x264 - core 61 r956kVAQmod.PsyRDO 7b71d58
x264 [info]: slice I:11 Avg QP: 0.00 size: 31243
x264 [info]: kb/s:4033.5

BROKEN FILE

——————————

Whats wrong?


P.S. I currently encoding 1920x832 (196071 frames) with broken build and different options — it is playable, but is it lossless?

[Quark.Fusion]

Now encoded with "--partitions i8x8,b8x8,p8x8,i4x4 --ref 4 --subme 4 --me hex --8x8dct --bframes 16 --bime --b-pyramid --b-adapt 1 --b-rdo --deadzone-inter 0 --deadzone-intra 0 --colormatrix bt709 --colorprim bt709 --qp 0 --direct auto --no-deblock --fullrange on --mixed-refs --no-dct-decimate --no-fast-pskip --no-psnr --no-ssim --progress --threads 6 --thread-input --trellis 0 --weightb ":
x264 [info]: slice I:16 Avg QP: 0.00 size: 31473
x264 [info]: slice P:1626 Avg QP: 0.00 size: 29513
x264 [info]: slice B:638 Avg QP: 0.00 size: 22953
x264 [info]: kb/s:5311.3

Seems that my big encode must be correct one.


Edit: seems that it is bug with "--no-cabac".

[komisar]

Yes, --no-cabac broken. I find "broker"... Not work from 928 revision...

Quark.Fusion
--qp 0 is lossless...

[komisar]

--no-cabac Broken after make fprofiled
Need confirm another "patchers-builders"...

[Dark Shikari]

Yes, --no-cabac broken. I find "broker"... Not work from 928 revision...Worksforme. "Its broken" is a completely useless bug report, by the way; unless its very obvious what you think is broken, I have no idea what you're talking about.

[komisar]

Sorry. I talked about my build. The problem arises when I use make fprofiled with gcc version 4.4.0 20080822 (experimental) (GCC). Standard build raises the same error. I try update my gcc from svn...

[Dark Shikari]

Sorry. I talked about my build. The problem arises when I use make fprofiled with gcc version 4.4.0 20080822 (experimental) (GCC). Standard build raises the same error. I try update my gcc from svn...Ah. Have you pinpointed exactly where gcc is miscompiling the code? It'd be useful to know just as a warning for where to potentially look in the future, as the absolute most nightmarish of bugs are the ones caused by miscompilation.

[komisar]

I found only one problem before with profiling VFW-version of x264. After profiling in "common/common.c" in function "x264_log"h->param.pf_log( h->param.p_log_private, i_level, psz_fmt, arg );changed tox264_log_default( h->param.p_log_private, i_level, psz_fmt, arg );for correct profiling i use ugly hack: http://komisar.gin.by/x.patch/last.used/k.vfw.01.dummy-log.diff

P.S. This misunderstanding has helped find BugMaster.

[kemuri-_9]

no wonder, i tried compiling some stuff with gcc 4.4.0 and kept getting seg faults from the cpu id asm method when trying to run it.
definitely shouldn't use it right now, imo.

quarkfusion: I haven't been able to reproduce such lack of playback on any of those settings, granted i don't really have any video files of that resolution for that length.

[komisar]

This is a bug from gcc. I reproduce this bug on any source and settings... :-( I would dig deeper...

[Sharktooth]

then use a stable GCC version...

[komisar]

This is a matter of principle. I want to find the cause of the error. No matter where, gcc or x264...

[kemuri-_9]

with the huge list of regressions 4.4.0 has right now, i doubt you'll find it.

[Sharktooth]

komisar, then you need to start a new thread and discuss gcc 4.4 problems there since it's not a x264 problem...
also, your statement made ppl think it was a x264 problem while it was a gcc one... that means confusion...
you should provide those info to the GCC devs not the x264 devs.

[komisar]

komiisar, then you need to start a new thread and discuss gcc 4.4 problems there since it's not a x264 problem...
also, your statement made ppl think it was a x264 problem while it was a gcc one... that means confusion...
you should provide those info to the GCC devs not the x264 devs.
Why do you think that this problem can not be discussed here? Initially, the problem concerned the my x264 build. It is now clear that this is a compiler problem. Where described recommendations for the use of tools?
I believe that the correct spelling of code for different versions of compilers are also important.
Ah. Have you pinpointed exactly where gcc is miscompiling the code? It'd be useful to know just as a warning for where to potentially look in the future, as the absolute most nightmarish of bugs are the ones caused by miscompilation.

[Sharktooth]

coz gcc 4.4 is still not released... it's beta or whatever you wanna call it so it's not a matter of "code spelling" but just a plain compiler bug and that has nothing in common with x264.

[kemuri-_9]

altered to to include kb/s like in r957 and fix rejections:
apply via
patch -p 1 -i x264_progress.indication_r957.diff
x264_progress.indication_r957.diff (http://kemuri9.net/dev/x264/patches/x264_progress.indication_r957.diff)

[skystrife]

x264.957.modified.exe (http://www.mediafire.com/?b8ts0udkajm) - Alternate Download (http://skystrife.com/x264/x264.957.modified.exe)

Patches used:

x264_psy_rdo_0.6_r956.diff (http://skystrife.com/x264/x264_psy_rdo_0.6_r956.diff) <-- One line change from r953's patch to get rid of that oh-so-scary fuzz warning.
x264_new_bframe_decision_04.7.diff <-- Enable with --b-adapt 2. Random code removal fixed in this patch.
x264_hrd_pulldown.09_interlace.diff
x264_progress.indication_r957.diff <-- Thanks, kemuri.

gcc 3.4.5 fprofiled build.

[Ranguvar]

Thanks to kemuri for the fixed progress indication patch!

Home (http://sites.google.com/site/ranguvar13/x264-builds)

Direct download (http://sites.google.com/site/ranguvar13/x264-builds/rang_x264_r0957.7z?attredirects=0), Mirrors (http://www.rapidspread.com/file.jsp?id=by84bgrjpc)

x264 r957 from Git (patched).
Compiled by Ranguvar on September 3rd, 2008, with GCC 4.3.2 on Windows XP Professional x64 SP2.
I have removed the non-AMD build, because the AMD build is of equal speed or faster than the non-AMD one
in all of my tests so far - even on non-AMD hardware. Why? Who knows. But you don't need to worry about it.

Open this archive with the free, multi-platform tools 7-Zip or p7zip. Compressed with LZMA.
The src folder contains the patched source code.
The bin folder contains a binary executable, and a DLL for those apps that use them
(NOT for AviDemux - get those from LoRd_MuldeR).

Git: git://git.videolan.org/x264.git
Info, and source tarballs: http://www.videolan.org/developers/x264.html
Changelog: http://git.videolan.org/gitweb.cgi?p=x264.git
Vanilla builds: http://x264.nl/
Discussion: http://forum.doom9.org/forumdisplay.php?f=77
http://forum.doom9.org/showthread.php?t=130364


Applied patches (included, unchanged, in the patches folder):

patch -p1 < ../x264diffs/x264_dll_alignment_fix.01.diff
patch < ../x264diffs/x264_progress.indication_r957.diff
patch -p1 < ../x264diffs/x264_hrd_pulldown.09_interlace.diff
patch -p1 < ../x264diffs/x264_psy_rdo_0.6_r953.diff
patch -p1 < ../x264diffs/x264_new_bframe_decision_04.7.diff


CLI used for build: ./configure --enable-shared --extra-cflags="-march=athlon -pipe"
make fprofiled VIDS="../enctests/deadline_cif.y4m"

Platform: X86
System: MINGW
asm: yes
avis input: yes
mp4 output: yes
pthread: yes
gtk: no
debug: no
gprof: no
PIC: no
shared: yes
visualize: no

[techouse]

x264_x86_r957_techouse (http://techouse.project357.com/builds/x264_x86_r957_techouse.7z)
Source: x264 r957 GIT (git://git.videolan.org/x264.git)

Applied patches (current versions):

x264_progress.indication_r957.diff

x264_psy_rdo.0.6_r957.diff

x264_hrd_pulldown.09_interlace.diff

x264_new_bframe_decision_04.7.diff


Please check http://forum.doom9.org/showthread.php?t=130364 and http://git.videolan.org/gitweb.cgi?p=x264.git;a=shortlog for more info

Compiled by techouse on September 3rd 2008, 09:39:49 CEST with GCC-4.3.2 on Windows Vista Business SP-1 64-bit.

Commandline used: ./configure --extra-cflags="-march=core2 -pipe" && make fprofiled

Platform: X86
System: MINGW
asm: yes
avis input: yes
mp4 output: yes
pthread: yes
gtk: no
debug: no
gprof: no
PIC: no
shared: no
visualize: no

P.S.: Love ya, kemuri ;)

[burfadel]

Why do you think that this problem can not be discussed here? Initially, the problem concerned the my x264 build. It is now clear that this is a compiler problem. Where described recommendations for the use of tools?
I believe that the correct spelling of code for different versions of compilers are also important.

Any luck with the 02 Sep release? Its good to test it at least, the 4.4.0 does make fast builds (encoding performance is fractionally better than any other GCC) :)

[komisar]

Any luck with the 02 Sep release? Its good to test it at least, the 4.4.0 does make fast builds (encoding performance is fractionally better than any other GCC) :)
I know... :) But on my system "02 Sep" svn release building with error. And I switch to gcc 4.3.2... When I make worked build of gcc 4.4 -- I continue my finding.

[TL0]

I am just wondering if the x264_fix_extended_zones.diff by VFR maniac is still needed or is the problem with using zone option he mentioned fixed?

diff --git a/common/common.h b/common/common.h
index ca555d1..4b18486 100644
--- a/common/common.h
+++ b/common/common.h
@@ -584,6 +584,12 @@ struct x264_t

} stat;

+ struct
+ {
+ int b_interlaced_esa;
+ int b_interlaced_temporal;
+ } warn;
+
/* CPU functions dependents */
x264_predict_t predict_16x16[4+3];
x264_predict_t predict_8x8c[4+3];
diff --git a/encoder/encoder.c b/encoder/encoder.c
index ad7151c..42c16fb 100644
--- a/encoder/encoder.c
+++ b/encoder/encoder.c
@@ -328,7 +328,7 @@ static void x264_bitstream_check_buffer( x264_t *h )
*
****************************************************************************/

-static int x264_validate_parameters( x264_t *h )
+static int x264_validate_parameters( x264_t *h, int b_zone )
{
#ifdef HAVE_MMX
if( !(x264_cpu_detect() & X264_CPU_MMXEXT) )
@@ -363,7 +363,8 @@ static int x264_validate_parameters( x264_t *h )
if( h->param.i_threads > 1 )
{
#ifndef HAVE_PTHREAD
- x264_log( h, X264_LOG_WARNING, "not compiled with pthread support!\n");
+ if ( !b_zone )
+ x264_log( h, X264_LOG_WARNING, "not compiled with pthread support!\n");
h->param.i_threads = 1;
#else
if( h->param.i_scenecut_threshold >= 0 )
@@ -375,12 +376,20 @@ static int x264_validate_parameters( x264_t *h )
{
if( h->param.analyse.i_me_method >= X264_ME_ESA )
{
- x264_log( h, X264_LOG_WARNING, "interlace + me=esa is not implemented\n" );
+ if ( !h->warn.b_interlaced_esa )
+ {
+ x264_log( h, X264_LOG_WARNING, "interlace + me=esa is not implemented\n" );
+ h->warn.b_interlaced_esa = 1;
+ }
h->param.analyse.i_me_method = X264_ME_UMH;
}
if( h->param.analyse.i_direct_mv_pred > X264_DIRECT_PRED_SPATIAL )
{
- x264_log( h, X264_LOG_WARNING, "interlace + direct=temporal is not implemented\n" );
+ if ( !h->warn.b_interlaced_temporal )
+ {
+ x264_log( h, X264_LOG_WARNING, "interlace + direct=temporal is not implemented\n" );
+ h->warn.b_interlaced_temporal = 1;
+ }
h->param.analyse.i_direct_mv_pred = X264_DIRECT_PRED_SPATIAL;
}
}
@@ -424,7 +433,7 @@ static int x264_validate_parameters( x264_t *h )
h->param.rc.i_qp_min = x264_clip3( h->param.rc.i_qp_min, 0, h->param.rc.i_qp_max );

if( ( h->param.i_width % 16 || h->param.i_height % 16 )
- && h->param.i_height != 1080 && !h->mb.b_lossless )
+ && h->param.i_height != 1080 && !h->mb.b_lossless && !b_zone )
{
// There's nothing special about 1080 in that the warning still applies to it,
// but chances are the user can't help it if his content is already 1080p,
@@ -491,7 +500,7 @@ static int x264_validate_parameters( x264_t *h )
if( h->param.rc.f_aq_strength <= 0 )
h->param.rc.i_aq_mode = 0;
/* VAQ effectively replaces qcomp, so qcomp is raised towards 1 to compensate. */
- if( h->param.rc.i_aq_mode == X264_AQ_GLOBAL )
+ if( h->param.rc.i_aq_mode == X264_AQ_GLOBAL && !b_zone )
h->param.rc.f_qcompress = x264_clip3f(h->param.rc.f_qcompress + h->param.rc.f_aq_strength / 0.7, 0, 1);
h->param.analyse.i_noise_reduction = x264_clip3( h->param.analyse.i_noise_reduction, 0, 1<<16 );

@@ -604,7 +613,7 @@ x264_t *x264_encoder_open ( x264_param_t *param )
/* Create a copy of param */
memcpy( &h->param, param, sizeof( x264_param_t ) );

- if( x264_validate_parameters( h ) < 0 )
+ if( x264_validate_parameters( h, 0 ) < 0 )
{
x264_free( h );
return NULL;
@@ -798,6 +807,10 @@ int x264_encoder_reconfig( x264_t *h, x264_param_t *param )
COPY( analyse.b_dct_decimate );
COPY( analyse.b_fast_pskip );
COPY( analyse.b_mixed_references );
+ // COPY( rc.f_ip_factor );
+ // COPY( rc.f_pb_factor );
+ COPY( rc.i_aq_mode );
+ COPY( rc.f_aq_strength );
// can only twiddle these if they were enabled to begin with:
if( h->pps->b_transform_8x8_mode )
COPY( analyse.b_transform_8x8 );
@@ -807,7 +820,7 @@ int x264_encoder_reconfig( x264_t *h, x264_param_t *param )

mbcmp_init( h );

- return x264_validate_parameters( h );
+ return x264_validate_parameters( h, 1 );
}

/* internal usage */
diff --git a/encoder/ratecontrol.c b/encoder/ratecontrol.c
index 1d41200..c0a61fb 100644
--- a/encoder/ratecontrol.c
+++ b/encoder/ratecontrol.c
@@ -569,7 +569,8 @@ int x264_ratecontrol_new( x264_t *h )
static int parse_zone( x264_t *h, x264_zone_t *z, char *p )
{
int len = 0;
- char *tok, *saveptr;
+ int i, j = 0;
+ char *tok, *buff;
z->param = NULL;
z->f_bitrate_factor = 1;
if( 3 <= sscanf(p, "%u,%u,q=%u%n", &z->i_start, &z->i_end, &z->i_qp, &len) )
@@ -586,11 +587,32 @@ static int parse_zone( x264_t *h, x264_zone_t *z, char *p )
p += len;
if( !*p )
return 0;
+
+ /* Parse some options. */
+ if( p[0] != ',' )
+ return -1;
+ else
+ buff = ++p;
z->param = malloc( sizeof(x264_param_t) );
memcpy( z->param, &h->param, sizeof(x264_param_t) );
- while( (tok = strtok_r( p, ",", &saveptr )) )
+ while( *buff )
{
- char *val = strchr( tok, '=' );
+ char *val;
+ tok = x264_malloc( strlen(buff)+1 );
+ memset( tok, 0, sizeof(tok) );
+ for( i = 0; p[j] != ',' && *buff; i++ )
+ {
+ tok[i] = p[j++];
+ buff++;
+ }
+ if ( !*tok )
+ {
+ x264_free( tok );
+ return -1;
+ }
+ tok[i] = '\0';
+ j++;
+ val = strchr( tok, '=' );
if( val )
{
*val = '\0';
@@ -599,9 +621,10 @@ static int parse_zone( x264_t *h, x264_zone_t *z, char *p )
if( x264_param_parse( z->param, tok, val ) )
{
x264_log( h, X264_LOG_ERROR, "invalid zone param: %s = %s\n", tok, val );
+ x264_free( tok );
return -1;
}
- p = NULL;
+ x264_free( tok );
}
return 0;
}


http://www.esnips.com/web/VFRmaniac-Softwares

[komisar]

Problem with --no-cabac in profiling gcc 4.4.0 solved (Thnx BugMaster). GCC 4.4.0 wrong inline function bs_write_vlc in cavlc.c. I change this with define:#define bs_write_vlc(a,b) bs_write(a, b.i_size, b.i_bits)
/*static inline void bs_write_vlc( bs_t *s, vlc_t v )
{
bs_write( s, v.i_size, v.i_bits );
}*/and all OK now.
Comparing gcc profiling:x264.gcc433.pf.exe --crf 26 --no-cabac --trellis 2 --ref 4 --bframes 3 --subme 6 --me umh --threads 1 --thread-input
encoded 20 frames, 6.96 fps, 4719.71 kb/s

x264.gcc440.pf.exe --crf 26 --no-cabac --trellis 2 --ref 4 --bframes 3 --subme 6 --me umh --threads 1 --thread-input
encoded 20 frames, 10.49 fps, 4719.71 kb/s

[DarkZell666]

and all OK now.
Comparing gcc profiling:x264.gcc433.pf.exe --crf 26 --no-cabac --trellis 2 --ref 4 --bframes 3 --subme 6 --me umh --threads 1 --thread-input
encoded 20 frames, 6.96 fps, 4719.71 kb/s

x264.gcc440.pf.exe --crf 26 --no-cabac --trellis 2 --ref 4 --bframes 3 --subme 6 --me umh --threads 1 --thread-input
encoded 20 frames, 10.49 fps, 4719.71 kb/s

... you mean the improvement is that big ? 50% faster ? o_O

[Ranguvar]

Those stats aren't very useful, no offense komisar. 20 frames only? No comparison to non-fprofiled stable?

[komisar]

Ranguvar
Indeed, not quite correctly. I make new tests...

[komisar]

Speed test gcc 346 vs gcc433 vs gcc440...

Source: avis [info]: 640x480 @ 60.00 fps (600 frames)

I make new tests.... This is not x264 speed test but gcc...

http://komisar.gin.by/test/gcc_speed_test.png

we all know gcc 4.3 produces slower x264 binaries than 3.4...
I do not know, but now I know more...

[Sharktooth]

compare to gcc 3.4... we all know gcc 4.3 produces slower x264 binaries than 3.4...

[komisar]

I have no gcc 3.4... But ok, I grab 3.4...
You may grab x264 binary from here: http://komisar.gin.by/test/

[gigah72]

here're some builds to play with, regardin speed, etc.
http://www.mediafire.com/?wgcgdjd9gem


patches
--------
x264_hrd_pulldown.09_interlace.diff
x264_new_bframe_decision_04.7.diff
x264_progress.indication_r957.diff
x264_psy_rdo_0.6_r956.diff
-----
builds
-------
x264_957_g345_c1_athlon.exe
x264_957_g345_c1_axp.exe
x264_957_g345_c1_k8.exe
x264_957_g345_c1_p2.exe
x264_957_g345_c2_athlon.exe
x264_957_g345_c2_axp.exe
x264_957_g345_c2_k8.exe
x264_957_g345_c2_p2.exe
x264_957_g345_x2_athlon.exe
x264_957_g345_x2_axp.exe
x264_957_g345_x2_k8.exe
x264_957_g345_x2_p2.exe
x264_957_g432_c1_athlon.exe
x264_957_g432_c1_axp.exe
x264_957_g432_c1_k8.exe
x264_957_g432_c1_p2.exe
x264_957_g432_x2_athlon.exe
x264_957_g432_x2_axp.exe
x264_957_g432_x2_k8.exe
-------
c1=CoreDuo 2300
c1=Core2Duo 4300
x2= AMD Athlon64 X2 5200+
all are build in same msys w2k/vmware on the above pc's

[Sharktooth]

... again with CPU optimizations ... x264 do not require them. the heavy stuff is coded in asm and already optimized...

[gigah72]

don't want it, don't try it. it's only for who's interested.

[Sharktooth]

just stop it and search before posting (follow the forum rules!). this has been already done... several times. so stop posting for just increasing your post count (again, follow the forum rules) and stop your aggressive behaviour (again, follow the forum rules) or you will get apples for apples...
so it appears you violated 3 forum rules in 15 minutes...

[Ranguvar]

I agree with gigah... don't want it, don't try it.

Seeing as how -march=athlon is noticeably faster than -march=pentium2 on AMD CPUs, for little reason apparently, despite Sharktooth's logic, anything that could potentially lead to another slight gain for a specific CPU is worthwhile. When you encode at brutally insane settings, every % counts.

[Sharktooth]

that's not the point... the point is it's not necessary to test that since it has been already done (last time it was a week ago or so... just look at the previous pages of this thread...). also he didnt post the cflags used, if the builds are fprofiled or not... etc... a well configured and generic build may be faster than or equal in speed to his cpu optimized builds...
however there are already conclusions about CPU optimizations with x264 (just look some pages back). if every user comes here posting 19 (!!! FYI building on different HW doesnt produce different binaries...) different builds will only add confusion for the ppl looking for the correct information and will spawn idiots that do not use the search function, that will test those builds adding tons of posts (most of the time they dont even know how to correctly benchmark too...) creating even more confusion...
i wish to remember you this thread is about patches... not discussion about or test of compiler optimizations.

[Audionut]

just stop it and search before posting (follow the forum rules!). this has been already done... several times. so stop posting for just increasing your post count (again, follow the forum rules) and stop your aggressive behaviour (again, follow the forum rules) or you will get apples for apples...
so it appears you violated 3 forum rules in 15 minutes...


Really!! It's only you who is aggressive. Your opinion, whether true or not, is not the be all and end all. As soon as someone posts something, that you do not agree with, it is you who flies of the rail.

[Sharktooth]

read my previous post (reply to ranguvar)... i was not referring to my opinion but to the conclusions that were drawn some pages back in this same thread.

[Audionut]

Just ignore it. He simply posted some different builds to play with. He didn't claim they were best or any other claims. Just a simple post.

BTW, People looking for correct information should read the stickies.

Perhaps your sticky could be edited, to make it more clear, to those of us that don't browse these forums every day, and know better, that those builds, are considered stable.
Any other builds are considered beta.

Honestly, while you and I and most others here will know better, it will help stop,
different builds will only add confusion for the ppl looking for the correct information and will find idiots that dont use the search function that will test those builds adding tons of posts

It just seems to me, that your pushing shit up hill. There are idiots everywhere. Always have been, always will be.

[Sharktooth]

i already state (in the sticky) the the vanilla git builds are the more stable than the patched builds (coz they include experimental patches...)

[Ranguvar]

Home (http://sites.google.com/site/ranguvar13/x264-builds)

Direct download (http://sites.google.com/site/ranguvar13/x264-builds/rang_x264_r0964.7z?attredirects=0), Mirrors (http://www.rapidspread.com/file.jsp?id=i0w0fgetps)

x264 r964 from Git (patched, fprofiled).
Compiled by Ranguvar on September 5rd, 2008, with GCC 4.3.2.
I have removed the non-AMD build, because the AMD build is of equal speed or faster than the non-AMD one
in all of my tests so far - even on non-AMD hardware. Why? Who knows. But you don't need to worry about it.

Open this archive with the free, multi-platform tools 7-Zip or p7zip. Compressed with LZMA.
The src folder contains the patched source code.
The bin folder contains a binary executable, and a DLL for those apps that use them
(NOT for AviDemux - get those from LoRd_MuldeR).

Git: git://git.videolan.org/x264.git
Info, and source tarballs: http://www.videolan.org/developers/x264.html
Changelog: http://git.videolan.org/gitweb.cgi?p=x264.git
Vanilla builds: http://x264.nl/
Discussion: http://forum.doom9.org/forumdisplay.php?f=77
http://forum.doom9.org/showthread.php?t=130364


Applied patches (included, unchanged, in the patches folder):

patch -p1 -i ../x264diffs/x264_dll_alignment_fix.01.diff
patch -p1 -i ../x264diffs/x264_progress.indication_r957.diff
patch -p1 -i ../x264diffs/x264_hrd_pulldown.09_interlace.diff
patch -p1 -i ../x264diffs/x264_psy_rdo_0.6_r956.diff
patch -p1 -i ../x264diffs/x264_new_bframe_decision_04.7.diff


CLI used for build: ./configure --enable-shared --extra-cflags="-march=athlon -pipe"
make fprofiled VIDS="../enctests/deadline_cif.y4m"

Platform: X86
System: MINGW
asm: yes
avis input: yes
mp4 output: yes
pthread: yes
gtk: no
debug: no
gprof: no
PIC: no
shared: yes
visualize: no

[skystrife]

x264.964.modified.exe (http://www.mediafire.com/?zba88amzpsn) - Alternate Download (http://skystrife.com/x264/x264.964.modified.exe)

Patches used:

x264_psy_rdo_0.6_r956.diff
x264_new_bframe_decision_04.7.diff
x264_hrd_pulldown.09_interlace.diff
x264_progress.indication_r957.diff

gcc 3.4.5 fprofiled build with -march=pentium2.

(my previous builds have all included -march=pentium2 as well but apparently it's "in" to have builds with different -march's so I'll specify this. Also, lol @ the gcc 4 and gcc 3 builds posts being so close together.)

[gav1577]

x264.964.modified.exe (http://www.mediafire.com/?zba88amzpsn) - Alternate Download (http://skystrife.com/x264/x264.964.modified.exe)

Patches used:

x264_psy_rdo_0.6_r956.diff
x264_new_bframe_decision_04.7.diff
x264_hrd_pulldown.09_interlace.diff
x264_progress.indication_r957.diff

gcc 3.4.5 fprofiled build with -march=pentium2.

(my previous builds have all included -march=pentium2 as well but apparently it's "in" to have builds with different -march's so I'll specify this. Also, lol @ the gcc 4 and gcc 3 builds posts being so close together.)

Im having serious visual problems with this build can some one confirm /reproduce ?

--pass 1 --bitrate 4500 --stats "C:\Documents and Settings\me\Desktop\123.stats" --level 4.1 --keyint 24 --min-keyint 2 --bframes 3 --direct auto --subme 1 --partitions none --ipratio 1.1 --pbratio 1.1 --vbv-bufsize 16500 --vbv-maxrate 16500 --qcomp 0.5 --me dia --threads auto --thread-input --sar 1:1 --progress --no-psnr --no-ssim --output NUL "C:\Documents and Settings\me\Desktop\123.avs" --mvrange 511 --aud --nal-hrd --sar 1:1

--pass 2 --bitrate 4500 --stats "C:\Documents and Settings\me\Desktop\123.stats" --level 4.1 --keyint 24 --min-keyint 2 --ref 3 --mixed-refs --bframes 3 --b-rdo --bime --weightb --direct auto --subme 6 --trellis 1 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --ipratio 1.1 --pbratio 1.1 --vbv-bufsize 16500 --vbv-maxrate 16500 --qcomp 0.5 --me umh --threads auto --thread-input --sar 1:1 --progress --no-psnr --no-ssim --output "C:\Documents and Settings\me\Desktop\123.mp4" "C:\Documents and Settings\me\Desktop\123.avs" --mvrange 511 --aud --nal-hrd --sar 1:1

megui profile HD AVCHD Source sample logs avs provided below Thanks
http://www.mediafire.com/?sharekey=36267983da746bb4d2db6fb9a8902bda

screen shot of output

http://img33.picoodle.com/data/img33/3/9/5/f_x264964Patcm_3697313.png (http://www.picoodle.com/view.php?img=/3/9/5/f_x264964Patcm_3697313.png&srv=img33)

[skystrife]

I just did a quick test (same settings, different source) and the output was fine. Downloading your source and avs now.

EDIT: With your source something definitely borked. I don't know what.

EDIT2: Both r964 builds are affected.

[gav1577]

I just did a quick test (same settings, different source) and the output was fine. Downloading your source and avs now.

Ok thanks BTW previous versions work fine with the source sample :)

[gav1577]

I just did a quick test (same settings, different source) and the output was fine. Downloading your source and avs now.

EDIT: With your source something definitely borked. I don't know what.

If thats the case how come previous builds work fine ? source is cut from original blu ray. Do you have the same problem with older builds?

[kemuri-_9]

DirectShowSource() <--- is the devil, don't use it.
use neuron2's DGAVCIndex

[skystrife]

DirectShowSource() <--- is the devil, don't use it.
use neuron2's DGAVCIndex

Well even then, if the avs is playing fine when I preview it in MPC it shouldn't be doing anything like this when I encode it, right?

(Also, in case my EDIT2 was missed, both Ranguvar and my builds are affected, so beware for bugs in both.)

[gav1577]

DirectShowSource() <--- is the devil, don't use it.
use neuron2's DGAVCIndex

same outcome from FFmpeg r14675 when muxed to mkv havent tried DGAVCIndex yet


Thanks for confirming skystrife

[skystrife]

Vanilla r964 build has the issue here for me, so this is most likely not related to the patching. What setting exactly is fuxing the output though is beyond me, I'm slowly removing every setting and not getting anywhere.

Any ideas?

[gav1577]

Vanilla r964 build has the issue here for me, so this is most likely not related to the patching. What setting exactly is fuxing the output though is beyond me, I'm slowly removing every setting and not getting anywhere.

Any ideas?

Same here i tried everything i could think of before i posted :confused:

[kemuri-_9]

well i tried working at it and in different players, the frames were definitely miscolored, so maybe one of the new updates had a regression where the chroma gets corrupted.

tried on something else and got similar massive corruption.

when reverting back to my r956 build, there were no problems.

[gigah72]

Im having serious visual problems with this build can some one confirm /reproduce ?

--pass 1 --bitrate 4500 --stats "C:\Documents and Settings\me\Desktop\123.stats" --level 4.1 --keyint 24 --min-keyint 2 --bframes 3 --direct auto --subme 1 --partitions none --ipratio 1.1 --pbratio 1.1 --vbv-bufsize 16500 --vbv-maxrate 16500 --qcomp 0.5 --me dia --threads auto --thread-input --sar 1:1 --progress --no-psnr --no-ssim --output NUL "C:\Documents and Settings\me\Desktop\123.avs" --mvrange 511 --aud --nal-hrd --sar 1:1

--pass 2 --bitrate 4500 --stats "C:\Documents and Settings\me\Desktop\123.stats" --level 4.1 --keyint 24 --min-keyint 2 --ref 3 --mixed-refs --bframes 3 --b-rdo --bime --weightb --direct auto --subme 6 --trellis 1 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --ipratio 1.1 --pbratio 1.1 --vbv-bufsize 16500 --vbv-maxrate 16500 --qcomp 0.5 --me umh --threads auto --thread-input --sar 1:1 --progress --no-psnr --no-ssim --output "C:\Documents and Settings\me\Desktop\123.mp4" "C:\Documents and Settings\me\Desktop\123.avs" --mvrange 511 --aud --nal-hrd --sar 1:1

megui profile HD AVCHD Source sample logs avs provided below Thanks
http://www.mediafire.com/?sharekey=36267983da746bb4d2db6fb9a8902bda

screen shot of output

http://img33.picoodle.com/data/img33/3/9/5/f_x264964Patcm_3697313.png (http://www.picoodle.com/view.php?img=/3/9/5/f_x264964Patcm_3697313.png&srv=img33)




now with 964 i get the same nice green with my mpeg2source sample and crf settings??
957 works fine.

EDIT:
coreavc in mpc decodes the broken scene, powerdvd in mpc just skipps over the broken scene...
maybe this does say something to someone?

EDIT2:
964 broken: http://www.mediafire.com/?i9h3tshdlcs
957 ok: http://www.mediafire.com/?1llhbmrsjdy

[kemuri-_9]

i went through git revisions one by one starting from r958 to find which one caused the problem...

revision 963 caused the problem, meaning from r962 to r963, the problematic code occurs.

[Dark Shikari]

i went through git revisions one by one starting from r958 to find which one caused the problem...

revision 953 caused the problem, meaning from r952 to r953, the problematic code occurs.Huh? That doesn't even make sense... r953? Are you sure you don't mean r963?

Anyways, this seems odd because I ran all of these patches through a huge slew of regression tests, and posted the patches in #x264 IRC, where another few people ran them through all of their own regression tests and confirmed that they worked flawlessly...

[kemuri-_9]

yeah, typo on my part.... (i blame the fact that it is 2am)
cherry picking from 962 to 964 also has no problems.

[Dark Shikari]

Indeed, there was a subtle test case in which it failed (a very rare one which almost never crops up... almost) and thus slipped past our regression tests.

Thanks for the report, fixed in r965.

[Soichiro]

I can confirm that there's an issue in r963. Horrible blocking shows up in the encode, which I've run 3 times now. It's not there in the source, I'm 100% certain, and it's not an avs filter.

Actually, I guess I'm late since it's fixed now. :p

[Ranguvar]

Home (http://sites.google.com/site/ranguvar13/x264-builds)

Direct download (http://sites.google.com/site/ranguvar13/x264-builds/rang_x264_r0965.7z?attredirects=0), Mirrors (http://www.rapidspread.com/file.jsp?id=hwfwpxvna5)

x264 r965 from Git (patched, fprofiled).
Compiled by Ranguvar on September 6th, 2008, with GCC 4.3.2.
DON'T think that because I used march=athlon it restricts the CPUs you can use.
It seems to improve performance (VERY slightly) for all CPUs.

Open this archive with the free, multi-platform tools 7-Zip or p7zip. Compressed with LZMA.
The src folder contains the patched source code.
The bin folder contains a binary executable, and a DLL for those apps that use them
(NOT for AviDemux - get those from LoRd_MuldeR).

Git: git://git.videolan.org/x264.git
Info, and source tarballs: http://www.videolan.org/developers/x264.html
Changelog: http://git.videolan.org/gitweb.cgi?p=x264.git
Vanilla builds: http://x264.nl/
Discussion: http://forum.doom9.org/forumdisplay.php?f=77
http://forum.doom9.org/showthread.php?t=130364


Applied patches (included, unchanged, in the patches folder):

patch -p1 -i ../x264diffs/x264_dll_alignment_fix.01.diff
patch -p1 -i ../x264diffs/x264_progress.indication_r957.diff
patch -p1 -i ../x264diffs/x264_hrd_pulldown.09_interlace.diff
patch -p1 -i ../x264diffs/x264_psy_rdo_0.6_r956.diff
patch -p1 -i ../x264diffs/x264_new_bframe_decision_04.7.diff


CLI used for build: ./configure --enable-shared --extra-cflags="-march=athlon -pipe"
make fprofiled VIDS="../enctests/deadline_cif.y4m"

Platform: X86
System: MINGW
asm: yes
avis input: yes
mp4 output: yes
pthread: yes
gtk: no
debug: no
gprof: no
PIC: no
shared: yes
visualize: no

[Comatose]

I can confirm that there's an issue in r963. Horrible blocking shows up in the encode, which I've run 3 times now. It's not there in the source, I'm 100% certain, and it's not an avs filter.

Actually, I guess I'm late since it's fixed now. :p
Yeah, umm, I've had two encodes go bad now =\ (r964)
Completely different source too, one anime and the other a 3D game D:

I shouldn't have downloaded a new compile D:

[Snowknight26]

Ranguvar, would be nice if you included pthreadGC2.dll in your build.

[Ranguvar]

I do. It's merged into the EXE. You don't need a separate one. If you just want it for something else, Google and download.

[techouse]

Ranguvar:
I guess you got GCC-4.3.2 from TDM's website and have overwritten all your old files with the new ones from TDM's zip/tar.gz packages. The problem is that the gcc-4.3.2-tdm-1-core.tar.gz package includes pthreadGC2.dll and pthreadGCE2.dll in its /bin folder, libpthreadGCE2.a, libpthreadGC2-static.a and libpthread.a in its /lib folder and pthread.h, sched.h and semaphore.h in its /include folder. You probably copied over those files to your MinGW /bin, your MinGW /include and your MinGW /lib folder folder.
I suggest you remove all these files, get the latest pthread cvs (cvs -d :pserver:anoncvs@sources.redhat.com:/cvs/pthreads-win32 checkout pthreads), compile (make clean GC-static) and install it (copy libpthreadGC2.a to your MinGW /lib folder and copy pthread.h, sched.h and semaphore.h to your MinGW /iclude folder). That way you will eliminate the need of x264.exe for an extra pthreadGC2.dll in C:\Windows\System32.
Trust me on this one, I had the same problem.

I also suggest you people update your GPAC libraries. Many have reported errors building it from CVS, however I have found a nasty trick that actually works:
1. download the old stable tarball from here http://downloads.sourceforge.net/gpac/gpac-0.4.4-rc2.tar.gz
2. once it is downloaded, extract it to your MSYS /home/username folder and cd into it (i.e. cd /home/username/gpac)
3. while inside the gpac folder get the latest GPAC CVS using the command cvs -z3 -d:pserver:anonymous@gpac.cvs.sourceforge.net:/cvsroot/gpac co -P gpac
4. run ./configure && make lib
5. copy /home/username/gpac/include/gpac to your MinGW /include folder

P.S.: If this doesn't work for you try it in your /home folder (i.e. /home/gpac).

[chriszxl]

now with 964 i get the same nice green with my mpeg2source sample and crf settings??
957 works fine.

EDIT:
coreavc in mpc decodes the broken scene, powerdvd in mpc just skipps over the broken scene...
maybe this does say something to someone?

EDIT2:
964 broken: http://www.mediafire.com/?i9h3tshdlcs
957 ok: http://www.mediafire.com/?1llhbmrsjdy

ya...me too...serious bug...

[gigah72]

ya...me too...serious bug...

965 (http://www.mediafire.com/?luzdgc2f03w) fixed this

[lucassp]

I'm trying to backup a DVD Video with x264 (the build from MeGUI) on Vista x64 but it crashes at the beginning. The avs script is playable in Media Player. Does x264 work with Vista x64?

[techouse]

x264_x86_r965_techouse (http://techouse.project357.com/builds/x264_x86_r965_techouse.7z)
Source: x264 r965 GIT (git://git.videolan.org/x264.git)

Applied patches (current versions):

x264_progress.indication_r957.diff

x264_psy_rdo.0.6_r957.diff

x264_hrd_pulldown.09_interlace.diff

x264_new_bframe_decision_04.7.diff


Please check http://forum.doom9.org/showthread.php?t=130364 and http://git.videolan.org/gitweb.cgi?p=x264.git;a=shortlog for more info

Compiled by techouse on September 6th 2008, 10:50:33 CEST with GCC-4.3.2 on Windows Vista Business SP-1 64-bit.

Commandline used: ./configure --extra-cflags="-march=core2 -pipe" && make fprofiled

Platform: X86
System: MINGW
asm: yes
avis input: yes
mp4 output: yes
pthread: yes
gtk: no
debug: no
gprof: no
PIC: no
shared: no
visualize: no

[gav1577]

Indeed, there was a subtle test case in which it failed (a very rare one which almost never crops up... almost) and thus slipped past our regression tests.

Thanks for the report, fixed in r965.

Works perfect now thanks

[saint-francis]

I'm trying to backup a DVD Video with x264 (the build from MeGUI) on Vista x64 but it crashes at the beginning. The avs script is playable in Media Player. Does x264 work with Vista x64?

There is a new version on the update server which works.

[Sharktooth]

sure... i just updated it. damn, i did 3 test encodes with r964 and everything was ok... i was pretty sure that build was working fine...
well, 965 is up... so there should be no more problems.

[lucassp]

There is a new version on the update server which works.

Still no go :(

[Sharktooth]

? did yo update to r965 ?

[Ranguvar]

Ranguvar:
I guess you got GCC-4.3.2 from TDM's website and have overwritten all your old files with the new ones from TDM's zip/tar.gz packages. The problem is that the gcc-4.3.2-tdm-1-core.tar.gz package includes pthreadGC2.dll and pthreadGCE2.dll in its /bin folder, libpthreadGCE2.a, libpthreadGC2-static.a and libpthread.a in its /lib folder and pthread.h, sched.h and semaphore.h in its /include folder. You probably copied over those files to your MinGW /bin, your MinGW /include and your MinGW /lib folder folder.
I suggest you remove all these files, get the latest pthread cvs (cvs -d :pserver:anoncvs@sources.redhat.com:/cvs/pthreads-win32 checkout pthreads), compile (make clean GC-static) and install it (copy libpthreadGC2.a to your MinGW /lib folder and copy pthread.h, sched.h and semaphore.h to your MinGW /iclude folder). That way you will eliminate the need of x264.exe for an extra pthreadGC2.dll in C:\Windows\System32.
Trust me on this one, I had the same problem.

I also suggest you people update your GPAC libraries. Many have reported errors building it from CVS, however I have found a nasty trick that actually works:
1. download the old stable tarball from here http://downloads.sourceforge.net/gpac/gpac-0.4.4-rc2.tar.gz
2. once it is downloaded, extract it to your MSYS /home/username folder and cd into it (i.e. cd /home/username/gpac)
3. while inside the gpac folder get the latest GPAC CVS using the command cvs -z3 -d:pserver:anonymous@gpac.cvs.sourceforge.net:/cvsroot/gpac co -P gpac
4. run ./configure && make lib
5. copy /home/username/gpac/include/gpac to your MinGW /include folder

P.S.: If this doesn't work for you try it in your /home folder (i.e. /home/gpac).

Thanks very much :) The problem was that I somehow got that damn DLL into my PATH without knowing it, so I thought my build was good.

[kemuri-_9]

i don't even bother with 'installing' the gpac/pthread library/include files..
it's easy enough to add
--extra-cflags="-I../pthreads -I../gpac/include" --extra-ldflags="-L../pthreads -L../gpac/bin/gcc"
to x264 configure to tell it where the files are without having to install them
especially useful when building multiple versions
since i do -march athlon-xp and pentium2 builds

[komisar]

I updated my previous message about speed comparsion of GCC here: http://forum.doom9.org/showthread.php?p=1179832#post1179832

[965] My CLI and VFW VAQmod builds found here: http://komisar.gin.by/

[techouse]

I'm trying to backup a DVD Video with x264 (the build from MeGUI) on Vista x64 but it crashes at the beginning. The avs script is playable in Media Player. Does x264 work with Vista x64?
Huh? I've been encoding with x264 on a Vista Business x64 since the dawn of time and have never had any problems with it. Check your filters and AVS.
P.S.: I'm just guessing, but did you crop the file right?

[skystrife]

x264.965.modified.exe (http://www.mediafire.com/?aakqpgnnmaa) - Alternate Download (http://skystrife.com/x264/x264.965.modified.exe)

Patches used:

x264_psy_rdo_0.6_r956.diff
x264_new_bframe_decision_04.7.diff
x264_hrd_pulldown.09_interlace.diff
x264_progress.indication_r957.diff

gcc 3.4.5 fprofiled build with -march=pentium2.

[burfadel]

Huh? I've been encoding with x264 on a Vista Business x64 since the dawn of time and have never had any problems with it. Check your filters and AVS.
P.S.: I'm just guessing, but did you crop the file right?

x264 works fine on both Xp x64 and Vista x64

[DarkZell666]

I'm trying to backup a DVD Video with x264 (the build from MeGUI) on Vista x64 but it crashes at the beginning. The avs script is playable in Media Player. Does x264 work with Vista x64?

Post your script, and maybe open a separate thread for it :)
Make sure it contains a ConvertToYV12() somewhere (preferably at the end), otherwise x264 won't accept it.
If it does, do other builds behave the same way ?

[lucassp]

Post your script, and maybe open a separate thread for it :)
Make sure it contains a ConvertToYV12() somewhere (preferably at the end), otherwise x264 won't accept it.
If it does, do other builds behave the same way ?

DGDecode_mpeg2source("D:\Test\VIDEO_TS\file.d2v",info=3)
ColorMatrix(hints=true,interlaced=true)
#Load_Stdcall_Plugin("C:\Program Files (x86)\Encodings\megui\tools\yadif\yadif.dll")
#Yadif(order=-1)
#crop
#resize
#denoise
Trim(5000,7000)

[Ranguvar]

@komisar: I see you have a LOT of minor patches on your website. Would you mind explaining what they do, in fairly basic terms? Mostly the following:

k.38.cosmetic.diff
999.log_param.diff
x264_32x32samples_crash.r870.diff
k.20.x264_fix_stats_file_work.r877.diff
x264_multithreading_Nth_pass_ratecontrol.r870.diff
bm_x264_thread_pool.r870.diff
k.41.x264_log_file.01k.r928.diff


Thanks!

[kemuri-_9]

@komisar: I see you have a LOT of minor patches on your website. Would you mind explaining what they do, in fairly basic terms? Mostly the following:

k.38.cosmetic.diff
changes x264 signature in crf mode to use 4 digits after the decimal instead of just 1
also adds a long \r line to clear output from progress before printing stats <--- already implemented in r957.

999.log_param.diff
writes the x264 generated signature to the stderr/log file

k.20.x264_fix_stats_file_work.r877.diff
looks to be an overhaul of the stats file writing and includes a padding mechanism for vfw compatibility

bm_x264_thread_pool.r870.diff
implements http://en.wikipedia.org/wiki/Thread_pool_pattern

k.41.x264_log_file.01k.r928.diff
adds the log-file parameter to log output to a file
(imo easier to just use tee)

[Ranguvar]

Thanks, kemuri!

Thread pool pattern looks interesting. I'll try a build with and without it, and compare.

Any ideas on x264_multithreading_Nth_pass_ratecontrol.r870.diff?

[kemuri-_9]

Any ideas on x264_multithreading_Nth_pass_ratecontrol.r870.diff?
looked at it again and it's definitely complexing up the bitrate approximation/ratecontrol so it should be more accurate.
that is, bitrate aiming in multi-threading should be more accurate (though i don't usually have a problem with this in x264 as is)

[MasterNobody]

kemuri-_9
Try to make 2pass encoding of small sample (500 frames is enough) with --threads 128 (128 because more threads more visible is quality degradation of few frames after 30-frame) without and with this patch. Probably than you will see the difference at frames 31 and few others.

[kemuri-_9]

and why would i realistically do that insane number of threads besides seeing at how many resources are being wasted by threads that can't be executed on my processors (being held in wait state)?
and not to mention all the processing time overhead from the thread swapping since the scheduler will probably swap them frequently with that large of a number of them.

[lexor]

You are right, kemuri, most of us can't use that many threads. Still, I do know people who run their encodes on Sun's servers (when they are idling at their workplace), which do run 128 threads per box, so they would care about that.

[Ranguvar]

Oh yeah, and if you could explain x264_32x32samples_crash.r870.diff, forgot about that one. Thanks again.

Doing a few tests now...

[MasterNobody]

and why would i realistically do that insane number of threads besides seeing at how many resources are being wasted by threads that can't be executed on my processors (being held in wait state)?
and not to mention all the processing time overhead from the thread swapping since the scheduler will probably swap them frequently with that large of a number of them.
This is only the example where you can see the difference easily. This bug (incorrect bitrate prediction) also exist with only 2-3 threads but it is not so visible.
Oh yeah, and if you could explain x264_32x32samples_crash.r870.diff, forgot about that one. Thanks again.

Doing a few tests now...
It is simply fix the crash (division by zero) when width or height of the source is 32 (17-32) when you encode with B-frames (and don't use --no-b-adapt).

[Ranguvar]

Thanks.

But this is very annoying... the patches are a mess of dependencies. Still trying to get it working, but jeez.

EDIT: Alright, I admit defeat. Every damn patch wants to bring in its friends, or it'll whine at me. komisar, if you read this, please help give me a way to test/use...

I only want:

x264_dll_alignment_fix.01.diff (no problem with your patches)
999.log_param.diff
x264_progress.indication_r957.diff
x264_32x32samples_crash.r870.diff
x264_multithreading_Nth_pass_ratecontrol.r870.diff (maybe)
bm_x264_thread_pool.r870.diff (maybe)
x264_hrd_pulldown.09_interlace.diff
x264_psy_rdo_0.6_r956.diff
x264_new_bframe_decision_04.7.diff


However, there are tons of dependencies... I really don't want to use the VAQ2mod, or fix_stats_file_work, or your version of the new b-frame decision patch...

Thanks :)

[kemuri-_9]

some of these, like the 32x32sample and Npass ratecontrol patches,
are fixes and I think the developers should look into implementing them into the repository.
(granted they work as intended still)
the logfile patch would be a feature they could add in if they whimmed it.

[Dark Shikari]

Yes, I agree; such fixes should not be used in custom builds but rather should just be committed if useful or not committed if not useful.

[Gabriel_Bouvigne]

looked at it again and it's definitely complexing up the bitrate approximation/ratecontrol so it should be more accurate.
that is, bitrate aiming in multi-threading should be more accurate (though i don't usually have a problem with this in x264 as is)
Could someone please point me at this patch?

[Underground78]

http://komisar.gin.by/x.patch/last.used/x264_multithreading_Nth_pass_ratecontrol.r870.diff

[komisar]

My used patches:
# Write to log encoding settings
999.log_param.diff (http://komisar.gin.by/x.patch/last.used/999.log_param.diff) (wo dep)

# Simply fix the crash (division by zero) when width or height of the source is 32 (17-32) when you encode with B-frames (and don't use --no-b-adapt)
x264_32x32samples_crash.r870.diff (http://komisar.gin.by/x.patch/last.used/x264_32x32samples_crash.r870.diff) (wo dep)

# Fix incorrect Nth-pass ratecontrol work with multithreading
x264_multithreading_Nth_pass_ratecontrol.r870.diff (http://komisar.gin.by/x.patch/last.used/x264_multithreading_Nth_pass_ratecontrol.r870.diff) (wo dep)

# More accurate calculation of i_frame, more correct workaround for VFW Nth-pass ratecontrol
k.20.x264_fix_stats_file_work.r877.diff (http://komisar.gin.by/x.patch/last.used/k.20.x264_fix_stats_file_work.r877.diff) (wo dep)

# Modified thread pool patch
bm_x264_thread_pool.r870.diff (http://komisar.gin.by/x.patch/last.used/bm_x264_thread_pool.r870.diff) (dep: "fix_stats_file_work", "multithreading_Nth_pass_ratecontrol")

# Write encoder outputs to file
k.41.x264_log_file.01k.r928.diff (http://komisar.gin.by/x.patch/last.used/k.41.x264_log_file.01k.r928.diff) (wo dep)

# Change precision of CRF-value in encoder settings
k.38.cosmetic.diff (http://komisar.gin.by/x.patch/last.used/k.38.cosmetic.diff) (wo dep)

# Add some addition task to profiling
999.profiled.01.diff (http://komisar.gin.by/x.patch/last.used/999.profiled.01.diff) (wo dep)

# Workaround of incorrect profiling of VFW (gcc 4.4)
k.vfw.01.dummy-log.diff (http://komisar.gin.by/x.patch/last.used/k.vfw.01.dummy-log.diff) (wo dep)

# Helper for make profiled build of VFW
k.vfw.02.profile.diff (http://komisar.gin.by/x.patch/last.used/k.vfw.02.profile.diff) (wo dep)

# Add ability to call external gui for VFW
k.vfw.03.external_config.01.diff (http://komisar.gin.by/x.patch/last.used/k.vfw.03.external_config.01.diff) (wo dep)
Ranguvar
x264_psy_rdo_0.6_r956.diff
x264_new_bframe_decision_04.7.diff
x264_hrd_pulldown.09_interlace.diff
Some as posted in this thread. I only make this compatible with my patched build.

P.S. I add prefix "k.XX...." because this patches (in original) not clear apply and I make them more compatible. Or I make this patch by myself.

P.P.S. Original version of some patches "by MasterNobody/BugMaster" found here: [x264-devel] BugMaster's patches (fix various problems) (http://mailman.videolan.org/pipermail/x264-devel/2008-January/003921.html)

And mirror of MasterNobody/BugMaster patches (next message) found here: http://komisar.gin.by/x.patch/BugMaster/20080908/

[MasterNobody]

Here are updated versions of my patches (which I use to build x264vfw): http://stashbox.org/208351/bm_x264_patch_collection.r965.zip
In this archive you will find independent versions of some patches (for example, x264_thread_pool.r965.diff)

List of patches in collection:
01_x264_32x32samples_crash.r965.diff
01_x264_cosmetic.r965.diff
01_x264_debug_defines.r965.diff
01_x264_fix_stats_file_work.r965.diff
01_x264_multithreading_bug_check.r965.diff
01_x264_multithreading_Nth_pass_ratecontrol.r965.diff
02_bm_x264_error_memoryleaks.02.r965.diff
03_bm_x264_thread_pool.r965.diff
04_bm_x264_vaqmod.01.r965.diff
05_bm_x264_psy_rdo_0.6.r965.diff
06_bm_x264_new_bframes_decision.04.7.r965.diff

Independent\
x264_32x32samples_crash.r965.diff
x264_cosmetic.r965.diff
x264_debug_defines.r965.diff
x264_error_memoryleaks.02.r965.diff
x264_fix_stats_file_work.r965.diff
x264_multithreading_bug_check.r965.diff
x264_multithreading_Nth_pass_ratecontrol.r965.diff
x264_thread_pool.r965.diff
x264_vaqmod.01.r965.diff

[Gabriel_Bouvigne]

The 32x32 fix seems really strange, especially the "pmb = -imb;" line. Did you intended to have a negative number of P MB ?

[Ranguvar]

Thanks very much, BugMaster - that may be what I'm looking for. I'll test ASAP.

Will all your updated patches be here always? http://komisar.gin.by/x.patch/BugMaster/

[stanjr]

I am compiling/encoding on a 64-bit Ubuntu quad-core machine.

Using x264_new_bframe_decision_04.7.diff causes the following error:
libx264.c: In function 'X264_init':
libx264.c: 165: error: X264_param_t has no member named 'b_bframe_adaptive'
(after compiling x264 and then when compiling mplayer to use x264 with mencoder)

Have I done something wrong?

[recover]

I just wanted to let you know that there is an updated version of the progress indication patch here (http://forum.doom9.org/showthread.php?p=1117683#post1117683).
The difference is only that the code is now enclosed in #ifdef _WIN32 so that it can compile on other OS.
I guess you have to fix this updated version the same way you've done with the previous version as well.

[Sharktooth]

it's useless for him since he's on ubuntu

[stanjr]

What about the 'b_bframe_adaptive' error?

[Sharktooth]

was the patching successfull?

[stanjr]

Yeah, patching x264 was successful and it compiled fine. It was only when I then got to compiling mplayer that I got the error. If you need more info, I can try to get what you need when I get home later.