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

[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.