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

[Fr4nz]

You are comparing 1163 and 1162, and they are using different patches.

No, see here:
http://git.videolan.org/gitweb.cgi?p=x264.git;a=shortlog

[LoRd_MuldeR]

The problem is not the difference between r1163 and r1162 (that is negligible), but that fact that one of the builds you were comparing is "v1162 Jeeb patched build" ;)

Unofficial patches can do all sorts of things, making the comparison useless. To get a proper comparison, use two vanilla (unpatched) builds or use the same patches for both builds at least!

[laserfan]

Thanks LM re: answering my "with MP4" query. :)

[Fr4nz]

The problem is not the difference between r1163 and r1162 (that is negligible), but that fact that one of the builds you were comparing is "v1162 Jeeb patched build" ;)

Unofficial patches can do all sorts of things, making the comparison useless. To get a proper comparison, use two vanilla (unpatched) builds or use the same patches for both builds at least!

Mulder, if I point out that there's a 4-5% gain, there's a reason...this is not a thing that I noticed yesterday, but since I spotted Imk first compiled builds...

[LoRd_MuldeR]

If I point out that there's a 4-5% gain, there's a reason...this is not a thing that I noticed yesterday, but since I spotted Imk first compiled builds...

Which doesn't change the fact that comparing the speed of builds which use different patches will not give you meaningful results ;)

[Fr4nz]

Which doesn't change the fact that comparing the speed of builds which use different patches will not give you meaningful results ;)

You're completely right, I should prepare a test in order to demonstrate my thesis, but I don't have time :)

So: trust me :D

[kemuri-_9]

yes the ICC builds from imk have most often been fractionally faster than the standard gcc builds as previously stated within this thread,
but they are also are usually compiled with higher mandatory asm requirements...
i imagine he's still doing SSE2 (generally for AMD) and SSSE3 (for Intel) builds of x264.
so older cpu chips can't use such builds....

[CruNcher]

@kemuri-_9
something is strange with your build i tried to get IBBP but i always get IBP from your build --b-adapt 0 -b 2 --scenecut -1 -I 25 the k8 one jarod results in the expected IBBP sequence

[kemuri-_9]

@kemuri-_9
something is strange with your build i tried to get IBBP but i always get IBP from your build --b-adapt 0 -b 2 --scenecut -1 -I 25 the k8 one jarod results in the expected IBBP sequence

ah... hmm... i did manage to replicate and somewhat pinpoint the issue...
seems to be another bug in the threaded slicetype patch...
thanks for pointing it out.

some more testing seems to reveal that b-adapt 0 is mostly broken with the current state of that patch...

[G_M_C]

yes the ICC builds from imk have most often been fractionally faster than the standard gcc builds as previously stated within this thread,
but they are also are usually compiled with higher mandatory asm requirements...
i imagine he's still doing SSE2 (generally for AMD) and SSSE3 (for Intel) builds of x264.
so older cpu chips can't use such builds....

I've ran an encode with IMK's ICC build v. 1163 for x32, and it crashed @ 90.2% of the 2nd pas of the encode. I did OC my system to 3,2 GHz, but the CPU is a it is an QX9650 that hasn't had a problem before at that speed. I've raised the voltage to the CPU slightly, and the 2nd pass of the encode is re-running now.

I'll report back to let you know if the problem has re-occurred (or not).

EDIT:
The encode went fine this time. Seems it was the stabillity of my system that was at fault, the slightly raised voltage did it.

[Atak_Snajpera]

The encode went fine this time. Seems it was the stabillity of my system that was at fault, the slightly raised voltage did it.
You should always check stability in Prime95 MT before encoding.

[G_M_C]

You should always check stability in Prime95 MT before encoding.

It's the first encode that had this error, out a great number. Never had a stabillity problem before.

[Sharktooth]

