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

[juGGaKNot]

x264_x86_r1354_v3_techouse (http://techouse.project357.com/builds/x86/x264_x86_r1354_v3_techouse.7z) | INFO (http://techouse.project357.com/nfo/x86/x264_x86_r1354_v3_techouse.txt)
GCC 4.4.2 20091019 (x86.generic.Komisar), generic, fprofiled

unpatched WORKS, TESTED.
pachted only with x264_win_zone_parse_fix_06.diff WORKS, TESTED.
patched with x264_win_zone_parse_fix_06.diff AND x264-r1352-nal_hrd-pic_struct-v11.patch FAILS, TESTED.
patched with x264_win_zone_parse_fix_06.diff AND x264_hrd_pd_interlace.16_r1301.diff NOT TESTED.

[rack04]

x264_x86_r1354M (http://www.mediafire.com/?nzigkztmdmz)

Built by rack04 on November 30, 2009, 4:32:10 PM CST
GCC 4.3.4 (x86.core2.Komisar)
--extra-cflags="-march=core2"
make fprofiled

Patched with:

x264_hrd_pd_interlace.16_r1301.diff (http://85.230.118.136/showthread.php?p=1336048#post1336048)
x264_win_zone_parse_fix_06.diff (http://kemuri9.net/dev/x264/patches/x264_win_zone_parse_fix_06.diff)

[techouse]

x264_x86_r1354_NAL-HRD-16-1301_techouse (http://techouse.project357.com/builds/x86/x264_x86_r1354_NAL-HRD-16-1301_techouse.7z) | INFO (http://techouse.project357.com/nfo/x86/x264_x86_r1354_NAL-HRD-16-1301_techouse.txt)
GCC 4.4.2 20091019 (x86.generic.Komisar), generic, fprofiled

x264_x64_r1354_NAL-HRD-16-1301_techouse (http://techouse.project357.com/builds/x64/x264_x64_r1354_NAL-HRD-16-1301_techouse.7z) | INFO (http://techouse.project357.com/nfo/x64/x264_x64_r1354_NAL-HRD-16-1301_techouse.txt)
GCC 4.4.2 20091019 (x86_64.generic.Komisar), generic, fprofiled

Patches used:

x264_win_zone_parse_fix_06.diff (http://kemuri9.net/dev/x264/patches/x264_win_zone_parse_fix_06.diff)
x264_hrd_pd_interlace.16_r1301.diff (http://85.230.118.136/showthread.php?p=1336048#post1336048)

[juGGaKNot]

x264_x86_r1354_NAL-HRD-16-1301_techouse (http://techouse.project357.com/builds/x86/x264_x86_r1354_NAL-HRD-16-1301_techouse.7z) | INFO (http://techouse.project357.com/nfo/x86/x264_x86_r1354_NAL-HRD-16-1301_techouse.txt)
GCC 4.4.2 20091019 (x86.generic.Komisar), generic, fprofiled

unpatched WORKS, TESTED.
pachted only with x264_win_zone_parse_fix_06.diff WORKS, TESTED.
patched with x264_win_zone_parse_fix_06.diff AND x264_hrd_pd_interlace.16_r1301.diff WORKS, TESTED.
patched with x264_win_zone_parse_fix_06.diff AND x264-r1352-nal_hrd-pic_struct-v11.patch FAILS, TESTED.

[Zm_Gorynych]

patched with x264_win_zone_parse_fix_06.diff AND x264-r1352-nal_hrd-pic_struct-v11.patch FAILS, TESTED.
Any details (command line, backtrace)?

[juGGaKNot]

Check the previos pages for cmd, i deleted the backtrace stuff when i deleted the msys folder ( bad net )

[[ReX]]

Edit x264_hrd_pd_interlace.16_r1301.diff to avoid fuzz in encoder/ratecontrol.h with x264 r1360.

Original
diff --git a/encoder/ratecontrol.h b/encoder/ratecontrol.h
index d3b9bec..bc047b9 100644
--- a/encoder/ratecontrol.h
+++ b/encoder/ratecontrol.h
@@ -36,7 +36,7 @@ void x264_ratecontrol_start( x264_t *, int i_force_qp, int overhead );
int x264_ratecontrol_slice_type( x264_t *, int i_frame );
void x264_ratecontrol_mb( x264_t *, int bits );
int x264_ratecontrol_qp( x264_t * );
-int x264_ratecontrol_end( x264_t *, int bits );
+int x264_ratecontrol_end( x264_t *, int bits, int vfrlowhigh );
void x264_ratecontrol_summary( x264_t * );
void x264_ratecontrol_set_estimated_size( x264_t *, int bits );
int x264_ratecontrol_get_estimated_size( x264_t const *);

New
diff --git a/encoder/ratecontrol.h b/encoder/ratecontrol.h
index b9d552b..9f81f32 100644
--- a/encoder/ratecontrol.h
+++ b/encoder/ratecontrol.h
@@ -37,7 +37,7 @@ int x264_ratecontrol_slice_type( x264_t *, int i_frame );
void x264_ratecontrol_set_weights( x264_t *h, x264_frame_t *frm );
void x264_ratecontrol_mb( x264_t *, int bits );
int x264_ratecontrol_qp( x264_t * );
-int x264_ratecontrol_end( x264_t *, int bits );
+int x264_ratecontrol_end( x264_t *, int bits, int vfrlowhigh );
void x264_ratecontrol_summary( x264_t * );
void x264_ratecontrol_set_estimated_size( x264_t *, int bits );
int x264_ratecontrol_get_estimated_size( x264_t const *);

The fuzz is harmless, I guess, but better safe than sorry. :rolleyes:

[[ReX]]

My x264 r1360 builds.

GCC builds

Generic (http://www.mediafire.com/?rjjtgg2zjgo) (fprofiled)
Patches used: x264_hrd_pd_interlace.16_r1301.diff and x264_win_zone_parse_fix_06.diff

-march=core2 (http://www.mediafire.com/?kgnynjzzinz) (fprofiled)
Patches used: x264_hrd_pd_interlace.16_r1301.diff and x264_win_zone_parse_fix_06.diff


ICC 11 builds
Thanks to MasterNobody and XhmikosR.
(x264_win_zone_parse_fix_06.diff not needed)

Generic (http://www.mediafire.com/?rjjtgg2zjgo) (fprofiled)
Patches used: x264_icc_r1342.diff and x264_hrd_pd_interlace.16_r1301.diff

/QaxSSSE3 /O3 (http://www.mediafire.com/?ntzntzmynyy) (fprofiled)
Patches used: x264_icc_r1342.diff and x264_hrd_pd_interlace.16_r1301.diff

/QxSSSE3 /O3 (http://www.mediafire.com/?ownjfzzzmtz) (fprofiled)
Patches used: x264_icc_r1342.diff and x264_hrd_pd_interlace.16_r1301.diff

[imk]

r1360M built with ICC.

Windows:
x264-r1360M-imk-win.7z (http://imk.cx/pc/x264/x264-r1360M-imk-win.7z)
win_build_info.txt (http://imk.cx/pc/x264/win_build_info.txt)

Mac OS X:
x264-r1360M-imk-osx.7z (http://imk.cx/pc/x264/x264-r1360M-imk-osx.7z)
osx_build_info.txt (http://imk.cx/pc/x264/osx_build_info.txt)

[olapanekala]

;1349881']My x264 r1360 builds.

GCC builds

Generic (http://www.mediafire.com/?rjjtgg2zjgo) (fprofiled)
Patches used: x264_hrd_pd_interlace.16_r1301.diff and x264_win_zone_parse_fix_06.diff

-march=core2 (http://www.mediafire.com/?kgnynjzzinz) (fprofiled)
Patches used: x264_hrd_pd_interlace.16_r1301.diff and x264_win_zone_parse_fix_06.diff


ICC 11 builds
Thanks to MasterNobody and XhmikosR.
(x264_win_zone_parse_fix_06.diff not needed)

Generic (http://www.mediafire.com/?rjjtgg2zjgo) (fprofiled)
Patches used: x264_icc_r1342.diff and x264_hrd_pd_interlace.16_r1301.diff

/QaxSSSE3 /O3 (http://www.mediafire.com/?ntzntzmynyy) (fprofiled)
Patches used: x264_icc_r1342.diff and x264_hrd_pd_interlace.16_r1301.diff

/QxSSSE3 /O3 (http://www.mediafire.com/?ownjfzzzmtz) (fprofiled)
Patches used: x264_icc_r1342.diff and x264_hrd_pd_interlace.16_r1301.diff

any QxSSSE3 ICC builds for r1360?

[imk]

Optimizing for SSSE3 really has no improvements, since you're going to be using the asm functions instead of the C functions.

[[ReX]]

any QxSSSE3 ICC builds for r1360?

Well, that's what my post says, or do you want QxSSSE3 without O3? :confused:

[olapanekala]

;1350215']Well, that's what my post says, or do you want QxSSSE3 without O3? :confused:

Missread your post. Test it and it rocks. Thnx!!!

[[ReX]]

My x264 r1361 builds.

GCC builds

Generic (http://www.mediafire.com/?amdm2kedmky) (fprofiled)
Patches used: x264_hrd_pd_interlace.16_r1301.diff and x264_win_zone_parse_fix_06.diff

-march=core2 (http://www.mediafire.com/?qy25yztntd5) (fprofiled)
Patches used: x264_hrd_pd_interlace.16_r1301.diff and x264_win_zone_parse_fix_06.diff


ICC 11 builds
Thanks to MasterNobody and XhmikosR.
(x264_win_zone_parse_fix_06.diff not needed)

Generic (http://www.mediafire.com/download.php?mdrohct2iym) (fprofiled)
Patches used: x264_icc_r1342.diff and x264_hrd_pd_interlace.16_r1301.diff

/QaxSSSE3 /O3 (http://www.mediafire.com/?yjjkdu1ljmf) (fprofiled)
Patches used: x264_icc_r1342.diff and x264_hrd_pd_interlace.16_r1301.diff

/QxSSSE3 /O3 (http://www.mediafire.com/?3nktmwuzvzj) (fprofiled)
Patches used: x264_icc_r1342.diff and x264_hrd_pd_interlace.16_r1301.diff

[juGGaKNot]

;1350942']GCC builds

what GCC ?

[chornobyl]

http://en.wikipedia.org/wiki/GNU_Compiler_Collection

[Audionut]

I think you'll find he was asking for version number.

[cogman]

Optimizing for SSSE3 really has no improvements, since you're going to be using the asm functions instead of the C functions.

Um no, it has no improvements because the instructions introduced by SSSE3 are both slower and less optimal then the non-sse version.

All C functions are eventually broken down to ASM instructions.

[kemuri-_9]

Um no, it has no improvements because the instructions introduced by SSSE3 are both slower and less optimal then the non-sse version.

All C functions are eventually broken down to ASM instructions.

he's saying that having intel (or gcc for that matter with people using -march=core2) compile the C code with at most using SSSE3 instructions provides hardly any benefit over compiling for something lower.
because all cpu intensive instructions are done via handwritten asm.

all you're proving to do is reduce the number of computers that can use the binary for hardly if any speed benefit.

[[ReX]]

what GCC ?

x264 --version
x264 0.79.1361M 733b660
built on Dec 9 2009, gcc: 4.5.0 20091203 (experimental)

[juGGaKNot]

;1351078']x264 --version
x264 0.79.1361M 733b660
built on Dec 9 2009, gcc: 4.5.0 20091203 (experimental)

Well warning people, before they download, that an experimental GCC was used for compilation helps ...

Anyway support for MB-tree + B-pyramid was added, techouse/jeeb builds please :D

[jpsdr]

Anyway support for MB-tree + B-pyramid was added, techouse/jeeb builds please :D

Bad luck if they are on vacation until next year...:)

[rack04]

Well warning people, before they download, that an experimental GCC was used for compilation helps ...

Anyway support for MB-tree + B-pyramid was added, techouse/jeeb builds please :D

x264_hrd_pd_interlace.16_r1301.diff is broken with the newest git.

[juGGaKNot]

Darn i have to install everything again.

LE : http://x264.tk/ techouse 1369 x264_win_zone_parse_fix_06.diff build is up

x264.nl says latest changes: Add fast pskip to x264 SEI info heade = 1369 :)

[komisar]

x264_hrd_pd_interlace.16_r1369.diff (http://komisar.gin.by/x.patch/last.used/x264_hrd_pd_interlace.16_r1369.diff)

[JEEB]

Who said anything about having a vacation ;)

You can always get my newest builds over at x264.fushizen.eu (http://x264.fushizen.eu).

Building nal-hrd'd builds as we speak :)

edit:

Added the 32/64bit nal-hrd'd builds to the 1369 post here (http://x264.fushizen.eu/?p=65).

[juGGaKNot]

Who said anything about having a vacation ;)

You can always get my newest builds over at x264.fushizen.eu (http://x264.fushizen.eu).

Building nal-hrd'd builds as we speak :)

edit:

Added the 32/64bit nal-hrd'd builds to the 1369 post here (http://x264.fushizen.eu/?p=65).

x86 has x264_win_zone_parse_fix_06.diff ? not hrd one.

[JEEB]

x86 has x264_win_zone_parse_fix_06.diff ? not hrd one.
Yes, it has the win_zone_parse_fix, which is actually somewhat nice to have, since some people have actually thought about using it in some situations ;)

[juGGaKNot]

Yes, it has the win_zone_parse_fix, which is actually somewhat nice to have, since some people have actually thought about using it in some situations ;)

win_zone_parse_fix is the only reason i do not use x264.nl builds :)

[poisondeathray]

Yes, it has the win_zone_parse_fix, which is actually somewhat nice to have, since some people have actually thought about using it in some situations ;)

What currently doesn't work with the patch?

the wiki says:

Fixes the zones option to completely work on Windows, due to a missing function in the API used by x264. Without the patch, only the rate control options work in zones.


But in the past, things like changing AQ didn't work

[kemuri-_9]

What currently doesn't work with the patch?
But in the past, things like changing AQ didn't work

the patch allows the use of 2 or more zones on mingw compiles.
it has absolutely no effect on what is configurable via zones.
the list of options that are zone-configurable are at
http://mewiki.project357.com/wiki/X264_Settings#zones
do note that AQ is not zone-configurable

[poisondeathray]

^thanks kemuri!

[[ReX]]

My x264 r1369 builds.

GCC 4.5.0 (experimental) builds

Generic (http://www.mediafire.com/?qzzmmtt5ivj) (fprofiled)
Patches used: x264_hrd_pd_interlace.16_r1369.diff and x264_win_zone_parse_fix_06.diff

-march=core2 (http://www.mediafire.com/?mdzhjmm3ncd) (fprofiled)
Patches used: x264_hrd_pd_interlace.16_r1369.diff and x264_win_zone_parse_fix_06.diff


ICC 11 builds
Thanks to MasterNobody and XhmikosR.
(x264_win_zone_parse_fix_06.diff not needed)

Generic (http://www.mediafire.com/?umuymwk5jem) (fprofiled)
Patches used: x264_icc_r1342.diff and x264_hrd_pd_interlace.16_r1369.diff

/QaxSSSE3 /O3 (http://www.mediafire.com/?zamoaywwnkj) (fprofiled)
Patches used: x264_icc_r1342.diff and x264_hrd_pd_interlace.16_r1369.diff

/QxSSSE3 /O3 (http://www.mediafire.com/?qzyy4zgimnw) (fprofiled)
Patches used: x264_icc_r1342.diff and x264_hrd_pd_interlace.16_r1369.diff


Well warning people, before they download, that an experimental GCC was used for compilation helps ...
Should I use 4.4.2 or 4.3.4 then?

[tormento]

;1351210']My x264 r1369 builds.
Rex, would you mind to compile x64 builds too? ;)

[burfadel]

;1351210']My x264 r1369 builds.

GCC 4.5.0 (experimental) builds

Should I use 4.4.2 or 4.3.4 then?

I think the experimental builds are a good option. There are already others that build using other GCC versions, but none that use the experiemental versions. As long as you state its an experimental version (and you use the latest) and the build date of that version its fine :)

I did a completely unscientific test of x264 build 1360 from xvidvideo.ru which used the GCC 4.5.0 experimental from 27.11.2009, and I have to say it appeared to be faster than those builds from x264.nl, but as I said completely unscientific test! Maybe someone with some time could do an updated comparison of the speed.

I use ffdshow and mplayerc from there as well, which are also built using the experimental GCC and have had no problems in terms of stability, so it should be ok to use (as long as its stated that its built with an experimental GCC version)!

[juGGaKNot]

Should I use 4.4.2 or 4.3.4 then?

Use what you want ofc

Note that no one uses 3.4.6 ( only x264.nl but no patched builds ) and people might use this since its stable ( ds said that gcc 4.x.x is not recommended for x86 builds )

IMO if you could do 3.4.6 ( only x86 ofc ) and 4.5.0 would be nice.

[rack04]

I haven't been able to find a link to download 3.4.6.

[XhmikosR]

Does anybody else noticed any crashes with ICC 1369 patched builds using b-pyramid normal + mb-tree? Currently it seems that it happens only for me and with a specific BluRay sample. I haven't tried someone else's ICC build, only my builds.
As for gcc, please note that 4.4.2 is slightly faster than 3.4.6. IIRC x264.nl will use gcc 4.4.2 for the future builds too...

[LoRd_MuldeR]

Does anybody else noticed any crashes with ICC 1369 patched builds using b-pyramid normal + mb-tree? Currently it seems that it happens only for me and with a specific BluRay sample.

Other people are reporting crashes too. Not with ICC builds, but with r1369:
http://forum.doom9.org/showthread.php?p=1351167#post1351167

[XhmikosR]

Yes, but the thing is that my GCC built with the same patches, encoding the exact same video, does not crash...

[LoRd_MuldeR]

That makes things complicated. Either we have a bug in x264 that shows up only sporadically and only in combination with a specific compiler. Or we have (related or unrelated) miscompilation problems in both, GCC and ICC.

[XhmikosR]

I'm running an ICC Debug build for 15 hours now with the same settings... It's slow and by slow I mean really slow. 0.06 fps. It's at ~60% and no crash so far. I hope it will have crashed by the time it finishes.

[jpsdr]

Problem is that in debug build, a lot of optimisations are not done. So, if it's realy a software bug, it should reproduce(*), but if it's a compiltation issue, it may not.
(*) You can have more tricky problem : a variable not initialised may have a random value in standard build, but sometimes debug build automaticaly initialise variables to 0. So, debug build can mask the problem. Realy not easy...

[XhmikosR]

Yes, but with the normal build I cannot provide lot of information to the x264 devs. If someone else faced crashes with r1369 ICC builds it would be better. Anyway, we'll see how it goes.

[olapanekala]

;1351210']My x264 r1369 builds.

GCC 4.5.0 (experimental) builds

Generic (http://www.mediafire.com/?qzzmmtt5ivj) (fprofiled)
Patches used: x264_hrd_pd_interlace.16_r1369.diff and x264_win_zone_parse_fix_06.diff

-march=core2 (http://www.mediafire.com/?mdzhjmm3ncd) (fprofiled)
Patches used: x264_hrd_pd_interlace.16_r1369.diff and x264_win_zone_parse_fix_06.diff


ICC 11 builds
Thanks to MasterNobody and XhmikosR.
(x264_win_zone_parse_fix_06.diff not needed)

Generic (http://www.mediafire.com/?umuymwk5jem) (fprofiled)
Patches used: x264_icc_r1342.diff and x264_hrd_pd_interlace.16_r1369.diff

/QaxSSSE3 /O3 (http://www.mediafire.com/?zamoaywwnkj) (fprofiled)
Patches used: x264_icc_r1342.diff and x264_hrd_pd_interlace.16_r1369.diff

/QxSSSE3 /O3 (http://www.mediafire.com/?qzyy4zgimnw) (fprofiled)
Patches used: x264_icc_r1342.diff and x264_hrd_pd_interlace.16_r1369.diff



Should I use 4.4.2 or 4.3.4 then?

The 1369 QxSSS3/O3 crashes in my system. 1360 QxSSS3/O3 works like charm.

[[ReX]]

Rex, would you mind to compile x64 builds too? ;)
Sorry, my OS is x86, but I think I'll be installing Windows 7 x64 soon (well not too soon).


I think the experimental builds are a good option. There are already others that build using other GCC versions, but none that use the experiemental versions. As long as you state its an experimental version (and you use the latest) and the build date of that version its fine :)

I did a completely unscientific test of x264 build 1360 from xvidvideo.ru which used the GCC 4.5.0 experimental from 27.11.2009, and I have to say it appeared to be faster than those builds from x264.nl, but as I said completely unscientific test! Maybe someone with some time could do an updated comparison of the speed.

I use ffdshow and mplayerc from there as well, which are also built using the experimental GCC and have had no problems in terms of stability, so it should be ok to use (as long as its stated that its built with an experimental GCC version)!
That's a valid point.


Use what you want ofc

Note that no one uses 3.4.6 ( only x264.nl but no patched builds ) and people might use this since its stable ( ds said that gcc 4.x.x is not recommended for x86 builds )

IMO if you could do 3.4.6 ( only x86 ofc ) and 4.5.0 would be nice.
I don't know if it's possible to have two GCC versions at the the same time without screwing things up.


The 1369 QxSSS3/O3 crashes in my system. 1360 QxSSS3/O3 works like charm.

I will compile a version without x264_hrd_pd_interlace.16_r1369.diff and we'll see if that's the problem.

Edit: Please test it -> http://www.mediafire.com/?dcbbzzlijd0

XhmikosR: that's weird, it didn't crash with me, I need to test with some different videos.

Edit 2: Confirmed, it crashed using this (http://forum.doom9.org/showpost.php?p=1351167&postcount=1084) command line

[XhmikosR]

The 1369 QxSSS3/O3 crashes in my system. 1360 QxSSS3/O3 works like charm.

The same problem as I have. Nice to see I'm not alone :p

I tried a build even without nal hdr but still crashed for me...

[Dark Shikari]

Bug fixed (http://git.videolan.org/?p=x264.git;a=commit;h=65b3d0fd9f8167a6d0772a29e8fcf1a66ee7f8af). See the x264 git status and postmortem thread (http://doom10.org/index.php?topic=58) for more details.

That took an completely unreasonable number of hours to find and fix.

[imk]

r1373M built with ICC.

Windows:
x264-r1373M-imk-win.7z (http://imk.cx/pc/x264/x264-r1373M-imk-win.7z)
win_build_info.txt (http://imk.cx/pc/x264/win_build_info.txt)

Mac OS X:
x264-r1373M-imk-osx.7z (http://imk.cx/pc/x264/x264-r1373M-imk-osx.7z)
osx_build_info.txt (http://imk.cx/pc/x264/osx_build_info.txt)

[CpT]

Sweet!

Hey DS is re-registration required for the other forums? Or was the db imported?