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

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