@Fr4nz: r1162 and r1163 are identical code wise. the only difference is in the configure script (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commitdiff;h=3f56e271ac3d8a0e054b8b18e63886a6070ef05e).
so please dont spread bull$hit.

[Fr4nz]

@Fr4nz: r1162 and r1163 are identical code wise. the only difference is in the configure script (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commitdiff;h=3f56e271ac3d8a0e054b8b18e63886a6070ef05e).
so please dont spread bull$hit.

Hey Sharkthoot:

1) I never said that the code was different between 1162 and 1163;
2) Read *better* my posts (this is a corollary from point 1);
3) I suggest you to moderate your language, as stated in rule #4.

[imk]

Does ICC has something similar to GCC's fprofile and MSVC's PGO? According to my test, profiling does increase performance by ~3% for GCC build and ~5% for MSVC build.

Yes, I profile each build I make.


yes the ICC builds from imk have most often been fractionally faster than the standard gcc builds as previously stated within this thread,
but they are also are usually compiled with higher mandatory asm requirements...
i imagine he's still doing SSE2 (generally for AMD) and SSSE3 (for Intel) builds of x264.
so older cpu chips can't use such builds....

Correct. I still build separate SSE2 and SSSE3 builds. The SSE2 builds are only built to satisfy AMD users, while the SSSE3 builds are meant for Intel Core 2 Duo's and higher.



As for performance differences, I occasionally update a spreadsheet I have with performance comparisons.

http://spreadsheets.google.com/pub?key=pbffjdC6iUPWs2HtYHwZ2VQ

These are my benchmarks and I try to keep them as detailed as possible so that there's no confusion in the results.

The gains with using ICC can be pretty small, but as long as it produces identical output with no problems, then it might as well be used. ;)

[akupenguin]

btw, I just checked your SSSE3 builds... they use SSSE3 in a grand total of 2 functions (ssd and predict_16x16_dc_top), both of which have asm anyway. If there's a difference in speed, it's due to icc's equivalent of -mtune, not due to the instruction set. Furthermore, there isn't much difference in the timing of scalar instructions between Core2 vs K8, so I have to wonder whether you're gaining anything at all by having separate SSE2 vs SSSE3 builds (that part isn't listed on your spreadsheet).

[imk]

Yeah, I've never actually compared the differences between the SSE2 and SSSE3 builds.

I'm probably going to use a combination of -x and -ax for future builds, which will enable SSE2 as a baseline requirement, while providing optimizations for other processors if available.

[techouse]

