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

[Ranguvar]

ahhh....

[Soichiro]

Excited about the b-adapt 2 speedboost!

Still would like some working multithreading up in there. :(

[Dark Shikari]

Still would like some working multithreading up in there. :(What's the problem? Works fine here...

[kemuri-_9]

What's the problem? Works fine here...

maybe whining that it's not as fast as b-adapt 1?

[Sharktooth]

Still would like some working multithreading up in there. :(
just use a sane number of b-frames.

[Soichiro]

Of course it's all my fault if it's being slow. Of course I'm just whining and being stupid. -_-;

I am using a sane number of b-frames. It's set to 6. And while it's better than before, it still doesn't use all of both cores with --b-adapt 2, which is something ideally I would like to see fixed. It's not too crippling on a dual core (though 70% CPU usage isn't something to be happy about either), but I imagine the new method would cause much more of a slowdown on a 4+ core system.

[Sharktooth]

6 is not sane... 3 (or 4 maybe) is...
and as Dark_Shikari said, even 2 with b-adapt 2 will look better then 16 with b-adapt 1.

[Soichiro]

Well my tests show that 6 is a good balance between speed and quality for animated material. Almost all my anime encodes have shown large (10%+) b-frame usage in up to 6-frame sequences, while beyond 6 frames is below 1%. I would call that "sane".

[Sharktooth]

not with b-adapt 2... using 6 b-frames will kill the encoding speed, so it's not a good balance.
use 3 b-frames with b-adapt 2. also for animes, maybe you better stick with b-adapt 1 and 6 or more b-frames.

[Soichiro]

Has b-adapt 2 shown bad results on anime? o.O

[Dark Shikari]

Has b-adapt 2 shown bad results on anime? o.ONo, I haven't done much testing on anime.

The question is whether you lose more from the lower --bframes than you gain from b-adapt 2, and I highly doubt that is the case.

[Sharktooth]

no, but since anime encodings will be happy with more b-frames, b-adapt 1 is faster and probably will be not much different than b-adapt 2 with less b-frames.

[Dark Shikari]

no, but since anime encodings will be happy with more b-frames, b-adapt 1 is faster and probably will be not much different than b-adapt 2 with less b-frames.We don't know this for sure :p Some testing will have to be done.

I have some anime clips that benefit tremendously from b-adapt 2. Though it might be because they're full of fades.

[Soichiro]

Ah, that makes sense, then. So I should keep using the old method until the new method is more optimized/properly multithreaded, then (unless I have extra time to kill :p).

Thank you. ;D

[Quark.Fusion]

AFAIK --b-adapt 2 can't be multithreaded as it relies on it's previous result (correct me if I'm wrong). Get process explorer and see how much cpu b-adapt thread uses, if it's greatly lesser that 100%/(num of cores) — try thread-pool patch.

[kemuri-_9]

working on some b-adapt comparisons
http://forum.doom9.org/showthread.php?p=1184814#post1184814

[skystrife]

x264.979.modified.exe (http://www.mediafire.com/?rzixxtfxxqc) - Alternate Download (http://skystrife.com/x264/x264.979.modified.exe)

Patches used:

x264_hrd_pulldown.09_interlace.diff

gcc 3.4.5 fprofiled build with -march=pentium2.

[Sharktooth]

tnx skystrife :)

[gav1577]

x264.979.modified.exe (http://www.mediafire.com/?rzixxtfxxqc) - Alternate Download (http://skystrife.com/x264/x264.979.modified.exe)

Patches used:

x264_hrd_pulldown.09_interlace.diff

gcc 3.4.5 fprofiled build with -march=pentium2.

Thanks :)

[fields_g]

If the next 21 builds come as quickly as the last 21, we will be at r1000 in 2 weeks...... wow....

It's not the quantity changes, but the QUALITY of the changes that impress me though! Thanks Devs!!

[burfadel]

Just wondering whether anyone has done tests adjusting the b-frame bias with --b-adapt 2? would be interesting to see the outcome of such tests. A different bias may be beneficial for anime, or resolve those having issues with psy trellis? (thats a question not a statement)!

[Ranguvar]

Sorry for the wait. Busy with encode tests.

Home (http://sites.google.com/site/ranguvar13/x264-builds)
Direct download (http://sites.google.com/site/ranguvar13/x264-builds/rang_x264_r0979.7z?attredirects=0), Mirrors (http://www.rapidspread.com/file.jsp?id=vjhzyxcku8)

x264 r979 from Git (patched, fprofiled).
Thanks to the x264 devs, including those who made the patches I use.
Compiled by Ranguvar on September 18th, 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 it
(May not work in AviDemux. Get those DLLs 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, in the order applied (included, unchanged, in the patches folder):

patch -p1 -i ../x264diffs/rang_x264_version.diff
patch -p1 -i ../x264diffs/x264_dll_alignment_fix.01.diff
patch -p1 -i ../x264diffs/x264_hrd_pulldown.09_interlace.diff
patch -p0 -i ../x264diffs/x264_fp-eta.01.r680.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

[Ranguvar]

WARNING: --bime b0rked in all revisions since and including r980, including this build. Don't use.

Home (http://sites.google.com/site/ranguvar13/x264-builds)
Direct download (http://sites.google.com/site/ranguvar13/x264-builds/rang_x264_r0982.7z?attredirects=0), Mirrors (http://www.rapidspread.com/file.jsp?id=jdfnjy3qms)

x264 r982 from Git (patched, fprofiled).
Thanks to the x264 devs, including those who made the patches I use.
Compiled by Ranguvar on September 20th, 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 it
(May not work in AviDemux. Get those DLLs 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, in the order applied (included, unchanged, in the patches folder):

patch -p1 -i ../x264diffs/rang_x264_version.diff
patch -p1 -i ../x264diffs/x264_dll_alignment_fix.01.diff
patch -p1 -i ../x264diffs/x264_hrd_pulldown.09_interlace.diff
patch -p0 -i ../x264diffs/x264_fp-eta.01.r680.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

[gigah72]

under which catergory do the last 3 patches fall (since 979), e.g. stability-, general-, internal-, bug- or ??-fix?
i ask, 'coz i notice a decrease of ~15% in encodingspeed with my usual testfiles?


EDIT:
the problem was in my setup, sorry, speed is OK.

[Warpman]

under which catergory do the last 3 patches fall (since 979), e.g. stability-, general-, internal-, bug- or ??-fix?
i ask, 'coz i notice a decrease of ~15% in encodingspeed with my usual testfiles?

The last 3 commits were mostly bugfixes I don't expect any big performence gain or loss.

[skystrife]

x264.983.modified.exe (http://www.mediafire.com/?jmwztuy5kbi) - Alternate Download (http://skystrife.com/x264/x264.983.modified.exe)

Patches used:

x264_hrd_pulldown.09_interlace.diff

gcc 3.4.5 fprofiled build with -march=pentium2.

Apologies for the recent absence--cleaning out the water loop was worth it though.

[Ranguvar]

Home (http://sites.google.com/site/ranguvar13/x264-builds)
Direct Download (http://sites.google.com/site/ranguvar13/x264-builds/rang_x264_r0983.7z?attredirects=0), Mirrors (http://www.rapidspread.com/file.jsp?id=zehc3cjzv8)

x264 r983 from Git (patched, fprofiled).
Thanks to the x264 devs, including those who made the patches I use.
Compiled by Ranguvar on September 20th, 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 it
(May not work in AviDemux. Get those DLLs 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, in the order applied (included, unchanged, in the patches folder):

patch -p1 -i ../x264diffs/rang_x264_version.diff
patch -p1 -i ../x264diffs/x264_dll_alignment_fix.01.diff
patch -p1 -i ../x264diffs/x264_hrd_pulldown.09_interlace.diff
patch -p0 -i ../x264diffs/x264_fp-eta.01.r680.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.985.modified.exe (http://www.mediafire.com/?yjuhyfzzykm) - Alternate Download (http://skystrife.com/x264/x264.985.modified.exe)

Patches used:

x264_hrd_pulldown.09_interlace.diff

gcc 3.4.5 fprofiled build with -march=pentium2.

[Romario]

Why you not use GCC 4.3.2, it's mush better then too old 3.4.5 ?

[Sagekilla]

Just saw r984 hit git, how much of a speedup can we expect from this?

[Dark Shikari]

Just saw r984 hit git, how much of a speedup can we expect from this?Depends on settings, since it speeds up hpel, and hpel is run a constant number of times regardless of settings (so slower settings == less speedup).

I think the speedup should be about 0-1% depending on settings. There's more coming afterwards; I'm going to be merging holger's intra pred and a few other things.

[Sagekilla]

Any speedup is good to hear. On that note, was this the one GSOC project that was "successful," besides the B frame patch you did yourself?

[Dark Shikari]

Any speedup is good to hear. On that note, was this the one GSOC project that was "successful," besides the B frame patch you did yourself?Yes. After this set of patches will come the merging of the other main successful patch.

[skystrife]

x264.986.modified.exe (http://www.mediafire.com/?tb2wv3r2nhm) - Alternate Download (http://skystrife.com/x264/x264.986.modified.exe)

Patches used:

x264_hrd_pulldown.09_interlace.diff

gcc 3.4.5 fprofiled build with -march=pentium2.

[Audionut]

I got problems trying to get the version info.

mingw32 says "./version.sh: git-rev-list: command not found"

msysgit says "./version.sh: line 5: join: command not found"

[Dark Shikari]

I got problems trying to get the version info.

mingw32 says "./version.sh: git-rev-list: command not found"

msysgit says "./version.sh: line 5: join: command not found"The current script doesn't work with the latest version of git because the command names were changed from "git-$command" to "git $command", I think.

[LoRd_MuldeR]

I got problems trying to get the version info.

mingw32 says "./version.sh: git-rev-list: command not found"

msysgit says "./version.sh: line 5: join: command not found"

You must add the Git "bin" folder to your PATH variable. Then the first warning will be gone :)

I do it this way:
export PATH=$PATH:"/c/Program Files (x86)/Git/bin"

EDIT: I currently use Git version 1.5.6.1.1071.g76fb and I get the "join: command not found" warning too (but this seems to be no problem).

[foxyshadis]

Machinae Supremacy talk moved (https://forum.doom9.org/showthread.php?t=141346).

[Audionut]

Thanks guys.

[Lux Delux]

I'm using megui with the latest skystrife build, just now I noticed (in just 1 scene for now) a strange blocking in an area

http://img217.imageshack.us/img217/1049/snapshot20080922004609uq2.jpg (http://imageshack.us)

below is the 1st and 2nd pass settings


Job commandline: "C:\Program Files (x86)\megui\tools\x264\x264.exe" --pass 1 --bitrate 1137 --stats "D:\WALKER S1\01\udegrain2.stats"
--ref 16 --mixed-refs --no-fast-pskip --bframes 6
--b-adapt 2 --b-pyramid --b-rdo --bime --weightb --direct auto --filter -1:-1 --subme 7 --trellis 2 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct
--me tesa --merange 32 --threads auto --thread-input --sar 59:65 --progress --no-dct-decimate --no-psnr --no-ssim --output NUL "D:\WALKER S1\01\udegrain2.avs"

Job commandline: "C:\Program Files (x86)\megui\tools\x264\x264.exe" --pass 2 --bitrate 1137 --stats "D:\WALKER S1\01\udegrain2.stats"
--ref 16 --mixed-refs --no-fast-pskip --bframes 6
--b-adapt 2 --b-pyramid --b-rdo --bime --weightb --direct auto --filter -1:-1 --subme 7 --trellis 2 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct
--me tesa --merange 32 --threads auto --thread-input --sar 59:65 --progress --no-dct-decimate --no-psnr --no-ssim --output "D:\WALKER S1\01\udegrain2.mkv" "D:\WALKER S1\01\udegrain2.avs"

[LoRd_MuldeR]

Lux Delux, it usually helps to upload a short sample of your source, which can be used to reproduce the problem...

[Audionut]

I had funky blocking problems like that when I forgot to change the output in mpc from system default.

Changing to haali or vmr9 fixed it.

[Lux Delux]

Yikes it seems it was the ffdshow build I was using, reverted to an older one had the output fine then.

Sorry for the false alarm :o

[LoRd_MuldeR]

Yikes it seems it was the ffdshow build I was using, reverted to an older one had the output fine then.

Sorry for the false alarm :o

You should report that in the ffdshow thread:
http://forum.doom9.org/showthread.php?t=120465&page=214

[Ranguvar]

NOTICE: I have switched back over to Arch GNU+Linux. Therefore, unless someone is willing to help me learn to cross-compile for Windows, I will either stop making builds, or may eventually put XP in a virtual machine and do it from there. :)

[gruntster]

EDIT: I currently use Git version 1.5.6.1.1071.g76fb and I get the "join: command not found" warning too (but this seems to be no problem).
Installing MSYS coreutils (http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=24963) should resolve this warning.

[Audionut]

Revision 987

Fix deblocking + threads + AQ bug

At low QPs, with threads and deblocking on, deblocking could be improperly disabled.
Revision in which this bug was introduced is unknown; it may be as old as b_variable_qp in x264 itself.


Trafficshare Download (http://rapidshare.com/files/147408536/x264-987.rar)


Compiled with gcc 3.4.5
./configure --enable-mp4-output --extra-cflags="-march=athlon -pipe"
fprofiled.

[skystrife]

x264.987.modified.exe (http://www.mediafire.com/?wozyejly3nz) - Alternate Download (http://skystrife.com/x264/x264.987.modified.exe)

Patches used:

x264_hrd_pulldown.09_interlace.diff

gcc 3.4.5 fprofiled build with -march=pentium2.

[bob0r]

x264.987.modified.01.exe (http://files.x264.nl/x264.987.modified.01.exe)
libx264-64.987.modified.01.dll (http://files.x264.nl/libx264-64.987.modified.01.dll)

x264_hrd_pulldown.09_interlace.diff

[komisar]

And my 987 builds also... :) (profiled, patched vaq-mod, unpatсhed as skyfire/bob0r, vfw, tuned)

http://komisar.gin.by/