x264_x64_r1165_unpatched (http://techouse.project357.com/builds/revision1165/x264.exe) | MD5 (http://techouse.project357.com/builds/revision1165/x264.md5)
GCC 4.4.0 20090524 (x64.core2.Komisar), unpatched, generic, fprofiled

________________________________________________________________________________

x264_x86_r1165_techouse (http://techouse.project357.com/builds/x264_x86_r1165_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x86_r1165_techouse.txt)
GCC 4.4.0 20090524 (x86.core2.Komisar), fprofiled, -march=core2

x264_x64_r1165_techouse (http://techouse.project357.com/builds/x264_x64_r1165_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x64_r1165_techouse.txt)
GCC 4.4.0 20090524 (x64.core2.Komisar), fprofiled, -march=core2

Patches used:

x264_hrd_pulldown.13_interlace.diff
x264_win_zone_parse_fix_05.diff

________________________________________________________________________________

x264_x86_r1165_AutoVAQ.0.2_techouse (http://techouse.project357.com/builds/x264_x86_r1165_AutoVAQ.0.2_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x86_r1165_AutoVAQ.0.2_techouse.txt)
GCC 4.4.0 20090524 (x86.core2.Komisar), fprofiled, -march=core2

x264_x64_r1165_AutoVAQ.0.2_techouse (http://techouse.project357.com/builds/x264_x64_r1165_AutoVAQ.0.2_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x64_r1165_AutoVAQ.0.2_techouse.txt)
GCC 4.4.0 20090524 (x64.core2.Komisar), fprofiled, -march=core2

Patches used:

x264_AutoVAQ.02.diff
x264_hrd_pulldown.13_interlace.diff
x264_win_zone_parse_fix_05.diff

[JEEB]

x264 r1165 32bit
download (http://jeeb.fiveforty.jp/x264/1165/x264.exe) ; release notes (http://jeeb.fiveforty.jp/x264/1165/relnotes.txt)

built on Jun 11 2009, gcc: 4.3.3
fprofiled, -march=i686


x264 r1165 64bit
download (http://jeeb.fiveforty.jp/x264/1165_x64/x264.exe) ; release notes (http://jeeb.fiveforty.jp/x264/1165_x64/relnotes.txt)

built on Jun 11 2009, gcc: 4.3.4 20090220 (prerelease) (x64.generic.Komisar)
fprofiled, -march=core2


Both patched with:

x264_win_zone_parse_fix_05.diff
x264_hrd_pulldown.13_interlace.diff


x264 r1165 AutoVAQ patched:

32bit (http://jeeb.fiveforty.jp/x264/1165avaq/x264.exe)
64bit (http://jeeb.fiveforty.jp/x264/1165avaq_x64/x264.exe)

(Built otherwise with the same patches, settings and compilers. x264_AutoVAQ.02.diff version of the AutoVAQ patch used.)

[JEEB]

x264 r1169 32bit
download (http://jeeb.fiveforty.jp/x264/1169/x264.exe) ; release notes (http://jeeb.fiveforty.jp/x264/1169/relnotes.txt)

built on Jun 20 2009, gcc: 4.3.3
fprofiled, -march=i686


x264 r1169 64bit
download (http://jeeb.fiveforty.jp/x264/1169_x64/x264.exe) ; release notes (http://jeeb.fiveforty.jp/x264/1169_x64/relnotes.txt)

built on Jun 20 2009, gcc: 4.3.4 20090220 (prerelease) (x64.generic.Komisar)
fprofiled, -march=core2


Both patched with:

x264_win_zone_parse_fix_05.diff
x264_hrd_pulldown.13_interlace.diff


x264 r1169 AutoVAQ patched:

32bit (http://jeeb.fiveforty.jp/x264/1169avaq/x264.exe)
64bit (http://jeeb.fiveforty.jp/x264/1169avaq_x64/x264.exe)

(Built otherwise with the same patches, settings and compilers. x264_AutoVAQ.02.diff version of the AutoVAQ patch used.)

[G_M_C]

@imk,

was looking for a new build on you .tk site, but the most recent one was from 4th of June. Could you make a new/recent one please ?

[JEEB]

x264 r1171 32bit
download (http://jeeb.fiveforty.jp/x264/1171/x264.exe) ; release notes (http://jeeb.fiveforty.jp/x264/1171/relnotes.txt)

built on Jun 23 2009, gcc: 4.3.3
fprofiled, -march=i686


x264 r1171 64bit
download (http://jeeb.fiveforty.jp/x264/1171_x64/x264.exe) ; release notes (http://jeeb.fiveforty.jp/x264/1171_x64/relnotes.txt)

built on Jun 23 2009, gcc: 4.3.4 20090220 (prerelease) (x64.generic.Komisar)
fprofiled, -march=core2


Both patched with:

x264_win_zone_parse_fix_05.diff
x264_hrd_pulldown.13_interlace.diff


x264 r1171 AutoVAQ patched:

32bit (http://jeeb.fiveforty.jp/x264/1171avaq/x264.exe)
64bit (http://jeeb.fiveforty.jp/x264/1171avaq_x64/x264.exe)

(Built otherwise with the same patches, settings and compilers. x264_AutoVAQ.02.mod.diff version of the AutoVAQ patch used.)

[kemuri-_9]

personally, I'm tired of seeing people make two builds for std / 'Auto' VAQ...

modded patch to add 'AutoVAQ' as --aq-mode 2:
x264_AutoVAQ.02.mod.diff
(http://kemuri9.net/dev/x264/patches/x264_AutoVAQ.02.mod.diff)

[Dark Shikari]

personally, I'm tired of seeing people make two builds for std / 'Auto' VAQ...

modded patch to add 'AutoVAQ' as --aq-mode 2:
x264_AutoVAQ.02.mod.diff
(http://kemuri9.net/dev/x264/patches/x264_AutoVAQ.02.mod.diff)I agree, I left that in for a reason...

[JEEB]

Nice. I was getting -.-" of having two different builds as well, and I just didn't want to do any modifications on the code by myself.

Thanks and I guess I'll be using this patch from now. Re-uploaded the "AutoVAQ" enabled binaries so that they have the x264_AutoVAQ.02.mod.diff patch used, and - should there be no problems with the patch - I'll just switch into making one build with all of the patches :3

[burfadel]

Autovaq is a good idea, its algorithm just needs to be adjusted to reflect the filesize of the current VAQ in CRF mode, NOT to reflect the situation where VAQ is disabled!!! It plainly says in the sourcecode, that its tuned to do that, and it shouldn't take too long or be too hard for someone who knows what they are doing to modify it so people don't have to lower their CRF compared to VAQ.

[juGGaKNot]

personally, I'm tired of seeing people make two builds for std / 'Auto' VAQ...

modded patch to add 'AutoVAQ' as --aq-mode 2:
x264_AutoVAQ.02.mod.diff
(http://kemuri9.net/dev/x264/patches/x264_AutoVAQ.02.mod.diff)

Just what i need for testing, a build please ?

[J_Darnley]

juGGaKNot: see JEEB's post.
kemuri-_9: thanks, I should try it at long last.

[juGGaKNot]

Ahh i see, confused by the fact he also built a non autovaq mod version

thnx, one less mb in the bin, aq-mode 2 for autovaq right ?

btw where did aq-sensitivity go ?

[komisar]

juGGaKNot, in AutoVAQ patch no aq-sensitivity. Only aq-strength. aq-sensitivity present in early version of VAQmod patch. Latest version x264_vaqmod.07.r1089.diff (http://komisar.gin.by/x.patch/BugMaster/20090126/independent/x264_vaqmod.07.r1089.diff).

[techouse]

personally, I'm tired of seeing people make two builds for std / 'Auto' VAQ...

modded patch to add 'AutoVAQ' as --aq-mode 2:
x264_AutoVAQ.02.mod.diff
(http://kemuri9.net/dev/x264/patches/x264_AutoVAQ.02.mod.diff)
:thanks:

[MasterNobody]

personally, I'm tired of seeing people make two builds for std / 'Auto' VAQ...

modded patch to add 'AutoVAQ' as --aq-mode 2:
x264_AutoVAQ.02.mod.diff
(http://kemuri9.net/dev/x264/patches/x264_AutoVAQ.02.mod.diff)
Thanks. Patch is OK, but I prefer little clean up: x264_AutoVAQ.03.diff (http://stashbox.org/549826/x264_AutoVAQ.03.diff).

[techouse]

x264_x64_r1171_unpatched (http://techouse.project357.com/builds/revision1171/x264.exe) | MD5 (http://techouse.project357.com/builds/revision1171/x264.md5)
GCC 4.4.0 20090524 (x64.core2.Komisar), unpatched, generic, fprofiled

________________________________________________________________________________

x264_x86_r1171_techouse (http://techouse.project357.com/builds/x264_x86_r1171_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x86_r1171_techouse.txt)
GCC 4.4.0 20090524 (x86.core2.Komisar), fprofiled, -march=core2

x264_x64_r1171_techouse (http://techouse.project357.com/builds/x264_x64_r1171_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x64_r1171_techouse.txt)
GCC 4.4.0 20090524 (x64.core2.Komisar), fprofiled, -march=core2

Patches used:

x264_hrd_pulldown.13_interlace.diff
x264_win_zone_parse_fix_05.diff
x264_AutoVAQ.03.diff

[juGGaKNot]

Building....

Waiting..... ( have to read a guide about compiling some day )

But i guess 02 is the same just not as clean.

@komisar so the latest VAQmod patch does not have sensitivity, better this way ?

BTW how does vaq affect the output ? better dark zones only ? i just watched a movie encoded with r736M with no psyRD but aq 0.5 and sensitivity 13 that looks very very sharp, autovaq with default 1.0 is causing problems in dark places on my source.

Writing library : x264 core 58 svn-736M
Encoding settings : cabac=1 / ref=3 / deblock=0:0:0 / analyse=0x3:0x133 / me=esa / subme=6 / me-prepass=0 / brdo=1 / mixed_ref=1 / me_range=27 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / chroma_qp_offset=0 / threads=3 / nr=0 / decimate=1 / mbaff=0 / bframes=16 / b_pyramid=1 / b_adapt=1 / b_bias=1 / direct=2 / wpredb=1 / bime=1 / keyint=250 / keyint_min=25 / scenecut=40(pre) / rc=2pass / bitrate=4400 / ratetol=2.0 / rceq='blurCplx^(1-qComp)' / qcomp=1.00 / qpmin=1 / qpmax=40 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / pb_ratio=1.30 / aq=1:0.5:13.0

[techouse]

Waiting..... ( have to read a guide about compiling some day )

But i guess 02 is the same just not as clean.

@komisar so the latest VAQmod patch does not have sensitivity, better this way ?

BTW how does vaq affect the output ? better dark zones only ? i just watched a movie encoded with ~r800 with no psyRD but aq 0.5 and sensitivity 13 that looks very very sharp, autovaq with default 1.0 is causing problems in dark places on my source.Built. I edited the post above to avoid double posting.

[juGGaKNot]

Built. I edited the post above to avoid double posting.

Better edit this one also.

thnx, testing.


@komisar so the latest VAQmod patch does not have sensitivity, better this way ?

BTW how does vaq affect the output ? better dark zones only ? i just watched a movie encoded with r736M with no psyRD but aq 0.5 and sensitivity 13 that looks very very sharp, autovaq with default 1.0 is causing problems in dark places on my source.

[komisar]

juGGaKNot, x264_AutoVAQ.03.diff not same as x264_vaqmod.07.r1089.diff.
In x264_vaqmod.07.r1089.diff sensitivity enter manually.
In x264_AutoVAQ.03.diff sensitivity calculate automaticaly.

[juGGaKNot]

juGGaKNot, x264_AutoVAQ.03.diff not same as x264_vaqmod.07.r1089.diff.
In x264_vaqmod.07.r1089.diff sensitivity enter manually.
In x264_AutoVAQ.03.diff sensitivity calculate automaticaly.

A patch with both and aq-mode 1 = vaqmod.07 / aq-mode 2 = AutoVAQ.03 is possible ?

calculate automatically is best or near the default 13 ?

[MasterNobody]

A patch with both and aq-mode 1 = vaqmod.07 / aq-mode 2 = AutoVAQ.03 is possible ?
Of course it is possible (here is patch x264_AutoVAQmod.03.diff (http://stashbox.org/549958/x264_AutoVAQmod.03.diff) with --aq-sensitivity from VAQmod but without --aq-metric) but probably nobody is interested in it now.

[juGGaKNot]

Of course it is possible (here is patch x264_AutoVAQmod.03.diff (http://stashbox.org/549958/x264_AutoVAQmod.03.diff) with --aq-sensitivity from VAQmod but without --aq-metric) but probably nobody is interested in it now.

I guess so, i will check out a compilation guide and use the normal one until then.

thnx, cheers.

One more question :

BTW how does vaq affect the output ? better dark zones only ? i just watched a movie encoded with r736M with no psyRD but aq 0.5 and sensitivity 13 that looks very very sharp, autovaq with default 1.0 is causing problems in dark places on my source.

[Dark Shikari]

I guess so, i will check out a compilation guide and use the normal one until then.

thnx, cheers.

One more question :

BTW how does vaq affect the output ? better dark zones only ? i just watched a movie encoded with r736M with no psyRD but aq 0.5 and sensitivity 13 that looks very very sharp, autovaq with default 1.0 is causing problems in dark places on my source.AutoVAQ is like the old "mode 1" of VAQ; it adapts per-frame to avoid VAQ affecting ratecontrol.

This may not be entirely a good thing, as it means that the powerful bias that VAQ adds to dark frames is no longer there.

[Fr4nz]

New Imk x264 "ICC compiled" 1171 version (for x86/x64) here:

http://imk.cx/pc/x264/x264-r1171M-imk-win.7z

[G_M_C]

New Imk x264 "ICC compiled" 1171 version (for x86/x64) here:

http://imk.cx/pc/x264/x264-r1171M-imk-win.7z

:thanks:

[JEEB]

x264 r1173 32bit
download (http://jeeb.fiveforty.jp/x264/1173/x264.exe) ; release notes (http://jeeb.fiveforty.jp/x264/1173/relnotes.txt)

built on Jun 26 2009, gcc: 4.3.3
fprofiled, -march=i686


x264 r1173 64bit
download (http://jeeb.fiveforty.jp/x264/1173_x64/x264.exe) ; release notes (http://jeeb.fiveforty.jp/x264/1173_x64/relnotes.txt)

built on Jun 26 2009, gcc: 4.3.4 20090220 (prerelease) (x64.generic.Komisar)
fprofiled, -march=core2


Both patched with:

x264_win_zone_parse_fix_05.diff
x264_hrd_pulldown.13_interlace.diff
x264_AutoVAQ.03.diff


(the AutoVAQ patch version 3 only adds the 'AutoVAQ' behavior when --aq-mode is set to '2'. Therefore it should not change default behavior, which makes the point moot to build two separate builds. Life just got easier.)

[techouse]

x264_x64_r1173_unpatched (http://techouse.project357.com/builds/revision1173/x264.exe) | MD5 (http://techouse.project357.com/builds/revision1173/x264.md5)
GCC 4.4.0 20090524 (x64.core2.Komisar), unpatched, generic, fprofiled

________________________________________________________________________________

x264_x86_r1173_techouse (http://techouse.project357.com/builds/x264_x86_r1173_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x86_r1173_techouse.txt)
GCC 4.4.0 20090524 (x86.core2.Komisar), fprofiled, -march=core2

x264_x64_r1173_techouse (http://techouse.project357.com/builds/x264_x64_r1173_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x64_r1173_techouse.txt)
GCC 4.4.0 20090524 (x64.core2.Komisar), fprofiled, -march=core2

Patches used:

x264_hrd_pulldown.13_interlace.diff
x264_win_zone_parse_fix_05.diff
x264_AutoVAQ.03.diff

[juGGaKNot]

Build request whenever anyone has the time :

Patches needed :

x264_hrd_pulldown.13_interlace.diff
x264_win_zone_parse_fix_05.diff
x264_open_gop_hrd.2.diff
x264_AutoVAQ.03.diff

THNX in advance.

[Sharktooth]

opengop patch is not yet ready...

[juGGaKNot]

opengop patch is not yet ready...

Not functional or messy ?

[Sharktooth]

have you read the thread?

[Fr4nz]

New Imk x264 "ICC compiled" 1173 version (for Intel x86/x64) here:

http://imk.cx/pc/x264/x264-r1173M-imk-win.7z