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

[Trahald]

If we're free to post ideas here, I tried working on it but don't really have the experience to get it done. An option --encoder-fps would tune your options every so many frames to try to match fps to --encoder-fps value. Bframes would be lowered or raised, refs decreased or increased, etc. It would be very useful if performing faster than a certain speed is crucial. The only issues I'd foresee is that certain options (like bframes) probably can't be changed very easily in the middle of encoding.

bframes (the amount used in a GOP not the parameter per se) can change naturally based on the material. Changing that as a parameter mid-stream (from 3 to 0 for example) is trivial. other parameters require changing the sps/pps which is more significant but doable. Some encoders do this but usually based on changes in a section of the source, not to meet a speed requirement.
It would be interesting for the sake of better quality @ same bitrate. Doing it for encoding fps sake doesnt seem a good enough reason IMHO.

[Dark Shikari]

If we're free to post ideas here, I tried working on it but don't really have the experience to get it done. An option --encoder-fps would tune your options every so many frames to try to match fps to --encoder-fps value. Bframes would be lowered or raised, refs decreased or increased, etc. It would be very useful if performing faster than a certain speed is crucial. The only issues I'd foresee is that certain options (like bframes) probably can't be changed very easily in the middle of encoding.This patch already exists, and it's called speedcontrol. If you need it, contact Michael Kazmier at firstinitial lastname [AT] availmedia [DOT] com.

[JEEB]

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

built on Jul 17 2009, gcc: 4.3.3
fprofiled, -march=i686


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

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


patched with:

x264_win_zone_parse_fix_05.diff
x264_hrd_pulldown.13_interlace_modified.diff (http://jeeb.fiveforty.jp/x264/patches/x264_hrd_pulldown.13_interlace_modified.diff)
x264_AutoVAQ.03.diff

[imk]

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

OS X (x86 + x86-64 Universal Binary):
x264-r1183M-imk-osx.7z (http://imk.cx/pc/x264/x264-r1183M-imk-osx.7z)



I'm not going to include the AutoVAQ patch just yet. I might include the threaded slicetype patch if enough people use it or want it.

[techouse]

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

________________________________________________________________________________

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

x264_x64_r1184_techouse (http://techouse.project357.com/builds/x264_x64_r1184_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x64_r1184_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

[imk]

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

[JEEB]

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

built on Jul 21 2009, gcc: 4.3.4 20090220 (prerelease) (x32.generic.Komisar)
fprofiled, -march=i686


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

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


patched with:

x264_win_zone_parse_fix_05.diff
x264_hrd_pulldown.14_interlace.diff


One less patch to apply, the AutoVAQ is in.

EDIT:
Now used the 64bit VM Komisar build system to build both, the problems with the 32bit build should be over. I personally haven't edited my build environment in quite some time so I have no idea what caused the problems from r1179 onwards.

[Kurtnoise]

Jeeb: did you change something in the code except patches ? coz I tested this command : x264.exe -h w/ your build and it crashes...:confused: it works fine with --help or --longhelp though (OS: win 7 32bits). Note that I've no crashes w/ my own build (gcc 4.4.0) using the same command.

Does anyone confirm or not ?

[DarkZell666]

Jeeb: did you change something in the code except patches ? coz I tested this command : x264.exe -h w/ your build and it crashes...:confused: it works fine with --help or --longhelp though (OS: win 7 32bits). Note that I've no crashes w/ my own build (gcc 4.4.0) using the same command.

Does anyone confirm or not ?

Confirmed here on XP 32-bits.
x264 -h doesn't show anything, it just quits without any error/warning.
Edit : Imk's build is ok for me.

[LoRd_MuldeR]

x264 -h doesn't show anything, it just quits without any error/warning.

In fact it seems all the "short" switches will cause x264 to exit immediately ("-h", "-w", "-B", etc). The x64 build is not effected though...

[JEEB]

Very weird. My building script consists of rm -rf'ing all of the current build folders -> updating the git repo (using one folder that never gets used for building) -> copying to the needed folders -> configuration and building. No additional patches were applied and the 32bit version gets even a standard ./configure because x264 by default optimizes for i686 IIRC.

I remember using the short commands myself earlier, so I will definitely have to take a look at it as I get home. :scared: And patching logs seemed to be all right.

Also, the 64bit build being not affected makes me think even more...

Too bad I don't have the msys environment on my hands via remote desktop :/

Possible culprits:
- my toolchain (hasn't been updated in a while though, so if it actually worked on the older builds...)
- that modified HRD patch (that has been there for some time as well; hurf, I was worried something might happen, because it was my first case, but let's see as the change was quite small...)
- getting updated code from the git repo went not-so-well?
- something else?

Will test some older binaries via wine on my laptop now.

EDIT:


r1184-83-81-79 32bit:
err:seh:setup_exception_record stack overflow 820 bytes in thread 0009 eip b7d269be esp 00520ffc stack 0x520000-0x521000-0x720000
r1173 32bit:
Works


Hurf, I think you can guess the reason and I will go cry myself to sleep with my patch that I made by applying it manually to the codebase and then doing diff magic. Will switch to the 1178 version by komisar and go hang myself ^^;

Although why the hell does it work on 64bit D:

EDIT2:

wtf, it even happens without any patches, I guess my build environment got changed somehow o_O I haven't touched it for months. Anyways, fun stuff.

EDIT3: Re-built the build with Trahald's v14 hrd pulldown patch on Komisar's msys/mingw - problems fixed, which is the main part - now to know why on Earth it failed on my 32bit building environment...

[Trahald]

No really big changes. Just code clean up. The 3 length values in the code were at maxes, which works but wastes bits, were lowered to reflect options given. I ran a few encodes at it and the calcs make sense to me, but be ready to revert if there is an issue.

[Tarutaru]

x264 0.68.1185M 2956905 built on Jul 23 2009, gcc: 4.4.0 (http://www.mediafire.com/?qdm2yzi2tyt)

* patch -p1 < /local/build/x264/patch/x264_hrd_pulldown.14_interlace.diff
* patch -p1 < /local/build/x264/patch/x264_win_zone_parse_fix_05.diff
* fprofiled, -msse4.2, -march=native(core i7)
* built with pthread, gpac

[kemuri-_9]

since this thread is also used for discussion and usage of patched builds, tossing the following out...

in addition to the release of gcc 4.4.1 as of a couple days ago, the mingw team has also revealed an official 4.4.0 release (which unlike 4.3.0 isn't stated as alpha/testing).
so those still using 3.4.5 should definitely upgrade...

[LoRd_MuldeR]

Is there a MinGW 4.4.1 binary yet? It seems TDM's builds have not been updated until now...

[kemuri-_9]

Is there a MinGW 4.4.1 binary yet? It seems TDM's builds have not been updated until now...

you always have the option to compile your own from source (like what i do)

[LoRd_MuldeR]

you always have the option to compile your own from source (like what i do)

Too much trouble :D

And I prefer using some "semi official" MinGW/GCC build, because it's more tested by the community.

[Selur]

I agree, tdm's builds are nice&handy :)
(btw. is there something similiar when aiming for 64bit builds?)

[LoRd_MuldeR]

People seem to use Komisar's MinGW x64 builds:
http://komisar.gin.by/mingw/index.html

[komisar]

My last stable build of gcc -- 4.3.4 20090620.
After 20090620 my trying to build correct gcc and x264 fail.
gcc 4.5.0 (svn) totally unstable (imho).
4.4.1 i can try to build after weekend.

[kemuri-_9]

i used my compiles of gcc 4.4.1 to compile both x86 and x64 versions of x264 and it works fine.

compiling from the svn can be a dual edged sword - bugs are likely to appear as other ones are fixed,
this is why i only use official releases now.
(plus it saves time from building from weekly snaps and such)

[Audionut]

Subme10

http://git.videolan.org/?p=x264.git;a=commit;h=7733721e410acb96fdf740ca95d2a394b2a2b713

[Tarutaru]

x264.0.68.1189M.x86.exe (http://www.mediafire.com/?15zyntynzvx)

* patch -p1 < x264_hrd_pulldown.14_interlace.diff
* patch -p1 < x264_win_zone_parse_fix_05.diff
* pthread, gpac
* fprofiled, -msse4.2, -march=native(core i7)

[JEEB]

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

built on Jul 26 2009, gcc: 4.3.4 20090220 (prerelease) (x32.generic.Komisar)
fprofiled, -march=i686


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

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


patched with:

x264_win_zone_parse_fix_05.diff
x264_hrd_pulldown.14_interlace.diff

[imk]

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

[bob0r]

Need someone who can compile x264 64bit fprofiled from GIT (no patches), gcc prefered.
Techouse seems very busy.

If you can provide this please host it on a http host (i can provide if needed):
http://yourhost.com/whatever/revisionXXXX/x264.exe
Like that.
Also include:
md5sum x264.exe | awk '{print $1}' >x264.md5
please, thats the file i use and check for updates.
( http://yourhost.com/whatever/revisionXXXX/x264.md5 )

If you can provide this please post for me x264.exe --version, so i can update x264.nl

Maybe JEEB? :)

[juGGaKNot]

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

built on Jul 26 2009, gcc: 4.3.4 20090220 (prerelease) (x32.generic.Komisar)
fprofiled, -march=i686


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

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


patched with:

x264_win_zone_parse_fix_05.diff
x264_hrd_pulldown.14_interlace.diff


Was autovaq commited or still diff ?

A subme 10 build with autovaq ?

[LoRd_MuldeR]

Was autovaq commited or still diff ?

Yes. Look at the GIT ;)

http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=88b35c2d3bd86b42059e27db365752da9f2cd032

A subme 10 build with autovaq ?

You don't need a "SubME 10" build. SubME=10 is available in all regular builds (r1187 and later). Note that it requires Trellis=2.

[juGGaKNot]

Yes. Look at the GIT ;)

http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=88b35c2d3bd86b42059e27db365752da9f2cd032



You don't need a "SubME 10" build. SubME=10 is available in all regular builds (r1187 and later). Note that it requires Trellis=2.

subme 10 + autovaq ( that is if autovaq was not commited )

anyway tested, guess this means death to deathzones.

will the --preset be edited so that subme 10 is on @ slower and placebo ?

[LoRd_MuldeR]

subme 10 + autovaq ( that is if autovaq was not commited )

That is what you get with "--aq-mode 2" + "--trellis 2" + "--subme 10" using a standard (unpatched) build.

will the --preset be edited so that subme 10 is on @ slower and placebo ?

The "slower" preset uses Trellis=2 + SubMe=9, but "placebo" already uses Trellis=2 + SubMe=10.

I wonder whether SubMe=10 really is a "placebo" setting? ;)

[juGGaKNot]

That is what you get with "--aq-mode 2" + "--trellis 2" + "--subme 10" using a standard (unpatched) build.

Well yes if its not a diff anymore :)

What does the zone parse fix do ? now that autovaq is in i can move to a unpatched build.

The "slower" preset uses Trellis=2 + SubMe=9, but "placebo" already uses Trellis=2 + SubMe=10.

I wonder whether SubMe=10 really is a "placebo" setting? ;)

We will see when subme 11 is out :) i'm going to use it.

Does that mean it's any louder? (http://www.youtube.com/watch?v=EbVKWCpNFhY)

I do not have amps :|

[Dark Shikari]

We will see when subme 11 is out :) i'm going to use it.Does that mean it's any louder? (http://www.youtube.com/watch?v=EbVKWCpNFhY)

[LoRd_MuldeR]

Well yes if its not a diff anymore :)

As said before, AutoVAQ is committed ;)

What does the zone parse fix do ? now that autovaq is in i can move to a unpatched build.

See this post:
http://forum.doom9.org/showpost.php?p=1308492&postcount=7

I do not have amps :|

You don't need to have an amp at home to understand the joke :D

[Selur]

now that autovaq is in i can move to a unpatched build.
not before hrd_pulldown_interlace get's stable and finds it way into the maintree ;)

[JEEB]

x264 r1190 64bit unpatched:
download (http://jeeb.fiveforty.jp/x264/revision1190/x264.exe) ; hash (http://jeeb.fiveforty.jp/x264/revision1190/x264.md5)
________________________________________________________________________________

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

built on Jul 28 2009, gcc: 4.3.4 20090220 (prerelease) (x32.generic.Komisar)
fprofiled, -march=i686


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

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


patched with:

x264_win_zone_parse_fix_05.diff
x264_hrd_pulldown.15_interlace.diff

[XhmikosR]

Using JEEB's builds, r1190, r1189 and r1184 I get the following when x264 crashes:

avis [info]: 1280x720 @ 23.98 fps (1442 frames)
Assertion failed: dpb_output_delay < pow( 2, sps->vui.nal_hrd_parameters.i_dpb_o
utput_delay_length ), file encoder/set.c, line 643

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

cmd used:
x264 --profile high --slow-firstpass --pass 1 --quiet --bitrate 5000 --stats "1.stats" --level 4.1 --keyint 24 --min-keyint 1 --ref 1 --no-mixed-refs --bframes 3 --no-weightb --direct auto --chroma-qp-offset 0 --subme 1 --trellis 0 --analyse none --no-8x8dct --ipratio 1.1 --pbratio 1.1 --vbv-bufsize 50000 --vbv-maxrate 50000 --qcomp 0.5 --me dia --threads auto --thread-input --sar 1:1 --output NUL "test.avs" --mvrange 511 --aud --nal-hrd

If I use imk's build r1190 everything is fine.

[Dark Shikari]

If I use imk's build r1190 everything is fine.Note where it terminates. It's a bug in the nal-hrd patch.

[XhmikosR]

Yes, but the odd thing is that the same script, same cmd, same patches used, all the same, only the compiler is different, with imk's build I get no crashes. Anyway, I didn't know where else to report it. I hope it gets fixed. :)

[Trahald]

thats why i put the assert in there ;) rather the encoder die than a decoder down the line. (because w/out the assert the encode would have completed). will have a patch out shortly.

[Trahald]

Hrd 15.

[JEEB]

1190 builds rebuilt, re-uploaded (all but the unmodified one, which had no patches, so (ry)

[Dark Shikari]

1190 builds rebuilt, re-uploaded (all but the unmodified one, which had no patches, so (ry)Sorry, but your efforts were in vain! (http://git.videolan.org/?p=x264.git;a=commit;h=306c3ee4b1c3cae804185597305725d2484f21b9) :cool:

[MythCreator]

x264 rev.1192 unpatched x86
download (http://www.rayfile.com/files/55c7cc57-7b71-11de-832c-0019d11a795f/)

built on Jul 28 2009, gcc: 4.4.0 (release) (TDM-GCC)

fprofiled

[juGGaKNot]

What setting does the --tune fastdecode have ?

ahh nvm


+ else if( !strcasecmp( optarg, "fastdecode" ) )

+ {

+ param->b_deblocking_filter = 0;

+ param->b_cabac = 0;

+ param->analyse.b_weighted_bipred = 0;

+ }

x264 rev.1192 unpatched x86
download (http://www.rayfile.com/files/55c7cc57-7b71-11de-832c-0019d11a795f/)

built on Jul 28 2009, gcc: 4.4.0 (release) (TDM-GCC)

fprofiled

Try filefront/mediafire ?

hmm..I'll upload to FileFront

I found the download, well hidden!

[Audionut]

http://mailman.videolan.org/pipermail/x264-devel/2009-July/006096.html

+ else if( !strcasecmp( optarg, "fastdecode" ) )
+ {
+ param->b_deblocking_filter = 0;
+ param->b_cabac = 0;
+ param->analyse.b_weighted_bipred = 0;
+ }

[MythCreator]

Try filefront/mediafire ?

hmm..I'll upload to FileFront




x264 rev 1192 patched build

Download (http://www.filefront.com/14141557/x264-r1192-patched.exe)

built on Jul 28 2009, gcc: 4.4.0 (release) (TDM-GCC)

fprofiled

patched with:
x264_win_zone_parse_fix_05.diff
x264_hrd_pulldown.15_interlace.diff

[gator1102]

http://xeph.textcube.com/2/attach/x264.exe
x264 rev.1192 _ 32-bit binary with MP4 output

Intel C++ Compiler (icc) v11.1.038

Used patches:

x264_icc_03_win.diff
x264_win_zone_parse_fix_05.diff
x264_hrd_pulldown.15_interlace.diff
x264-r1183-threaded-slicetype-v17.diff

[techouse]

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

________________________________________________________________________________

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

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

Patches used:

x264_hrd_pulldown.15_interlace.diff
x264_win_zone_parse_fix_05.diff

[techouse]

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

________________________________________________________________________________

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

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

Patches used:

x264_hrd_pulldown.15_interlace.diff
x264_win_zone_parse_fix_05.diff

[JEEB]

x264 r1193 64bit unpatched:
download (http://jeeb.fiveforty.jp/x264/revision1193/x264.exe) ; hash (http://jeeb.fiveforty.jp/x264/revision1193/x264.md5)

built on Jul 28 2009, gcc: 4.3.4 20090220 (prerelease) (x64.generic.Komisar)
fprofiled, otherwise defaults

________________________________________________________________________________

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

built on Jul 28 2009, gcc: 4.3.4 20090220 (prerelease) (x32.generic.Komisar)
fprofiled, -march=i686


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

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


patched with:

x264_win_zone_parse_fix_05.diff
x264_hrd_pulldown.15_interlace.diff


My help is probably unneeded, but since this is what my building script outputs nowadays, I'll be using this base I guess ;)

[mopurist]

Hrd 15.

Sorry, maybe I misunderstand, but is this version supposed to fix the error described in post 2036?

I just recompiled x264 with this patch and I get the same failure. (Linux 64-bit, if it matters)

x264: encoder/set.c:644: x264_sei_picture_timing_write: Assertion `dpb_output_delay < pow( 2, sps->vui.nal_hrd_parameters.i_dpb_output_delay_length )' failed.

Thanks.

[Trahald]

whats your command line.

[imk]

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

[mopurist]

whats your command line.

When I run with the same options XhmikosR described, it does work. I hadn't updated x264 for several months, and now that I have, a script I used previously without issue dies with the assertion failed.

If I trim the command used by the script down as far as the following, the assertion still fails:
/usr/bin/wine /home/mopurist/.wine/drive_c/Program\ Files/avs2yuv.exe /home/mopurist/test.avs -raw - | x264 --bitrate 7000 --level 4.1 --nal-hrd --vbv-maxrate 50000 --vbv-bufsize 50000 --output test.264 - 1440x1080 --fps 29.970

The actual command the script uses is:
/usr/bin/wine "${avs2yuvdir}/avs2yuv.exe" "${workdir}/${1}.avs" -raw -| /usr/bin/x264 --b-adapt 2 --pass 1 --psy-rd 1.0:0.2 --aq-strength 1.3 --bitrate $2 --stats "${workdir}/${1}.stats" --level 4.1 --nal-hrd --ref 4 --mixed-refs --bframes 4 --b-pyramid --no-fast-pskip --weightb --me umh --direct auto --keyint 300 --min-keyint 30 --vbv-maxrate 62500 --vbv-bufsize 62500 --mvrange 511 --aud --subme 7 --trellis 2 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --threads auto --thread-input --deblock 0,1 --sar 4:3 --output "${twosixfourdir}/${1}_final.264" - 1440x1080 --fps 29.970

So, obviously I don't know what the assertion is testing, nor do I understand how it is determined or what the purpose of the change is, that now results in an assertion failed.

Any help in understanding and fixing the issue would be appreciated.

Thanks.

[ACoolie]

In a vanilla icc-compiled x264 r1193 build i get the following error around 300 frames into the second pass of an encode. CFLAGS and LDFLAGS are just "-openmp."
x264: encoder/analyse.c:1175: x264_mb_analyse_inter_p16x16: Assertion `a->l0.me16x16.mv[1] <= h->mb.mv_max_spel[1] || h->param.i_threads == 1' failed.
x264 -B 1264 -o 1.h264 -p2 --merange 24 --level 4.1 --fps 24000/1001 --sar 32/27 -b 12 -f -2,-2 --frames 52560 --psy-rd 1.3:0.15 --aq-strength 1.0 --aq-mode 2 --stats .stats - 708x348 --preset slower --no-fast-pskip --b-pyramid -m10
A gcc-compiled x264 works perfectly. If I set subme to 9 and use the icc build, it works as well.

[Dark Shikari]

.... I'm a complete idiot, it seems... adding more subme values and not increasing the size of the array... I'm shocked it worked at all.

Fix committed.

[Dark Shikari]

OK, now this is brilliant.

static const int subpel_iterations[][4] =
{{0,0,0,0},
{1,1,0,0},
{0,1,1,0},
{0,2,1,0},
{0,2,1,1},
{0,2,1,2},
{0,0,2,2},
{0,0,2,2},
{0,0,4,10},
{0,0,4,10}};

/* (x-1)%6 */
static const int mod6m1[8] = {5,0,1,2,3,4,5,0};

Accessing the array positions subpel_iterations[10][2] and subpel_iterations[10][3] gave "1,2", a reasonable enough hpel/qpel value, which resulted in me never noticing the problem.

Of course, on a compiler that didn't happen to arrange the data adjacently in memory...

[Trahald]

@mopurist
Hmm... i couldnt duplicate the issue, but i'll keep trying.

Except for wasting a few bits.. rev 13 of the patch is fine to use.

[techouse]

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

________________________________________________________________________________

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

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

Patches used:

x264_hrd_pulldown.15_interlace.diff
x264_win_zone_parse_fix_05.diff

[MythCreator]

x264_x86_r1195_MythCreator

Download (http://www.filefront.com/14148645/x264-r1195-patched.exe)

GCC 4.4.1 released (MythCreator build), fprofiled

Patches used:

x264_hrd_pulldown.15_interlace.diff
x264_win_zone_parse_fix_05.diff

[mopurist]

@mopurist
Hmm... i couldnt duplicate the issue, but i'll keep trying.

Except for wasting a few bits.. rev 13 of the patch is fine to use.

Thanks for taking a look.

Unfortunately, 13 doesn't apply cleanly to latest git (x264.c changes) and my work schedule will leave me only an hour or so each day to check it out.

I did notice that if I don't specify --fps (with version 15 of the patch) I don't get the assertion failure. But it assumes 25fps, which is incorrect, and seems to encode at about 1/4th the rate that I was previously getting with x264+hrd version 9 from several months ago.

[imk]

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

[Trahald]

@mopurist
http://forum.doom9.org/showthread.php?p=1306166#post1306166 <-the 13 in this post. it was modified by one of the other builders to patch post preset era x264.

[JEEB]

x264 r1195 64bit unpatched:
download (http://jeeb.fiveforty.jp/x264/revision1195/x264.exe) ; hash (http://jeeb.fiveforty.jp/x264/revision1195/x264.md5)

built on Jul 29 2009, gcc: 4.3.4 20090220 (prerelease) (x64.generic.Komisar)
fprofiled, otherwise defaults

________________________________________________________________________________

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

built on Jul 29 2009, gcc: 4.3.4 20090220 (prerelease) (x32.generic.Komisar)
fprofiled, -march=i686


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

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


patched with:

x264_win_zone_parse_fix_05.diff
x264_hrd_pulldown.15_interlace.diff

[moviefan]

I'm using Techouse's build r1195 and I'm still getting the same error "This application has requested the Runtime to terminate in an unusual way. Please contact the application's support team for more information." using subme 10. Something is seriously wrong... The last working revision for me was r1187 (I think).

[Dark Shikari]

I'm using Techouse's build r1195 and I'm still getting the same error "This application has requested the Runtime to terminate in an unusual way. Please contact the application's support team for more information." using subme 10. Something is seriously wrong... The last working revision for me was r1187 (I think).I can't do anything without a gdb backtrace, sorry.

[moviefan]

Do I need to compile x264 for performing the backtrace with gdb? I have never done this before... Or is it too difficult do it right away for the first time?

[kemuri-_9]

x264 w/ debug symbols (http://kemuri9.net/dev/x264/x264_debug.exe)
you can use this with mingw's gdb and provide a backtrace upon the crash (if it does still crash)

[moviefan]

OK, what's this? ".../gdb/dwarf2read.c:985: gdb-internal-error: read_comp_unit_head: dwarf from non elf file" "An internal GDB error was detected. This may make further debugging unreliable."

[kemuri-_9]

A. if you aren't already, be sure to be using mingw gdb 6.8-3
B. if you are, then post a sample that you can consistently crash with and the command line you're using to cause the crash.

[Dark Shikari]

Do I need to compile x264 for performing the backtrace with gdb? I have never done this before... Or is it too difficult do it right away for the first time?gdb --args ./x264_debug_build --all --your --normal --options

...

<it crashes>

bt

[LoRd_MuldeR]

OK, what's this? ".../gdb/dwarf2read.c:985: gdb-internal-error: read_comp_unit_head: dwarf from non elf file" "An internal GDB error was detected. This may make further debugging unreliable."

Maybe a problem with "SJLJ" -vs- "Dwarf-2" Unwinding?

[moviefan]

A. is the problem. I used the current gdb version of DevCpp which is old. Do I have to run x264 in the gdb environment with my current x264 settings? So is this like a normal encode only under supervision of gdb?

[LoRd_MuldeR]

A. is the problem. I used the current gdb version of DevCpp which is old. Do I have to run x264 in the gdb environment with my current x264 settings? So is this like a normal encode only under supervision of gdb?

Do it like proposed here:
http://forum.doom9.org/showpost.php?p=1309773&postcount=2071

BTW: You may need to type "run" or "c" to make the program start/resume until it crashes...

[moviefan]

Do it like proposed here:
http://forum.doom9.org/showpost.php?p=1309773&postcount=2071

Sorry, parallel posting :rolleyes:

I'll report back when results have arrived.

Edit: Sorry, it's strange... Now gdb says, "gdb: unrecognized option --threads"
Edit2: Oh, @DarkShikari: --args was meant literally... now it works, but I get massive output in the console. Does it terminate and show the error, when there is an abnormal termination? kemuri-_9's debug build does not include the --nal-hrd patch, so the situation is not identical to my crash situation.
Edit3: I got to go to bed, exam tomorrow, but I'll post the results in about 8 hours. Encoding is slow, duplicating the encoding situation (1 fps...), but it'll probably have crashed by tomorrow morning (if it crashes).

[LoRd_MuldeR]

Edit2: Oh, @DarkShikari: --args was meant literally... now it works, but I get massive output in the console. Does it terminate and show the error, when there is an abnormal termination? kemuri-_9's debug build does not include the --nal-hrd patch, so the situation is not identical to my crash situation.

Yes, Avisynth spams the gdb console with debugging messages ;)

But if x264 crashes, gdb will interrupt, show an error message and return to the propmpt. Then you can type "bt" to get a stacktrace, so we see where exactly it crashed.

If that doesn't happen, the crash simply doesn't occur with kemuri's debug build.

Edit3: I got to go to bed, exam tomorrow, but I'll post the results in about 8 hours.

Good luck !!!

[moviefan]

x264 crashed.

"Program received signal SIGSEGV, Segmentation fault. [Switchting to thread 2268.0x20c] 0x6fb775f6 in libavcodec!dspuitl_init () from ...\DGAVCDec\libavcodec.dll"

Hm, it seems, that x264 is OK and DGAVCDec is the problem, right? Strange, since I had done encodes with exactly the same .dga-file and exactly this DGAVCDec version.

Good luck !!!
Thanks, I hope it'll be good. Stochastic processes...:cool:

[LoRd_MuldeR]

When the "Segmentation fault" happens, type bt to get a Stacktrace and post the result back here...

[moviefan]

Hm, I did type bt at that point, but it didn't reveal any new information. There were some thread messages (or whatever they are) and the message about libavcodec. What should have been written there? In case, I missed something, I will repeat the backtrace.

[Dark Shikari]

Hm, I did type bt at that point, but it didn't reveal any new information. There were some thread messages (or whatever they are) and the message about libavcodec. What should have been written there? In case, I missed something, I will repeat the backtrace.You were able to backtrace but you can't paste the results here so we can read them? :rolleyes:

[moviefan]

Ehm, basically... yes ;-). OK... I will redo the tracing. I closed the terminal this morning, but the information were as I mentioned. I started another encode with imk's build using DirectShowSource of the same source this morning and up to now there have not been any errors. Do you definitely expect more information than I posted, so that I missed something? In that case I do the tracing again.

Edit: Actually, the DirectShowSource encode failed too, but for other, unknown reasons... I've just started the backtrace again.
Edit: OK, an error occurred again. I now paste exactly what is shown in the terminal:
This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information.
warning: Process detach: hModule = 0x10000000, gRefCnt = 2

Program exited with code 03.
(gdb) bt
No stack.

This message is different to the one from this morning. However, there is an error and I hope this helps with debugging.

Edit: The issue might have been caused by using SetMTMode(2) at the very beginning of the avs-script, especially before AVCSource/DirectShowSource. When I put it after source loading, the encodes seem to be stable. I have already encoded about 33000 frames and the crashes were always at a few 1000 frames.

[juGGaKNot]

I want to modify x264.c to make a custom profile

cmd now :

--profile high --preset placebo --tune animation --bitrate %btratex264% --stats %myx264stats% --level %mylevel% --fullrange on --no-fast-pskip --bframes 4 --psy-rd 1.0:00 --ipratio 1.1 --pbratio 1.1 --vbv-bufsize 20000 --vbv-maxrate 20000 --qcomp 1.0 --aq-mode 2 --aq-strength 1.0 --nal-hrd --sar 1:1 --aud --no-dct-decimate

cmd after

--profile high --preset juggaknot --bitrate %btratex264% --stats %myx264stats% --level %mylevel%

so i want to include all these settings

--fullrange on --no-fast-pskip --bframes 4 --psy-rd 1.0:00 --ipratio 1.1 --pbratio 1.1 --vbv-bufsize 20000 --vbv-maxrate 20000 --qcomp 1.0 --aq-mode 2 --aq-strength 1.0 --nal-hrd --sar 1:1 --aud --no-dct-decimate

in a preset, so far i got :

H0( " --preset Use a preset to select encoding settings [medium]\n" );
H0( " Overridden by user settings\n");
H1( " - ultrafast,veryfast,fast,medium\n"
" - slow,slower,placebo,juggaknot\n" );
else H0( " - ultrafast,veryfast,fast,medium,slow,slower,placebo\n" );

else if( !strcasecmp( optarg, "juggaknot" ) )
{
param->i_frame_reference > 1 ? param->i_frame_reference*2 : 1;
param->i_deblocking_filter_alphac0 = 1;
param->i_deblocking_filter_beta = 1;
param->analyse.f_psy_rd = 1.0;
param->rc.f_aq_strength = 1.0;
param->i_bframe = 4;
param->rc.f_qcompress = 1.0;

How can i add the rest of the cvars ? can i add all of them ?

[J_Darnley]

You can discover the variable names by looking at common/common.c and the function x264_param_parse then add them to your preset. You don't have to add your preset name to the help if it is for your use.

[LoRd_MuldeR]

juGGaKNot, try this:

else if( !strcasecmp( optarg, "juggaknot" ) )
{
param->analyse.i_me_method = X264_ME_TESA;
param->analyse.i_subpel_refine = 10;
param->analyse.i_me_range = 24;
param->i_frame_reference = 16;
param->i_bframe_adaptive = X264_B_ADAPT_TRELLIS;
param->analyse.i_direct_mv_pred = X264_DIRECT_PRED_AUTO;
param->analyse.inter |= X264_ANALYSE_PSUB8x8;
param->analyse.b_fast_pskip = 0; // --no-fast-pskip
param->analyse.i_trellis = 2;
param->i_bframe = 16; // --bframes 4
param->rc.f_qcompress = 1.0f // --qcomp 1.0
param->rc.i_vbv_max_bitrate = 20000; // --vbv-maxrate 20000
param->rc.i_vbv_buffer_size = 20000; // --vbv-bufsize 20000
param->rc.b_aud = 1; // --aud
param->b_dct_decimate = 0; // --no-dct-decimate
param->vui.b_fullrange = 1; // --fullrange on
param->analyse.f_psy_rd = 1.0f; // --psy-rd 1.0:00
param->analyse.f_psy_trellis = 0.0f; // --psy-rd 1.0:00
param->rc.i_aq_mode = X264_AQ_AUTOVARIANCE; // --aq-mode 2
param->rc.f_aq_strength = 1.0f; // --aq-strength 1.0
param->rc.f_ip_factor = 1.1f; // --ipratio 1.1
param->rc.f_pb_factor = 1.1f; // --pbratio 1.1
param->vui.i_sar_height = 1; //--sar 1:1
param->vui.i_sar_width = 1; //--sar 1:1
param->b_nal_hrd = 1; // --nal-hrd
}

Diff: http://pastie.org/568166

Note that some lines are superfluous, as they simply represent the default. But I included them anyway, just for completeness ;)

[juGGaKNot]

You can discover the variable names by looking at common/common.c and the function x264_param_parse then add them to your preset. You don't have to add your preset name to the help if it is for your use.

thnx, it is for use in my exe thingy.

juGGaKNot, try this:

thnx.

LE

error on the diff

***************
*** 593,598 ****
param->analyse.i_trellis = 2;
param->i_bframe = 16;
}
else
{
fprintf( stderr, "x264 [error]: invalid preset: %s\n", optarg );
--- 593,626 ----
param->analyse.i_trellis = 2;
param->i_bframe = 16;
}
+ else if( !strcasecmp( optarg, "juggaknot" ) )
+ {
+ param->analyse.i_me_method = X264_ME_TESA;
+ param->analyse.i_subpel_refine = 10;
+ param->analyse.i_me_range = 24;
+ param->i_frame_reference = 16;
+ param->i_bframe_adaptive = X264_B_ADAPT_TRELLIS;
+ param->analyse.i_direct_mv_pred = X264_DIRECT_PRED_AUTO;
+ param->analyse.inter |= X264_ANALYSE_PSUB8x8;
+ param->analyse.b_fast_pskip = 0; // --no-fast-pskip
+ param->analyse.i_trellis = 2;
+ param->i_bframe = 16; // --bframes 4
+ param->rc.f_qcompress = 1.0f // --qcomp 1.0
+ param->rc.i_vbv_max_bitrate = 20000; // --vbv-maxrate 20000
+ param->rc.i_vbv_buffer_size = 20000; // --vbv-bufsize 20000
+ param->rc.b_aud = 1; // --aud
+ param->b_dct_decimate = 0; // --no-dct-decimate
+ param->vui.b_fullrange = 1; // --fullrange on
+ param->analyse.f_psy_rd = 1.0f; // --psy-rd 1.0:00
+ param->analyse.f_psy_trellis = 0.0f; // --psy-rd 1.0:00
+ param->rc.i_aq_mode = X264_AQ_AUTOVARIANCE; // --aq-mode 2
+ param->rc.f_aq_strength = 1.0f; // --aq-strength 1.0
+ param->rc.f_ip_factor = 1.1f; // --ipratio 1.1
+ param->rc.f_pb_factor = 1.1f; // --pbratio 1.1
+ param->vui.i_sar_height = 1; //--sar 1:1
+ param->vui.i_sar_width = 1; //--sar 1:1
+ param->b_nal_hrd = 1; // --nal-hrd
+ }
else
{
fprintf( stderr, "x264 [error]: invalid preset: %s\n", optarg );

$ patch -p1 < /d/jugg.diff
patching file x264.c
Hunk #1 FAILED at 593.
1 out of 1 hunk FAILED -- saving rejects to file x264.c.rej

LE :

if i copy the code in x264.c ( replace placebo with juggaknot )

i get errors on aud

[jpsdr]

Hello.

I'm totaly new in h264.
I've try to encode videos in h264, and import
them in scenarist. After faillure and research,
it seems that standard x264 built lack some "4-slice"
support in produced stream to be BD compliant, at
least in scenarist (v4.3.0) aspect.
I've found that maybe it exist some patched version
wich add these "slice".
I hope i'm in the right place to ask this.
If these versions exist, where can i find them,
and what specific command line option do i have
to add in MeGUI ?

Thanks.

[nurbs]

You can try to compile x264 with this patch (http://mailman.videolan.org/pipermail/x264-devel/2009-August/006106.html) and then add the appropriate custom command line options in megui.

[juGGaKNot]

param->analyse.i_me_method = X264_ME_TESA;
param->analyse.i_subpel_refine = 10;
param->analyse.i_me_range = 32;
param->i_frame_reference = 16;
param->i_bframe_adaptive = X264_B_ADAPT_TRELLIS;
param->analyse.i_direct_mv_pred = X264_DIRECT_PRED_AUTO;
param->analyse.inter |= X264_ANALYSE_PSUB8x8;
param->analyse.b_fast_pskip = 0;
param->analyse.i_trellis = 2;
param->i_bframe = 4;
param->rc.f_qcompress = 1.0f;
param->rc.i_vbv_max_bitrate = 20000;
param->rc.i_vbv_buffer_size = 20000;
param->vui.b_fullrange = 1;
param->analyse.f_psy_rd = 1.0f;
param->analyse.f_psy_trellis = 0.0f;
param->rc.i_aq_mode = X264_AQ_AUTOVARIANCE;
param->rc.f_aq_strength = 1.0f;
param->rc.f_ip_factor = 1.1f;
param->rc.f_pb_factor = 1.1f;
param->vui.i_sar_height = 1;
param->vui.i_sar_width = 1;
param->i_deblocking_filter_alphac0 = 1;
param->i_deblocking_filter_beta = 1;
param->analyse.b_dct_decimate = 0;
param->rc.b_aud = 1; does not work.

[moviefan]

Referring to jpsdr's post, is slicing actually needed to be BD compliant? And are there disadvantages using the multislice-patch?

[Dark Shikari]

Referring to jpsdr's post, is slicing actually needed to be BD compliant? And are there disadvantages using the multislice-patch?Slightly lower compression (a few %).

Technically, BD does require slicing, but I have yet to receive a report of a player not taking an unsliced stream.

Some authoring software checks it anyways though.

[moviefan]

OK, if the patch is used, is x264 in its current development stage capable of 100% BD compliance (official requirements)? (speaking of encoding 1080p material, using Level 4.1 and the correct settings to be within BD specs)

[Dark Shikari]

OK, if the patch is used, is x264 in its current development stage capable of 100% BD compliance (official requirements)? (speaking of encoding 1080p material, using Level 4.1 and the correct settings to be within BD specs)Maybe. We don't really know; the spec is secret.

[juGGaKNot]

param->rc.b_aud = 1; does not work.

x264.c: In function 'Parse':
x264.c:610: error: 'struct <anonymous>' has no member named 'b_aud'
make[1]: *** [x264.o] Error 1
make[1]: Leaving directory `/d/x264'
make: *** [fprofiled] Error 2

Administrator@LastXP15 /d/x264
$

What is the right param ?

[LoRd_MuldeR]

What is the right param ?

Try this ;)

param->b_aud = 1;

[juGGaKNot]

LOL, i tried it and it did not work, now it does.

thnx

anyway a download link for x264_win_zone_parse_fix_05.diff ?

[LoRd_MuldeR]

Let me google that for you:
http://lmgtfy.com/?q=x264_win_zone_parse_fix_05+filetype%3Adiff

[juGGaKNot]

filetype:xxx, good tip

i get one error

hrd also got errors, 13 modified, 14 and 15 :

$ patch -p1 < /d/x264_win_zone_parse_fix_05.diff
patching file encoder/ratecontrol.c
Hunk #1 FAILED at 638.
Hunk #2 FAILED at 649.
2 out of 2 hunks FAILED -- saving rejects to file encoder/ratecontrol.c.rej

$ patch -p1 < /d/x264_hrd_pulldown.13_interlace.diff
patching file common/bs.h
Hunk #1 FAILED at 169.
1 out of 1 hunk FAILED -- saving rejects to file common/bs.h.rej
patching file common/common.c
Hunk #1 FAILED at 141.
Hunk #2 FAILED at 370.
Hunk #3 FAILED at 585.
3 out of 3 hunks FAILED -- saving rejects to file common/common.c.rej
patching file common/common.h
Hunk #1 FAILED at 279.
1 out of 1 hunk FAILED -- saving rejects to file common/common.h.rej
patching file common/frame.c
Hunk #1 FAILED at 109.
1 out of 1 hunk FAILED -- saving rejects to file common/frame.c.rej
patching file common/frame.h
Hunk #1 FAILED at 34.
1 out of 1 hunk FAILED -- saving rejects to file common/frame.h.rej
patching file common/set.h
Hunk #1 FAILED at 125.
1 out of 1 hunk FAILED -- saving rejects to file common/set.h.rej
patching file encoder/encoder.c
Hunk #1 FAILED at 383.
Hunk #2 FAILED at 702.
Hunk #3 FAILED at 908.
Hunk #4 FAILED at 1309.
Hunk #5 FAILED at 1358.
Hunk #6 FAILED at 1368.
Hunk #7 FAILED at 1390.
Hunk #8 FAILED at 1514.
Hunk #9 FAILED at 1547.
Hunk #10 FAILED at 1608.
Hunk #11 FAILED at 1699.
Hunk #12 FAILED at 1749.
Hunk #13 FAILED at 1763.
13 out of 13 hunks FAILED -- saving rejects to file encoder/encoder.c.rej
patching file encoder/ratecontrol.c
Hunk #1 FAILED at 70.
Hunk #2 FAILED at 91.
Hunk #3 FAILED at 143.
Hunk #4 FAILED at 287.
Hunk #5 FAILED at 1088.
Hunk #6 FAILED at 1170.
Hunk #7 FAILED at 1292.
Hunk #8 FAILED at 1305.
8 out of 8 hunks FAILED -- saving rejects to file encoder/ratecontrol.c.rej
patching file encoder/ratecontrol.h
Hunk #1 FAILED at 34.
1 out of 1 hunk FAILED -- saving rejects to file encoder/ratecontrol.h.rej
patching file encoder/set.c
Hunk #1 FAILED at 208.
Hunk #2 FAILED at 391.
Hunk #3 FAILED at 580.
3 out of 3 hunks FAILED -- saving rejects to file encoder/set.c.rej
patching file encoder/set.h
Hunk #1 FAILED at 29.
1 out of 1 hunk FAILED -- saving rejects to file encoder/set.h.rej
patching file x264.c
Hunk #1 FAILED at 196.
Hunk #2 FAILED at 354.
Hunk #3 FAILED at 399.
Hunk #4 FAILED at 467.
Hunk #5 FAILED at 1107.
5 out of 5 hunks FAILED -- saving rejects to file x264.c.rej
patching file x264.h
Hunk #1 FAILED at 201.
Hunk #2 FAILED at 267.
Hunk #3 FAILED at 293.
3 out of 3 hunks FAILED -- saving rejects to file x264.h.rej

$ patch -p1 < /d/x264_hrd_pulldown.14_interlace.diff
patching file common/bs.h
Hunk #1 FAILED at 169.
1 out of 1 hunk FAILED -- saving rejects to file common/bs.h.rej
patching file common/common.c
Hunk #1 FAILED at 145.
Hunk #2 FAILED at 374.
Hunk #3 FAILED at 589.
3 out of 3 hunks FAILED -- saving rejects to file common/common.c.rej
patching file common/common.h
Hunk #1 FAILED at 288.
1 out of 1 hunk FAILED -- saving rejects to file common/common.h.rej
patching file common/frame.c
Hunk #1 FAILED at 109.
1 out of 1 hunk FAILED -- saving rejects to file common/frame.c.rej
patching file common/frame.h
Hunk #1 FAILED at 34.
1 out of 1 hunk FAILED -- saving rejects to file common/frame.h.rej
patching file common/set.h
Hunk #1 FAILED at 125.
1 out of 1 hunk FAILED -- saving rejects to file common/set.h.rej
patching file encoder/encoder.c
Hunk #1 FAILED at 403.
Hunk #2 FAILED at 725.
Hunk #3 FAILED at 931.
Hunk #4 FAILED at 940.
Hunk #5 FAILED at 1386.
Hunk #6 FAILED at 1396.
Hunk #7 FAILED at 1418.
Hunk #8 FAILED at 1571.
Hunk #9 FAILED at 1633.
Hunk #10 FAILED at 1729.
Hunk #11 FAILED at 1779.
Hunk #12 FAILED at 1793.
12 out of 12 hunks FAILED -- saving rejects to file encoder/encoder.c.rej
patching file encoder/ratecontrol.c
Hunk #1 FAILED at 68.
Hunk #2 FAILED at 89.
Hunk #3 FAILED at 140.
Hunk #4 FAILED at 286.
Hunk #5 FAILED at 1089.
Hunk #6 FAILED at 1171.
Hunk #7 FAILED at 1293.
Hunk #8 FAILED at 1305.
8 out of 8 hunks FAILED -- saving rejects to file encoder/ratecontrol.c.rej
patching file encoder/ratecontrol.h
Hunk #1 FAILED at 34.
1 out of 1 hunk FAILED -- saving rejects to file encoder/ratecontrol.h.rej
patching file encoder/set.c
Hunk #1 FAILED at 208.
Hunk #2 FAILED at 383.
Hunk #3 FAILED at 572.
3 out of 3 hunks FAILED -- saving rejects to file encoder/set.c.rej
patching file encoder/set.h
Hunk #1 FAILED at 29.
1 out of 1 hunk FAILED -- saving rejects to file encoder/set.h.rej
patching file x264.c
Hunk #1 FAILED at 196.
Hunk #2 FAILED at 354.
Hunk #3 FAILED at 399.
Hunk #4 FAILED at 467.
4 out of 4 hunks FAILED -- saving rejects to file x264.c.rej
patching file x264.h
Hunk #1 FAILED at 200.
Hunk #2 FAILED at 266.
Hunk #3 FAILED at 292.
3 out of 3 hunks FAILED -- saving rejects to file x264.h.rej

$ patch -p1 < /d/x264_hrd_pulldown.15_interlace.diff
patching file common/bs.h
Hunk #1 FAILED at 169.
1 out of 1 hunk FAILED -- saving rejects to file common/bs.h.rej
patching file common/common.c
Hunk #1 FAILED at 145.
Hunk #2 FAILED at 374.
Hunk #3 FAILED at 589.
3 out of 3 hunks FAILED -- saving rejects to file common/common.c.rej
patching file common/common.h
Hunk #1 FAILED at 288.
1 out of 1 hunk FAILED -- saving rejects to file common/common.h.rej
patching file common/frame.c
Hunk #1 FAILED at 109.
1 out of 1 hunk FAILED -- saving rejects to file common/frame.c.rej
patching file common/frame.h
Hunk #1 FAILED at 34.
1 out of 1 hunk FAILED -- saving rejects to file common/frame.h.rej
patching file common/set.h
Hunk #1 FAILED at 125.
1 out of 1 hunk FAILED -- saving rejects to file common/set.h.rej
patching file encoder/encoder.c
Hunk #1 FAILED at 403.
Hunk #2 FAILED at 725.
Hunk #3 FAILED at 931.
Hunk #4 FAILED at 940.
Hunk #5 FAILED at 1386.
Hunk #6 FAILED at 1396.
Hunk #7 FAILED at 1418.
Hunk #8 FAILED at 1571.
Hunk #9 FAILED at 1633.
Hunk #10 FAILED at 1729.
Hunk #11 FAILED at 1779.
Hunk #12 FAILED at 1793.
12 out of 12 hunks FAILED -- saving rejects to file encoder/encoder.c.rej
patching file encoder/ratecontrol.c
Hunk #1 FAILED at 68.
Hunk #2 FAILED at 89.
Hunk #3 FAILED at 140.
Hunk #4 FAILED at 286.
Hunk #5 FAILED at 1089.
Hunk #6 FAILED at 1171.
Hunk #7 FAILED at 1293.
Hunk #8 FAILED at 1305.
8 out of 8 hunks FAILED -- saving rejects to file encoder/ratecontrol.c.rej
patching file encoder/ratecontrol.h
Hunk #1 FAILED at 34.
1 out of 1 hunk FAILED -- saving rejects to file encoder/ratecontrol.h.rej
patching file encoder/set.c
Hunk #1 FAILED at 208.
Hunk #2 FAILED at 384.
Hunk #3 FAILED at 573.
3 out of 3 hunks FAILED -- saving rejects to file encoder/set.c.rej
patching file encoder/set.h
Hunk #1 FAILED at 29.
1 out of 1 hunk FAILED -- saving rejects to file encoder/set.h.rej
patching file x264.c
Hunk #1 FAILED at 196.
Hunk #2 FAILED at 354.
Hunk #3 FAILED at 399.
Hunk #4 FAILED at 467.
4 out of 4 hunks FAILED -- saving rejects to file x264.c.rej
patching file x264.h
Hunk #1 FAILED at 200.
Hunk #2 FAILED at 266.
Hunk #3 FAILED at 292.
3 out of 3 hunks FAILED -- saving rejects to file x264.h.rej

[kemuri-_9]

i get one error
hrd also got errors, 13 modified, 14 and 15 :

i've usually gotten a patch to completely reject when the git repo settings have it in windows text mode (CR/LF) instead of linux (LF only)

check the settings for the git program you're using.

[juGGaKNot]

Using windows xp.

$ git config --global core.autocrlf true

$ patch -p1 < /d/win.diff
patching file encoder/ratecontrol.c
Hunk #1 FAILED at 638.
Hunk #2 FAILED at 649.
2 out of 2 hunks FAILED -- saving rejects to file encoder/ratecontrol.c.rej

$ git config --global core.autocrlf input

$ patch -p1 < /d/win.diff
patching file encoder/ratecontrol.c
Hunk #1 FAILED at 638.
Hunk #2 FAILED at 649.
2 out of 2 hunks FAILED -- saving rejects to file encoder/ratecontrol.c.rej

$ git config --global core.autocrlf false

$ patch -p1 < /d/win.diff
patching file encoder/ratecontrol.c
Hunk #1 FAILED at 638.
Hunk #2 FAILED at 649.
2 out of 2 hunks FAILED -- saving rejects to file encoder/ratecontrol.c.rej

[Trahald]

When you installed git it asks what type of line endings you want, IIRC it defaults to windows (CR/LF) when installed on windows. You should select linux(LF) . When it happened to me, I just reinstalled GIT and changed the setting. I assume there is another quicker way to do it, but i didnt bother looking.

My own question... When i diff, the vcproj/sln files always end up in there. A few times Ive googled til i get tired of googling a way (well.. a simple way) to avoid that, but never can find one. i usually do git diff -ignore-space-at-eol > blah.diff . (the ignore arg ive found keeps the diff file from quoting the entire vcproj file but a header still shows up. ) you can see that at the beginning of my diffs

[juGGaKNot]

You should select linux(LF)

Reinstalled,

windows style = git config --global core.autocrlf true
UNIX style=git config --global core.autocrlf false

same problem.

Changes since Git-1.5.4-preview20080202

New Features
• Comes with official git 1.5.5.
• core.autocrlf is enabled (true) by default. This means git converts to Windows line endings (CRLF) during checkout and converts to Unix line endings (LF) during commit. This is the right choice for cross-platform projects.

true/false/input nothing works, what version do you use ?

[elguaxo]

I downloaded and reinstalled Git-1.6.4-preview20090730.exe. I chose this and now the patching works.

http://img81.imageshack.us/img81/5581/unix.th.png (http://img81.imageshack.us/img81/5581/unix.png)

:)

[Trahald]

@JUGGAKNOT
i presume you did redownload (git clone) after the change? or 'git reset --hard' i think should work too. make sure save changes youve made if any

[juGGaKNot]

@JUGGAKNOT
i presume you did redownload (git clone) after the change? or 'git reset --hard' i think should work too. make sure save changes youve made if any

removed git, crapcleaner, reinstalled unix style ( git config --global core.autocrlf is false )

so

MSYS + MinGW + Git + YASM

Remove "bin\rxvt.exe" file

Open msys\etc\fstab in Notepad, replace d:/min /mingw

export PATH="$PATH:/d/git/bin"
cd /d/
git clone git://git.videolan.org/x264.git
cd /d/x264
git reset --hard
./configure ( Assembler YES, Pthread YES )

Modify x264.c preset placebo > preset juggaknot

param->analyse.i_me_method = X264_ME_TESA;
param->analyse.i_subpel_refine = 10;
param->analyse.i_me_range = 32;
param->i_frame_reference = 16;
param->i_bframe_adaptive = X264_B_ADAPT_TRELLIS;
param->analyse.i_direct_mv_pred = X264_DIRECT_PRED_AUTO;
param->analyse.inter |= X264_ANALYSE_PSUB8x8;
param->analyse.b_fast_pskip = 0;
param->analyse.i_trellis = 2;
param->i_bframe = 4;
param->rc.f_qcompress = 1.0f;
param->rc.i_vbv_max_bitrate = 20000;
param->rc.i_vbv_buffer_size = 20000;
param->vui.b_fullrange = 1;
param->analyse.f_psy_rd = 1.0f;
param->analyse.f_psy_trellis = 0.0f;
param->rc.i_aq_mode = X264_AQ_AUTOVARIANCE;
param->rc.f_aq_strength = 1.0f;
param->rc.f_ip_factor = 1.1f;
param->rc.f_pb_factor = 1.1f;
param->vui.i_sar_height = 1;
param->vui.i_sar_width = 1;
param->i_deblocking_filter_alphac0 = 1;
param->i_deblocking_filter_beta = 1;
param->analyse.b_dct_decimate = 0;
param->b_aud = 1;
param->b_nal_hrd = 1;

patch -p1 < /d/win.diff
patch -p1 < /d/hrd.diff
make fprofiled VIDS=sample.avs

compiles fine, i get a 498kb x264.exe

x264.exe" --pass 1 --slow-firstpass --preset juggaknot --bitrate x --output NUL avs
x264.exe" --pass 2 --preset juggaknot --bitrate x --output x avs

Makes

Writing library : x264 core 68 r1195M 5d75a9b
Encoding settings : cabac=1 / ref=10 / deblock=1:1:1 / analyse=0x3:0x133 / me=tesa / subme=10 / psy_rd=1.0:0.0 / mixed_ref=1 / me_range=32 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / chroma_qp_offset=-2 / threads=3 / nr=0 / decimate=0 / mbaff=0 / bframes=4 / b_pyramid=0 / b_adapt=2 / b_bias=0 / direct=3 / wpredb=1 / keyint=250 / keyint_min=25 / scenecut=40 / rc=2pass / bitrate=200 / ratetol=1.0 / qcomp=1.00 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=20000 / vbv_bufsize=20000 / ip_ratio=1.10 / pb_ratio=1.10 / aq=2:1.00

I think the problem was i have a 2l fanta here not a 10l cola.

THNX.

[rack04]

I have the latest git but I'm unsure how to properly apply these patch files. I have the latest git and I have copied the patches to the project directory. Do I just type:

patch < x264_hrd_pulldown.15_interlace.diff -p0

and

patch < x264_win_zone_parse_fix_05.diff -p0

If I try that MSYS asks for a file to path.

[LoRd_MuldeR]

If you run from x264 root directory (this is where x264.c and x264.h are located), the correct command for most patches is:
patch -p1 < somepatch.diff

[rack04]

Great thanks. One other question, how do I configure for mp4 output?

[LoRd_MuldeR]

Great thanks. One other question, how do I configure for mp4 output?

GPAC is needed:
http://gpac.sourceforge.net/home_download.php

The configure script should detect it automatically, if installed.

[rack04]

GPAC is needed:
http://gpac.sourceforge.net/home_download.php

The configure script should detect it automatically, if installed.

Is there an installer for GPAC? All I see is the source code.

[juGGaKNot]

k, i'm getting tired of editing the x264.c so i want to make a diff

else if( !strcasecmp( optarg, "juggaknot" ) )
{
param->analyse.i_me_method = X264_ME_TESA;
param->analyse.i_subpel_refine = 10;
param->analyse.i_me_range = 32;
param->i_frame_reference = 16;
param->i_bframe_adaptive = X264_B_ADAPT_TRELLIS;
param->analyse.i_direct_mv_pred = X264_DIRECT_PRED_AUTO;
param->analyse.inter |= X264_ANALYSE_PSUB8x8;
param->analyse.b_fast_pskip = 0;
param->analyse.i_trellis = 2;
param->i_bframe = 4;
param->rc.f_qcompress = 1.0f;
param->rc.i_vbv_max_bitrate = 20000;
param->rc.i_vbv_buffer_size = 20000;
param->vui.b_fullrange = 1;
param->analyse.f_psy_rd = 1.0f;
param->analyse.f_psy_trellis = 0.0f;
param->rc.i_aq_mode = X264_AQ_AUTOVARIANCE;
param->rc.f_aq_strength = 1.0f;
param->rc.f_ip_factor = 1.1f;
param->rc.f_pb_factor = 1.1f;
param->vui.i_sar_height = 1;
param->vui.i_sar_width = 1;
param->i_deblocking_filter_alphac0 = 1;
param->i_deblocking_filter_beta = 1;
param->analyse.b_dct_decimate = 0;
param->b_aud = 1;
param->b_nal_hrd = 1;
}

what else do i need in the diff to make sure it patches right ?

[roozhou]

Is there an installer for GPAC? All I see is the source code.
You don't have to download the source code and compile it on your own. It's a waste of time and energy.

Thanks to Sherpya we can get headers and pre-compiled libraries here:
http://oss.netfarm.it/mplayer/pkgs/libgpac_static-mingw32-0.4.5-gcc45.tar.bz2

Unzip it to your mingw folder and they should work.

[rack04]

Is the x264.exe created by "make fprofiled VIDS=/c/x264/riverbed.1920x1080.yuv" the final build? Or do I need to "make" after the fprofiled is complete?

[kemuri-_9]

k, i'm getting tired of editing the x264.c so i want to make a diff

what else do i need in the diff to make sure it patches right ?

clone the repository, edit the files as necessary, and then do a git diff and have the output redirect to a file i.e.
git diff > custom_profile.diff

then you can use this produced file with patch to replicate the changes with the non-edited file(s)

Is the x264.exe created by "make fprofiled VIDS=/c/x264/riverbed.1920x1080.yuv" the final build? Or do I need to "make" after the fprofiled is complete?
when make fprofiled finishes, that's the fprofiled binary....

[rack04]

when make fprofiled finishes, that's the fprofiled binary....

Excellent thanks.

Here is my x264 build:

x264 core:68 r1195 5d75a9b (http://www.mediafire.com/?sharekey=5d73f4b17331fe365a3d773badf21430e04e75f6e8ebb871)

Built on August 3, 2009, gcc: 4.4.0

$ ./configure --extra-cflags="-march=core2"

Platform: X86
System: MINGW
asm: yes
avis input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no

You can run 'make' or 'make fprofiled' now.

$ make fprofiled VIDS="riverbed.1920x1080.yuv"

Used patches:

x264_hrd_pulldown.15_interlace.diff
x264_win_zone_parse_fix_05.diff

[juGGaKNot]

clone the repository, edit the files as necessary, and then do a git diff and have the output redirect to a file i.e.
git diff > custom_profile.diff

then you can use this produced file with patch to replicate the changes with the non-edited file(s)

Every time git is updated or until the diff fails to patch ?

i got http://en.pastebin.ca/1516972

it seems valid for builds with hrd and zone fix.

[LoRd_MuldeR]

Every time git is updated or until the diff fails to patch ?.

If you made the patch as suggest by Kemuri, you can use that patch to re-apply your modifications every time you checked out the latest version from GIT.

However in case there are changes in the GIT version that make your patch fail, you will need to adjust the patch (or simply make a new patch against latest GIT).

[juGGaKNot]

If you made the patch as suggest by Kemuri, you can use that patch to re-apply your modifications every time you checked out the latest version from GIT.

However in case there are changes in the GIT version that make your patch fail, you will need to adjust the patch (or simply make a new patch against latest GIT).

I made it as suggested by you, git diff x264.c > 444.dif

git diff > 444.diff fails

now i patch win zone fix 05 then hrd

after i test my diff win zone fix 05 then hrd than my diff ?

[komisar]

I have published a new version of mingw cross-compile toolchain with gcc441 with Graphite loop transform framework (http://komisar.gin.by/mingw/index.html).
If you're interested - test please.
Build scripts and step-by-step description also published.

x264 1195 updated...
http://komisar.gin.by/

[juGGaKNot]

As soon as git is updated komisar.

[LoRd_MuldeR]

I have published a new version of mingw cross-compile toolchain with gcc441 with Graphite loop transform framework (http://komisar.gin.by/mingw/index.html).
If you're interested - test please.

Seems to work for me. Thanks!

[rack04]

when make fprofiled finishes, that's the fprofiled binary....

The reason I asked is because the time stamp on the file doesn't change.

[LoRd_MuldeR]

The reason I asked is because the time stamp on the file doesn't change.

The "make fprofiled" command does the following:

1. It builds x264 with -fprofile-generate
2. It runs several test encodes to collect profiling information
3. It re-builds x264, this time with -fprofile-use

So the very last thing it does is creating a new binary. I'd suspect the timestamp of x264.exe to change at that moment ;)

(Note that "make fprofiled" does that all for you. You don't need run "make" once again! This would actually replace the "fprofiled" binary with a non-profiled one ^^)

[kemuri-_9]

The reason I asked is because the time stamp on the file doesn't change.

*irritated*

fprofiled:
$(MAKE) clean
mv config.mak config.mak2
sed -e 's/CFLAGS.*/& -fprofile-generate/; s/LDFLAGS.*/& -fprofile-generate/' config.mak2 > config.mak
$(MAKE) x264$(EXE)
$(foreach V, $(VIDS), $(foreach I, 0 1 2 3 4 5 6 7, ./x264$(EXE) $(OPT$I) --threads 1 $(V) -o $(DEVNULL) ;))
rm -f $(SRC2:%.c=%.o)
sed -e 's/CFLAGS.*/& -fprofile-use/; s/LDFLAGS.*/& -fprofile-use/' config.mak2 > config.mak
$(MAKE)
rm -f $(SRC2:%.c=%.gcda) $(SRC2:%.c=%.gcno)
mv config.mak2 config.mak
endif

...

clean:
rm -f $(OBJS) $(OBJASM) $(OBJCLI) $(SONAME) *.a x264 x264.exe .depend TAGS
rm -f checkasm checkasm.exe tools/checkasm.o tools/checkasm-a.o
rm -f $(SRC2:%.c=%.gcda) $(SRC2:%.c=%.gcno)
- sed -e 's/ *-fprofile-\(generate\|use\)//g' config.mak > config.mak2 && mv config.mak2 config.mak


make fprofiled deletes any binary that's already there and makes a profile-capable binary, profiles, and then makes the profiled binary.

chances are you're looking at the creation timestamp which usually never changes, look at the modified timestamp

[rack04]

make fprofiled deletes any binary that's already there and makes a profile-capable binary, profiles, and then makes the profiled binary.

chances are you're looking at the creation timestamp which usually never changes, look at the modified timestamp

*not-irritated*

Thanks! :)

[rack04]

x264 r1195 32-bit

Download (http://www.megaupload.com/?d=1G1GDIO0)

Built by rack04 on August 5, 2009, 8:24:42 AM CST
GCC: 4.4.1 (x86.core2.Komisar)
--extra-cflags="-march=core2"
fprofiled with a 300 frame PNG sequence of Big Buck Bunny

Patched with:

x264_hrd_pulldown.15_interlace.diff
x264_win_zone_parse_fix_05.diff

Platform: X86
System: MINGW
asm: yes
avis input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no

[juGGaKNot]

x264_x86_r1198_juGGaKNot (http://www.mediafire.com/download.php?dez2jqve5mn)
GCC 4.4.1, generic, fprofiled, patched
Source: GIT

Applied patches :

x264_win_zone_parse_fix_05.diff (http://www.mediafire.com/download.php?kqymujywhtw)

It is fprofiled on a uncompressed source with very high motion.

Please check Doom9.org patches thread (http://forum.doom9.org/showthread.php?t=130364), Doom9.org Macroblock tree Ratecontrol thread (http://forum.doom9.org/showthread.php?t=148686) and GIT shortlog (http://git.videolan.org/gitweb.cgi?p=x264.git;a=shortlog) for more info.

Compiled by juGGaKNot (http://forum.doom9.org/member.php?u=144865) with GCC 4.4.1 on Windows XP SP-2 32-bit.

Platform: X86
System: MINGW
asm: yes
avis input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no

BTW with mbtree commited i get the "mbtre + b-piramid" not suported warning dark, will you update to avoid this or is it k ?

Waiting for HRD 16.

[rack04]

BTW with mbtree commited i get the "mbtre + b-piramid" not suported warning dark, will you update to avoid this or is it k ?

What do you mean update? b-pyramid isn't supported. That is what the message is telling you.

What doesn't it work with yet?

--b-pyramid

[juGGaKNot]

to get fprofiled it encodes, it uses some settings, in one encode it uses --b-pyramid + mbtree and displays a warning

also pbratio is in the --longhelp, does it still exist ( i guess when not using mbtree ) ?

[wyti]

Add mean Add, very slow is only a new profile, but placebo still exist.

And the warning, not very important it display this warning and internally disable b-pyramid, and a new update will probably come to support B-pyramid

[komisar]

Trahald, is this correct adaptation to 1198 version?
x264_hrd_pulldown.15_interlace.fix.1198.diff (http://komisar.gin.by/x.patch/x264_hrd_pulldown.15_interlace.fix.1198.diff)

[rack04]

Trahald, is this correct adaptation to 1198 version?
x264_hrd_pulldown.15_interlace.fix.1198.diff (http://komisar.gin.by/x.patch/x264_hrd_pulldown.15_interlace.fix.1198.diff)

I tried this patch and during the 2nd pass it kept throwing an error about "ratecontrol_init: can't open mbtree stats file".

avis [info]: 640x480 @ 60.00 fps (200 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [error]: ratecontrol_init: can't open mbtree stats file
x264 [error]: x264_encoder_open failed

[komisar]

rack04, strange... I don't see any error. Can you post command-line? (more likely it is not because of this patch)

[rack04]

rack04, strange... I don't see any error. Can you post command-line?

Echo.
Echo.
Echo.[ %TIME% ] Encoding pass 1 ...
Echo.

@Echo on
"%x264_PATH%" --preset veryfast --tune film --pass 1 --slow-firstpass --bitrate %VIDBITRATE% --stats "%SOURCE_FOLDER%\%SOURCE_FILENAME%.stats" --level 4.1 --keyint 24 --min-keyint 1 --vbv-bufsize 30000 --vbv-maxrate 24000 --direct auto --b-adapt 2 --nal-hrd --output NUL "%INPUT_VIDEO%" 2>"%SOURCE_FOLDER%\%SOURCE_FILENAME%-1pass.txt"
@Echo off

Echo.
Echo.
Echo.[ %TIME% ] Encoding pass 2 ...
Echo.

@Echo on
"%x264_PATH%" --preset slower --tune film --pass 2 --bitrate %VIDBITRATE% --stats "%SOURCE_FOLDER%\%SOURCE_FILENAME%.stats" --level 4.1 --keyint 24 --min-keyint 1 --vbv-bufsize 30000 --vbv-maxrate 24000 --no-fast-pskip --sar 1:1 --aud --nal-hrd --output "%SOURCE_FOLDER%\%SOURCE_FILENAME%-output.h264" "%INPUT_VIDEO%" 2>"%SOURCE_FOLDER%\%SOURCE_FILENAME%-2pass.txt"
@Echo off

[rack04]

This is the build that I'm using:

x264 core:69 r1198M a1ed468 32-bit

Download (http://www.mediafire.com/?sharekey=ec060338ab9d891fe7c82ed4b8f0c380e04e75f6e8ebb871)

Built by rack04 on August 7, 2009, 10:47:09 AM CST
GCC: 4.4.1 (x86.core2.Komisar)
--extra-cflags="-march=core2"
fprofiled with 200 frames of BigBuckBunny.avs, 200 frames of LosslessTouhou.mkv, and 250 frames of riverbed.1920x1080.yuv

Patched with:

x264_hrd_pulldown.15_interlace.fix.1198.diff
x264_win_zone_parse_fix_05.diff

Platform: X86
System: MINGW
asm: yes
avis input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no

[juGGaKNot]

x264_x86_r1198_HRD_fix_juGGaKNot (http://www.mediafire.com/download.php?zmkxzlnyngn)
GCC 4.4.1, modified, fprofiled, patched
Source: GIT

Applied patches :

x264_win_zone_parse_fix_05.diff (http://www.mediafire.com/download.php?kqymujywhtw)
x264_hrd_pulldown.15_interlace.fix.1198.diff (http://www.mediafire.com/download.php?lgng2dkyoyz)

It is fprofiled on a uncompressed 300 frames source with very high motion

Please check Doom9.org patches thread (http://forum.doom9.org/showthread.php?t=130364), and GIT shortlog (http://git.videolan.org/gitweb.cgi?p=x264.git;a=shortlog) for more info.

Compiled by juGGaKNot (http://forum.doom9.org/member.php?u=144865) with GCC 4.4.1 on Windows XP SP-2 32-bit.

Platform: X86
System: MINGW
asm: yes
avis input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no

It patches right, it encodes right.

[komisar]

rack04, with "--preset ultrafast/veryfast/faster" stats.mbtree not created... :-\ In this presets mb-tree disabled...
Add --mbtree for 1st pass.

[rack04]

rack04, with "--preset ultrafast/veryfast/faster" stats.mbtree not created... :-\

So is this considered a bug in the x264 or my fault for a bad command line? I think since --slow-firstpass is an option the mbtree should take into account --preset ultrafast/veryfast/faster in the first pass.

[juGGaKNot]

Rack rc-lookahead is disabled on the second pass, your setup is useless for mbtree.

[rack04]

Rack rc-lookahead is disabled on the second pass, your setup is useless for mbtree.

How do you figure? Default is 40.

Although now that I look at the mediainfo information:

Encoding settings: cabac=1 / ref=8 / deblock=1:-1:-1 / analyse=0x3:0x133 / me=umh / subme=9 / psy=1 / psy_rd=1.0:0.2 / mixed_ref=1
/ me_range=16 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / chroma_qp_offset=-3 / threads=3 / nr=0 / decimate=1
/ mbaff=0 / bframes=3 / b_pyramid=0 / b_adapt=2 / b_bias=0 / direct=3 / wpredb=1 / keyint=24 / keyint_min=1 / scenecut=40 / rc_lookahead=24
/ rc=2pass / mbtree=1 / bitrate=10732 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0
/ qblur=0.5 / vbv_maxrate=24000 / vbv_bufsize=30000 / ip_ratio=1.40 / aq=1:1.00


:confused:

[juGGaKNot]

Read the mbtree thread

rc-lookahead is disabled on second pass since 0.11, rc1 will show lookahead 0, commited version has a tweak to show the first pass value.

Changes in 0.11:

2. Lots of trivial parameter-handling fixes, e.g. lookahead automatically disabled on second pass.

[Dark Shikari]

Lookahead is clipped to keyint.

[juGGaKNot]

Lookahead is clipped to keyint.

Really ? so bd users have to use 24 max hmm.

rack

Always use the same preset in both passes.

[akupenguin]

so bd users have to use 24 max hmm.
Lookahead>keyint would not be useful. We don't strictly stop the lookahead at the next keyframe, but that's only for consistency with the previous frames in the GOP that had more dependents. No frame will ever actually affect anything more than a keyint ahead, so it would just be wrong to include those in the lookahead window.

[imk]

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

x264-r1201M-imk-osx.7z (http://imk.cx/pc/x264/x264-r1201M-imk-osx.7z)

I didn't use the hrd or win zone patch for this build. When those patches are updated, I'll make new builds.

[juGGaKNot]

x264_x86_r1201_juGGaKNot (http://www.mediafire.com/download.php?yxnmxtjiyzt)
GCC 4.4.1, generic, fprofiled.
Source: GIT

It is fprofiled on a uncompressed 300 frames source with very high motion

Please check Doom9.org patches thread (http://forum.doom9.org/showthread.php?t=130364), Doom9.org Macroblock tree Ratecontrol thread (http://forum.doom9.org/showthread.php?t=148686) and GIT shortlog (http://git.videolan.org/gitweb.cgi?p=x264.git;a=shortlog) for more info.

Compiled by juGGaKNot (http://forum.doom9.org/member.php?u=144865) with GCC 4.4.1 on Windows XP SP-2 32-bit.


Platform: X86
System: MINGW
asm: yes
avis input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no

I didn't use the hrd or win zone patch for this build. When those patches are updated, I'll make new builds.

What he said.

BTW its not M ( i think ), no patches applied ...

[rack04]

x264 core:70 r1206M 01a693d 32-bit

Download (http://www.megaupload.com/?d=VEQJ7738)

Built by rack04 on August 9, 2009, 9:11:59 AM CST
GCC: 4.4.1 (x86.core2.Komisar)
--extra-cflags="-march=core2"
fprofiled with 200 frames of BigBuckBunny.avs, 200 frames of LosslessTouhou.mkv, and 250 frames of riverbed.1920x1080.yuv

Platform: X86
System: MINGW
asm: yes
avis input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no

[imk]

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

x264-r1206M-imk-osx.7z (http://imk.cx/pc/x264/x264-r1206M-imk-osx.7z)

[kemuri-_9]

so i decided to update the win zone patch for everyone (even though i don't use it).
it took longer to find the 05 revision backward traversing this thread than to fix the darn thing :sly:

x264_win_zone_parse_fix_06.diff (http://kemuri9.net/dev/x264/patches/x264_win_zone_parse_fix_06.diff)

[juGGaKNot]

Look 2 posts up, the diffs are linked in all my posts :)

[kemuri-_9]

Look 2 posts up, the diffs are linked in all my posts :)
not the file, you link to threads where the patches exist within posts.
which is effectively useless when a thread such as this one is over 100 pages.
but whatever, i had found the rev 05 win zone patch on page 78 of this thread, and that's all i cared about.

[komisar]

new 1206 builds with adapted patches (need testing)
also new VAQ (again :) may help with fades and mbtree) patch by BugMaster in kMod build. (activate by "--aq-mode 3")
http://komisar.gin.by/

[JEEB]

x264 r1206 64bit unpatched:
download (http://jeeb.fiveforty.jp/x264/revision1206/x264.exe) ; hash (http://jeeb.fiveforty.jp/x264/revision1206/x264.md5)

built on Aug 9 2009, gcc: 4.3.4 20090220 (prerelease) (x64.generic.Komisar)
fprofiled, otherwise defaults

________________________________________________________________________________

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

built on Aug 10 2009, gcc: 4.3.4 20090220 (prerelease) (x32.generic.Komisar)
fprofiled, -march=i686


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

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


patched with:

x264_win_zone_parse_fix_06.diff (http://kemuri9.net/dev/x264/patches/x264_win_zone_parse_fix_06.diff)
x264_hrd_pulldown.15_interlace.fix.1206.diff (http://komisar.gin.by/x.patch/x264_hrd_pulldown.15_interlace.fix.1206.diff)


Hurf, I did compile at least one build during ASM'09, but only now do I get at releasing :3 I wish there was an easy way of recording them demos in order to put up for people who have not-so-powerful machines like myself.

[imk]

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

x264-r1206M_2-imk-osx.7z (http://imk.cx/pc/x264/x264-r1206M_2-imk-osx.7z)

Re-built with:
x264_win_zone_parse_fix_06.diff
x264_hrd_pulldown.15_interlace.fix.1206.diff

[juGGaKNot]

not the file, you link to threads where the patches exist within posts.
which is effectively useless when a thread such as this one is over 100 pages.
but whatever, i had found the rev 05 win zone patch on page 78 of this thread, and that's all i cared about.

I mean posts by me here on the latest pages where there is a patched build

like #2135, i upload all the diffs on mediafire when i post a patched x264.

i said 2 posts up but it was unpatched, my mistake.

LE :

komisar aq3 : ( 4 pictures, aq1, aq2, aq3, xvid )

http://i286.photobucket.com/albums/ll105/juGGaKNot4cs/th_aq1.jpg (http://s286.photobucket.com/albums/ll105/juGGaKNot4cs/?action=view&current=aq1.jpg)http://i286.photobucket.com/albums/ll105/juGGaKNot4cs/th_aq2.jpg (http://s286.photobucket.com/albums/ll105/juGGaKNot4cs/?action=view&current=aq2.jpg)http://i286.photobucket.com/albums/ll105/juGGaKNot4cs/th_aq3.jpg (http://s286.photobucket.com/albums/ll105/juGGaKNot4cs/?action=view&current=aq3.jpg)http://i286.photobucket.com/albums/ll105/juGGaKNot4cs/th_xvid.jpg (http://s286.photobucket.com/albums/ll105/juGGaKNot4cs/?action=view&current=xvid.jpg)

[rack04]

x264 core:70 r1206 32-bit

Download (http://www.sendspace.com/file/477gj3)

Built by rack04 on August 10, 2009, 2:06:11 PM CST
GCC: 4.4.1 (x86.core2.Komisar)
$ ./configure
Platform: X86
System: MINGW
asm: yes
avis input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
$ --extra-cflags="-march=core2"
$ make fprofiled VIDS="bigbuckbunny.avs LosslessTouhou.avs riverbed.1920x1080.yuv"

Patched with:

x264_hrd_pulldown.15_interlace.fix.1206.diff
x264_win_zone_parse_fix_06.diff

[rack04]

x264 core:70 r1209M 32-bit

Download (http://www.mediafire.com/?sharekey=e6d304fba0af2c04c2b435915e8821d7e04e75f6e8ebb871)

Built by rack04 on August 13, 2009, 4:45:30 PM CST
GCC: 4.4.1 (x86.core2.Komisar)
$ ./configure
Platform: X86
System: MINGW
asm: yes
avis input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
$ --extra-cflags="-march=core2"
$ make fprofiled VIDS="bigbuckbunny.avs LosslessTouhou.avs riverbed.1920x1080.yuv"

Patched with:

x264_hrd_pulldown.15_interlace.fix.1206.diff
x264_win_zone_parse_fix_06.diff

[JEEB]

x264 r1210 64bit unpatched:
download (http://koti.mbnet.fi/jeeb/x264/revision1210/x264.exe) ; hash (http://koti.mbnet.fi/jeeb/x264/revision1210/x264.md5)

built on Aug 14 2009, gcc: 4.3.4 20090220 (prerelease) (x64.generic.Komisar)
fprofiled, otherwise defaults

________________________________________________________________________________

x264 r1210 32bit
download (http://koti.mbnet.fi/jeeb/x264/1210/x264.exe) ; release notes (http://koti.mbnet.fi/jeeb/x264/1210/relnotes.txt)

built on Aug 14 2009, gcc: 4.3.4 20090220 (prerelease) (x32.generic.Komisar)
fprofiled, -march=i686


x264 r1210 64bit
download (http://koti.mbnet.fi/jeeb/x264/1210_x64/x264.exe) ; release notes (http://koti.mbnet.fi/jeeb/x264/1210_x64/relnotes.txt)

built on Aug 14 2009, gcc: 4.3.4 20090220 (prerelease) (x32.generic.Komisar)
fprofiled, -march=core2


patched with:

x264_win_zone_parse_fix_06.diff (http://kemuri9.net/dev/x264/patches/x264_win_zone_parse_fix_06.diff)
x264_hrd_pulldown.15_interlace.fix.1206.diff (http://komisar.gin.by/x.patch/x264_hrd_pulldown.15_interlace.fix.1206.diff)


Hurf, and the Japanese box I'm using fell for the first time in two or so years :3 Using MBnet as hosting for this build at least temporarily until the box comes back up.

[imk]

r1210M built with ICC.

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

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

[deank]

@Dark Shikari:

About my post in BD-Rebuilder thread:

I just tried these latest patched versions from posts above (32bit):

* JEEB's one works.
* imk's one - does not work (gives the same blocky output) (and shows Slow_mod4_stack).

Both tested with same options, same source (720x576p @ 25fps).

Dean

[Dark Shikari]

@Dark Shikari:

About my post in BD-Rebuilder thread:

I just tried these latest patched versions from posts above (win32):

* JEEB's one works.
* imk's one - does not work (gives the same blocky output).

Both tested with same options, same source (720x576i @ 25fps).

DeanThen it sounds like IMK's build has been miscompiled.

[imk]

Slow_mod4_stack only exists for the 32-bit build. Despite saying that, it still ends up to be slightly faster than GCC. It shouldn't affect any quality.

As for the blocky output, I'm not sure. Could you link me to the clip you're using and the args you use so I can run my own tests?

[Selur]

@Trahald: there's a user (http://forum.gleitz.info/showpost.php?p=393212&postcount=430) in the german doom9 forum which got a "Assertion failed: dpb_output_delay < pow( 2, sps->vui.nal_hrd_parameters.i_dpb_output_delay_length ), file encoder/set.c, line 652"-crash using the following command line:
x264 --profile high --crf 22 --level 4 --ref 5 --keyint 50 --min-keyint 25 --scenecut 40 --bframes 3 --b-bias 0 --direct auto --cplxblur 20 --qcomp 0.6 --qblur 0.5 --qpmin 1 --qpmax 51 --qpstep 4 --ipratio 1.4 --pbratio 1.3 --chroma-qp-offset 0 --partitions i4x4,i8x8,p8x8,b8x8 --me hex --merange 16 --subme 10 --no-mixed-refs --no-fast-pskip --aq-mode 1 --aq-strength 1 --deadzone-inter 11 --vbv-maxrate 24000 --vbv-bufsize 30000 --aud --nal-hrd --threads auto --sar 10:11 --filter 0,0 --fps 25 --output "C:\WINDOWS\TEMP\test1_222855078.264" - 720x480 and this (http://forum.doom9.org/showthread.php?p=1314614#post1314614) build.
thought this might help finding the problem.

Cu Selur

[deank]

As for the blocky output, I'm not sure. Could you link me to the clip you're using and the args you use so I can run my own tests?

Here. (http://rapidshare.com/files/267990592/dvddump.m2ts)

[Trahald]

@Selur
I couldnt duplicate the issue with that command line. If whoever it is can document the frame the error occurs on, then run an encode on a build with the assert line removed (so the encode will complete)and send me the output. then i can see the conditions which cause the error. I think the calcs are ok so id like to pin down the prob instead of arbitrarily making the value larger.

[imk]

Here. (http://rapidshare.com/files/267990592/dvddump.m2ts)

Alright, thanks. I'll run some tests on it to see if I can duplicate it or alleviate the problem.

[Selur]

@Trahald: I'll contact the user and ask him to test it like you suggested.
(now I just have to get my build environment running again to provide the user with a build he can use.;))
-> provided him with a new builds, the one without the assertion can through an he'll upload the created file later (will forward it than to you)

[imk]

Here. (http://rapidshare.com/files/267990592/dvddump.m2ts)

Also, which settings are you using with x264?


Edit:
I've been trying my builds and JEEB's builds in Windows, and I tried my ICC build and a GCC build of mine in OS X, and they all output identical, md5sum-matching, bitstreams.


Edit 2:
Alright, it seems to be that the 64-bit ICC build produces identical output to GCC. The 32-bit version is where things are slightly different. Since it has Slow_mod4_stack, I believe that certain C functions are used instead of ASM, which might explain why the output is different. I'm not sure if that would result in “blocky” output, or just slightly different output. I'll run more tests.


Edit 3:
I really can't reproduce this. I get basically the same output. Only the headers differ.

For MD5 sums... 32-bit GCC and 32-bit ICC are identical, but differ from the 64-bit builds. And 64-bit GCC and 64-bit ICC are identical.

There really shouldn't be any different output.

[moviefan]

@Dark Shikari (most probably): The --help documentation misses --aq-mode 3 to be mentioned and described. I just noticed that and thought it's worth mentioning, just to keep up consistency.

[Dark Shikari]

@Dark Shikari (most probably): The --help documentation misses --aq-mode 3 to be mentioned and described. I just noticed that and thought it's worth mentioning, just to keep up consistency.AQ mode 3 is not part of official x264; it's the job of patch maintainers to add their own help.

[moviefan]

Oh, I didn't notice JEEB's binary included an AQ patch... He only names the winzone and the hrd patch.

[juGGaKNot]

--aq 3 was added as a diff by komisar @ 1206 i think , to help fades.

http://komisar.gin.by/index.html

i can compile a 1210 if you want.

[moviefan]

Thanks for the offer, but it seems that JEEB has included the diff already without explicitly mentioning.

[alwa]

I don't think JEEB includes this patch. I think the values of aq-mode are just clipped to valid values. So if you set aq-mode 3, the value will be clipped to 2(the maximum valid value). It doesn't matter if you set it to 2, 3 or even 1337 the output will be the same. (Correct me if I'm wrong)

[rack04]

x264 core:71 r1214 32-bit

Download (http://www.mediafire.com/?sharekey=b39064c936236ab08ef1259ff1b60e81e04e75f6e8ebb871)

Built by rack04 on August 17, 2009, 4:05:18 PM CST
$ gcc --version
gcc.exe (GCC) 4.4.1 (x86.core2.Komisar)
$ ./configure --extra-cflags="-march=core2"
Platform: X86
System: MINGW
asm: yes
avis input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
$ make fprofiled VIDS="bigbuckbunny.avs LosslessTouhou.avs riverbed.1920x1080.yuv"

Patched with:

x264_hrd_pulldown.15_interlace.fix.1206.diff (http://komisar.gin.by/x.patch/x264_hrd_pulldown.15_interlace.fix.1206.diff)
x264_win_zone_parse_fix_06.diff (http://kemuri9.net/dev/x264/patches/x264_win_zone_parse_fix_06.diff)

[JEEB]

x264 r1214 64bit unpatched:
download (http://jeeb.fiveforty.jp/x264/revision1214/x264.exe) ; hash (http://jeeb.fiveforty.jp/x264/revision1214/x264.md5)

built on Aug 18 2009, gcc: 4.3.4 20090220 (prerelease) (x64.generic.Komisar)
fprofiled, otherwise defaults

________________________________________________________________________________

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

built on Aug 18 2009, gcc: 4.3.4 20090220 (prerelease) (x32.generic.Komisar)
fprofiled, -march=i686


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

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


patched with:

x264_win_zone_parse_fix_06.diff (http://kemuri9.net/dev/x264/patches/x264_win_zone_parse_fix_06.diff)
x264_hrd_pulldown.15_interlace.fix.1206.diff (http://komisar.gin.by/x.patch/x264_hrd_pulldown.15_interlace.fix.1206.diff)


Hint: I do not add patches that are not mentioned. I do not _trust_ myself to do something like that. Anyways, now building without a VM since I moved to a fully 64bit environment at last. Next step would be to update the msys/mingw environment I have :3

[Fr4nz]

IMK ICC x264 1214 builds for x86/x64 here:

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

[Tarutaru]

x264 r1217 GCC4.4.0 win32 build:
x264-r1217-win32-patched (http://www.mediafire.com/?sharekey=c330f9eea9b6a9ca1bee9a6e9edd9c76a66c1b8c8cdf93cac95965eaa7bc68bc)

pthread, gpac, fprofiled.
patched with:
x264_win_zone_parse_fix_06.diff
x264_hrd_pulldown.15_interlace.fix.1217.diff

[techouse]

x264_hrd_pulldown.15_interlace.fix.1217.diff (http://pastebin.ca/1535080)

[alwa]

x264 r1217 32bit
download (http://www.mediafire.com/?n24zamgjnyn)


built on Aug 19 2009, gcc: 4.4.1 (x86.generic.Komisar)
fprofiled, defaults


x264 r1217 64bit
download (http://www.mediafire.com/?mkyn3jqmtiw)


built on Aug 19 2009, gcc: 4.4.1 (x86_64.generic.Komisar)
fprofiled, defaults



patched with:


x264_win_zone_parse_fix_06.diff (http://kemuri9.net/dev/x264/patches/x264_win_zone_parse_fix_06.diff)
x264_hrd_pulldown.15_interlace.fix.1217.diff (http://www.mediafire.com/?0ijmtdodzty) (own)


I had the build and the updated patch before i saw techouse's updated patch, thats why...

[techouse]

x264_x64_r1217_unpatched (http://techouse.project357.com/builds/revision1217/x264.exe) | MD5 (http://techouse.project357.com/builds/revision1217/x264.md5)
GCC 4.4.1 20090803 (x64.core2.Komisar), unpatched, generic, fprofiled

________________________________________________________________________________

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

x264_x64_r1217_techouse (http://techouse.project357.com/builds/x264_x64_r1217_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x64_r1217_techouse.txt)
GCC 4.4.1 20090803 (x86_64.core2.Komisar), fprofiled, -march=core2

Patches used:

x264_hrd_pd_interlace.16.diff
x264_win_zone_parse_fix_06.diff

[Trahald]

Attached is hrd 16. it will patch to 1217. There is also a workaround for an inconsistency (not a bug) in x264. i_fps_den is sometimes the value passed from the frame server but other times its LCD to i_fps_num. so i just commented out the line. considering it only does anything when the den/num can be reduced, other times having no effect.
- x264_reduce_fraction( &h->param.i_fps_num, &h->param.i_fps_den );
+ //x264_reduce_fraction( &h->param.i_fps_num, &h->param.i_fps_den );
the framerate section of the sps of a PAL movie will take as many bits now as the sps of a NTSC movie. (negligible)

this should end the assert errors seen sometimes on PAL.

[froggy1]

Thanks Trahald, works nicely here ;)

[rack04]

x264 core:72 r1217M 32-bit

Download (http://www.megaupload.com/?d=GY10GX3F)

Built by rack04 on August 19, 2009, 2:05:45 PM CST
$ gcc --version
gcc.exe GCC: 4.4.1 (x86.core2.Komisar)
$ ./configure --extra-cflags="-march=core2"
Platform: X86
System: MINGW
asm: yes
avis input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
$ make fprofiled VIDS="bigbuckbunny.avs LosslessTouhou.avs riverbed.1920x1080.yuv"

Patched with:

x264_hrd_pd_interlace.16.diff (http://forum.doom9.org/showthread.php?p=1316462#post1316462)
x264_win_zone_parse_fix_06.diff (http://kemuri9.net/dev/x264/patches/x264_win_zone_parse_fix_06.diff)

[JEEB]

x264 r1217 64bit unpatched:
download (http://jeeb.fiveforty.jp/x264/revision1217/x264.exe) ; hash (http://jeeb.fiveforty.jp/x264/revision1217/x264.md5)

built on Aug 19 2009, gcc: 4.3.4 20090220 (prerelease) (x64.generic.Komisar)
fprofiled, otherwise defaults

________________________________________________________________________________

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

built on Aug 19 2009, gcc: 4.3.4 20090220 (prerelease) (x32.generic.Komisar)
fprofiled, -march=i686


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

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


patched with:

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


Changing dates is what I get from building stuff near midnight.

[JEEB]

x264 r1222 64bit unpatched:
download (http://jeeb.fiveforty.jp/x264/revision1222/x264.exe) ; hash (http://jeeb.fiveforty.jp/x264/revision1222/x264.md5)

built on Aug 20 2009, gcc: 4.3.4 20090220 (prerelease) (x64.generic.Komisar)
fprofiled, otherwise defaults

________________________________________________________________________________

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

built on Aug 20 2009, gcc: 4.3.4 20090220 (prerelease) (x32.generic.Komisar)
fprofiled, -march=i686


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

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


patched with:

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


Guess what is down again, m'kay~ and back up.

[techouse]

x264_x64_r1222_unpatched (http://techouse.project357.com/builds/revision1222/x264.exe) | MD5 (http://techouse.project357.com/builds/revision1222/x264.md5)
GCC 4.4.1 20090803 (x64.core2.Komisar), unpatched, generic, fprofiled

________________________________________________________________________________

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

x264_x64_r1222_techouse (http://techouse.project357.com/builds/x264_x64_r1222_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x64_r1222_techouse.txt)
GCC 4.4.1 20090803 (x86_64.core2.Komisar), fprofiled, -march=core2

Patches used:

x264_hrd_pd_interlace.16.diff
x264_win_zone_parse_fix_06.diff

[imk]

r1222M built with ICC.

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

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



On a side note, I started updating my benchmark spreadsheet with r1217.
x264 Benchmarks (http://spreadsheets.google.com/pub?key=pbffjdC6iUPWs2HtYHwZ2VQ&gid=4&hl=sv)

There's still some I need to finish up with the placebo test, but you can get an idea from all the other results.

If you don't understand what all of the numbers or headers mean, click on the "Information" label at the top.

[komisar]

My 1222 versions of x264:
http://komisar.gin.by/

In addition I published a gdb-6.8.50.20090821-cvs (32/64-bit) (http://komisar.gin.by/mingw/) (need more testing)

[alwa]

@imk:

Your x86 32Bit build doesn't work at all on system. If i want to start an encoding nothing happens, but the process keeps running with 25% cputime (single threaded) like in an infinite loop. I have a C2Q Q9550 E0 on Win 7 x64 RC. The 64Bit build works fine though, so it is nothing dramatic to me.

Edit: r1163 is the latest that works with me, but auto thread detection and the progress indicator do not work. I hope that helps in some way...

[imk]

@imk:

Your x86 32Bit build doesn't work at all on system. If i want to start an encoding nothing happens, but the process keeps running with 25% cputime (single threaded) like in an infinite loop. I have a C2Q Q9550 E0 on Win 7 x64 RC. The 64Bit build works fine though, so it is nothing dramatic to me.

Edit: r1163 is the latest that works with me, but auto thread detection and the progress indicator do not work. I hope that helps in some way...

Can you get on IRC and find me? I'd like to compile some builds with various settings and see which work and which do not.

If you have time, come find me on Freenode in #x264. I use the nick Dopefish there.

[Tarutaru]

x264 r1222 built with gcc 4.4.0 (http://www.mediafire.com/?jdytjlmw5ai)

Compiler options:

-march=i686 -msse4.2
with pthread, gpac
fprofiled


Patches:

x264_hrd_pulldown.16_interlace.diff
x264_win_zone_parse_fix_06.diff

[Wishbringer]

Tried encoding some PSP videos with imk build 1222 in MeGUI (manually copied x264 into folder).
x264 crashed each time.
Tried same with Techouse build 1222, no crashes...
On the other hand, imk 64bit in Ripbot264 works great, so problem seems to be in 32bit build.

[imk]

Yeah, all of the problems seem related specifically to the 32-bit build. It all started happening around the time MBTree got committed. You should be using the 64-bit build if you have a 64-bit OS anyway. ;)

When I get some time I'll try and make some debug builds so I can narrow down what's going on. The 32-bit build works fine during profiling and benchmarking, but aside from that, I haven't actually used the 32-bit build to encode anything.

[juGGaKNot]

Tried encoding some PSP videos with imk build 1222 in MeGUI (manually copied x264 into folder).
x264 crashed each time.
Tried same with Techouse build 1222, no crashes...


It seams that techouse's build also crashes for a friend, i told him to get the patched and unpatched builds from techouse and try --longhelp, reporting back soon.

LE :

techouse and imk crash
jeebs work

i will make a debug build tomorrow.

[juGGaKNot]

x264_r1232_juGGaKNot (http://www.mediafire.com/download.php?adm0owztnvk)
GCC 4.4.1, fprofiled, patched
Source: GIT

Applied patches :

x264_win_zone_parse_fix_06.diff (http://www.mediafire.com/download.php?w4y4mdzymgh)

Please check Doom9.org patches thread (http://forum.doom9.org/showthread.php?t=130364), and GIT shortlog (http://git.videolan.org/gitweb.cgi?p=x264.git;a=shortlog) for more info.

Compiled by juGGaKNot with GCC 4.4.1 on Windows XP SP-2 32-bit.

Platform: X86
System: MINGW
asm: yes
avis input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no

HRD needs to be updated again, Download link (http://www.mediafire.com/download.php?m4mxmr0uuzy)

[techouse]

I fixed the HRD patch so it works with r1232.

x264_hrd_pd_interlace.16.fix.1232.diff (http://pastebin.org/11898)

[imk]

r1232M built with ICC.

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

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

[juGGaKNot]

r1232M built with ICC.

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

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

if you use complete log you might also want to take a look at the console diff ( shows the encoding settings used in the cmd window )

[techouse]

x264_x64_r1232_unpatched (http://techouse.project357.com/builds/revision1232/x264.exe) | MD5 (http://techouse.project357.com/builds/revision1232/x264.md5)
GCC 4.4.1 20090803 (x64.core2.Komisar), unpatched, generic, fprofiled

________________________________________________________________________________

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

x264_x64_r1232_techouse (http://techouse.project357.com/builds/x264_x64_r1232_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x64_r1232_techouse.txt)
GCC 4.4.1 20090803 (x86_64.core2.Komisar), fprofiled, -march=core2

Patches used:

x264_hrd_pd_interlace.16.fix.1232.diff (http://pastebin.org/11898)
x264_win_zone_parse_fix_06.diff

[JEEB]

x264 r1232 64bit unpatched:
download (http://jeeb.fiveforty.jp/x264/revision1232/x264.exe) ; hash (http://jeeb.fiveforty.jp/x264/revision1232/x264.md5)

built on Aug 25 2009, gcc: 4.3.4 20090220 (prerelease) (x64.generic.Komisar)
fprofiled, otherwise defaults

________________________________________________________________________________

x264 r1232 32bit
download (http://jeeb.fiveforty.jp/x264/1232/x264.exe) ; release notes

built on Aug 25 2009, gcc: 4.3.4 20090220 (prerelease) (x32.generic.Komisar)
fprofiled, -march=i686


x264 r1232 64bit
download (http://jeeb.fiveforty.jp/x264/1232_x64/x264.exe) ; release notes

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


patched with:

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.fix.1232.diff (http://pastebin.org/11898)


I will upload release notes with the changelogs later on as I will have time :3 Nothing really has changed on that side, for the exception of the nal_hrd patch version of course, so I guess it's alright.

[rack04]

x264 core:72 r1232M x86

Download (http://www.mediafire.com/?sharekey=66628d7bf878e80e7432d3c9683f450ae04e75f6e8ebb871)

Built by rack04 on August 25, 2009, 9:20:51 AM CST
$ gcc --version
gcc.exe (GCC) 4.4.1 (x86.core2.Komisar)
$ ./configure --extra-cflags="-march=core2"
Platform: X86
System: MINGW
asm: yes
avis input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
$ make fprofiled VIDS="bigbuckbunny.avs LosslessTouhou.avs riverbed.1920x1080.yuv"

Patched with:

x264_hrd_pd_interlace.16.fix.1232.diff (http://pastebin.org/11898)
x264_win_zone_parse_fix_06.diff (http://kemuri9.net/dev/x264/patches/x264_win_zone_parse_fix_06.diff)

[JEEB]

x264 r1235 64bit unpatched:
download (http://jeeb.fiveforty.jp/x264/revision1235/x264.exe) ; hash (http://jeeb.fiveforty.jp/x264/revision1235/x264.md5)

built on Aug 27 2009, gcc: 4.3.4 20090220 (prerelease) (x64.generic.Komisar)
fprofiled, otherwise defaults

________________________________________________________________________________

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

built on Aug 27 2009, gcc: 4.3.4 20090220 (prerelease) (x32.generic.Komisar)
fprofiled, -march=i686


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

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


patched with:

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.fix.1232.diff (http://pastebin.org/11898)


A bit longer list this time since I just merged two changelogs >:3

[rack04]

x264 r1235M x86

Download (http://www.mediafire.com/?sharekey=3dd461e796995ebe1f8e0fff488e27e0e04e75f6e8ebb871)

Built by rack04 on August 27, 2009, 9:14:16 AM CST
gcc --version
gcc.exe (GCC) 4.3.4 20090526 (prerelease) (x86.core2.Komisar)
-march=core2
make fprofiled

Patched with:

x264_hrd_pd_interlace.16.fix.1232.diff (http://pastebin.org/11898)
x264_win_zone_parse_fix_06.diff (http://kemuri9.net/dev/x264/patches/x264_win_zone_parse_fix_06.diff)

[techouse]

x264_x64_r1235_unpatched (http://techouse.project357.com/builds/revision1235/x264.exe) | MD5 (http://techouse.project357.com/builds/revision1235/x264.md5)
GCC 4.4.1 20090803 (x64.core2.Komisar), unpatched, generic, fprofiled

________________________________________________________________________________

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

x264_x64_r1235_techouse (http://techouse.project357.com/builds/x264_x64_r1235_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x64_r1235_techouse.txt)
GCC 4.4.1 20090803 (x86_64.core2.Komisar), fprofiled, -march=core2

Patches used:

x264_hrd_pd_interlace.16.fix.1232.diff (http://pastebin.org/11898)
x264_win_zone_parse_fix_06.diff

[woah!]

x264_x64_r1235_unpatched (http://techouse.project357.com/builds/revision1235/x264.exe) | MD5 (http://techouse.project357.com/builds/revision1235/x264.md5)
GCC 4.4.1 20090803 (x64.core2.Komisar), unpatched, generic, fprofiled

________________________________________________________________________________

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

x264_x64_r1235_techouse (http://techouse.project357.com/builds/x264_x64_r1235_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x64_r1235_techouse.txt)
GCC 4.4.1 20090803 (x86_64.core2.Komisar), fprofiled, -march=core2

Patches used:

x264_hrd_pd_interlace.16.fix.1232.diff (http://pastebin.org/11898)
x264_win_zone_parse_fix_06.diff

i get this with you patched x86 version: unrecognised option `--nal-hrd'

rack04 version above you with same patches works ok...

[juGGaKNot]

32/64 bit ? are you sure you have the patched one ?

--longhelp

[woah!]

i said x86 patched version so 32bit patched...

rack04 has these options: --nal-hrd --pulldown

techouse's doesnt, and thats fine to know, so i will use another version which does.

[techouse]

I'm pretty sure I patched it, but I'll recheck my building scripts and report back later.

EDIT: You're right, I had a typo in my script and cause of that it didn't find the diff file. Thanx for noticing it :) ONLY my patched r1232 and r1235 builds are affected. I'm fixing/rebuilding r1235 now.

[woah!]

np ... i am guessing anyone who does bluray stuff would have said something soon enough too :)

[techouse]

Fixed. :)

[moviefan]

What I have been wondering about is:

--march=i686/core2/... - What is the difference?
--fprofiled: What is this for?

[kemuri-_9]

--march=i686/core2/... - What is the difference?

march=i686 is used by default to have gcc use the cmov instruction which speeds up some of the c code a bit here and there.
core2 does just about nothing; it's mostly used to have gcc schedule tasks in way that's optimal for core2 as the instructions barely differ from that of march=i686.

--fprofiled: What is this for?

fprofiled is a scheme that you compile a program with that capability, execute it, and then recompile it optimizing based on which code paths were executed the most/least from your executions.
other compilers can have different names for such a feature, but gcc's is called 'fprofile'.

[LoRd_MuldeR]

Profiling means that the application is analyzed while it's executing and processing "real" input data. The info collected during the profiling process can be used by the compiler to enable additional optimizations (or to enable the optimizations in parts of the program where they are really needed). Compiling x264 with fprofiled takes much longer than without, because the binary is compiled twice (once before the profiling and again after the profiling is completed). Also you need to provide a sample video clip that will be encoded several times (with different settings in order to cover all code paths) during the profiling process...

[moviefan]

OK, very interesting! Thanks for the explanations!

[JEEB]

x264 r1239 64bit unpatched:
download (http://jeeb.fiveforty.jp/x264/revision1239/x264.exe) ; hash (http://jeeb.fiveforty.jp/x264/revision1239/x264.md5)

built on Aug 29 2009, gcc: 4.3.4 20090220 (prerelease) (x64.generic.Komisar)
fprofiled, otherwise defaults

________________________________________________________________________________

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

built on Aug 29 2009, gcc: 4.3.4 20090220 (prerelease) (x32.generic.Komisar)
fprofiled, -march=i686


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

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


patched with:

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.fix.1232.diff (http://pastebin.org/11898)

[rack04]

x264 r1239M x86

Download (http://www.mediafire.com/?sharekey=23986c34d519238b2fb2ca15d7ea42d9e04e75f6e8ebb871)

Built by rack04 on August 28, 2009, 10:13:17 PM CST
GCC 4.3.4 20090526 (prerelease) (x86.core2.Komisar)
-march=core2
fprofiled

Patched with:

x264_hrd_pd_interlace.16.fix.1232.diff (http://pastebin.org/11898)
x264_win_zone_parse_fix_06.diff (http://kemuri9.net/dev/x264/patches/x264_win_zone_parse_fix_06.diff)

[buzzqw]

for any interest

http://www.64k.it/andres/data/x264/x264.1239.x86.tar.gz

gcc 4.4.1

$ ./configure
Platform: X86
System: LINUX
asm: yes
avis input: no
mp4 output: yes
pthread: yes
matroska: yes

Patched with: x264_hrd_pd_interlace.16.fix.1232.diff (http://pastebin.org/11898)

BHH

[rack04]

x264 r1240M x86

Download (http://www.megaupload.com/?d=TO4FKXQ9)

Built by rack04 on August 29, 2009, 1:39:08 PM CST
GCC 4.3.4 20090526 (prerelease) (x86.core2.Komisar)
-march=core2
fprofiled

Patched with:

x264_hrd_pd_interlace.16.fix.1232.diff (http://pastebin.org/11898)
x264_win_zone_parse_fix_06.diff (http://kemuri9.net/dev/x264/patches/x264_win_zone_parse_fix_06.diff)

[JEEB]

x264 r1240 64bit unpatched:
download (http://jeeb.fiveforty.jp/x264/revision1240/x264.exe) ; hash (http://jeeb.fiveforty.jp/x264/revision1240/x264.md5)

built on Aug 30 2009, gcc: 4.3.4 20090220 (prerelease) (x64.generic.Komisar)
fprofiled, otherwise defaults

________________________________________________________________________________

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

built on Aug 30 2009, gcc: 4.3.4 20090220 (prerelease) (x32.generic.Komisar)
fprofiled, -march=i686


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

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


patched with:

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.fix.1232.diff (http://pastebin.org/11898)


________________________________________________________________________________

And something deeply experimental.

x264 r1240 with MixAQ and OreAQ patches: download (http://jeeb.fiveforty.jp/x264/1240/x264_aqpatches.7z)

built on Aug 30 2009, gcc: 4.3.4 20090220 (prerelease)
fprofiled, default CPU flags, --extra-ldflags="-lz"


Patched with the patches:

The stuff applied on the patched builds
x264_OreAQ12_r1240.diff (http://jeeb.pastebin.ca/1547857)
x264_MixAQ_r1240.diff
(http://jeeb.pastebin.ca/1547858)


If you plan on building, the file 'AQDebugLog.h' has to be in the root of your x264 codebase:

for OreAQ (http://jeeb.pastebin.ca/1547807)
for MixAQ (http://jeeb.pastebin.ca/1547805)


These patches are made by Seraphy and Muken AKA VFR Maniac, each developing their own versions and VFR Maniac updating the standard patches for newer revisions. And yes, the patches seem to need zlib. Tobinaka has written some articles on these AQ modes on Doom9, so please search for his posts if you have any basic questions on the patches, and please do report any findings if you decide to test these builds.

Also, I took these patches in this time because of the large amount of interest they have gathered in Japan overall. Personally I didn't dislike what an older MixAQ build did with the blackpearl sequence on 500kbps, but otherwise I'm not saying any of these patches greatly increases quality or something like that. Isn't it fun to have something not-so-usual on your hands?

[VFR maniac]

Hi, JEEB.
I updated OreAQ qp_adj calculation according to rev1236.

Please check below.
http://seraphy.fam.cx/~seraphy/cgi-bin/cbbs.cgi?mode=one&namber=2269

Edit: Woops! I passed by you.

[JEEB]

Yes, thank you. Didn't see that before my builds completed and I had revisited your site after writing my post. I had gotten info on you not updating the patch for 1239 so I kind of skipped the pre-checking phase, putting my bad(?) edit into the first, pre-edit builds. Oh well, won't happen again.

[juGGaKNot]

http://www.esnips.com/nsdoc/7a9f4e8d-75cf-4258-89a6-0c5725bb5534/?action=forceDL

what about this ? usable ?

[JEEB]

Since that URL keeps redirecting me to the login screen, I can't tell for sure, but I guess that's a link for VFR_Maniac's own builds. They contain much more patches, I have only added the most basic ones into mine that were available. Also, if that's the OreAQ_frame_edge one I guess that's something even newer. Feel free to test whichever build works for you and how they work.

[juGGaKNot]

http://www.esnips.com/web/x264experimental

a weightp diff

[techouse]

x264_x64_r1240_unpatched (http://techouse.project357.com/builds/revision1240/x264.exe) | MD5 (http://techouse.project357.com/builds/revision1240/x264.md5)
GCC 4.4.1 20090803 (x64.core2.Komisar), unpatched, generic, fprofiled

________________________________________________________________________________

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

x264_x64_r1240_techouse (http://techouse.project357.com/builds/x264_x64_r1240_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x64_r1240_techouse.txt)
GCC 4.4.1 20090803 (x86_64.core2.Komisar), fprofiled, -march=core2

Patches used:

x264_hrd_pd_interlace.16.fix.1232.diff (http://pastebin.org/11898)
x264_win_zone_parse_fix_06.diff

[JEEB]

For weightp I would recommend the usage of the git repository rather than random patches since I do not know of any official diff releases (no bad intent to VFR maniac, but since A) the weightp repository is up-to-date atm and because B) it has the newest changes I'd consider it a better option than any patches floating around).

Of course goes without saying that the weightp functionality is heavily under construction at the moment, so I'd rather not make any larger perceptions by looking at the current state of the repo / any patch that might be based on an older revision from the same repo. To have interest in that functionality is completely normal, though.

[G_M_C]

For weightp I would recommend the usage of the git repository rather than random patches since I do not know of any official diff releases (no bad intent to VFR maniac, but since A) the weightp repository is up-to-date atm and because B) it has the newest changes I'd consider it a better option than any patches floating around).

Of course goes without saying that the weightp functionality is heavily under construction at the moment, so I'd rather not make any larger perceptions by looking at the current state of the repo / any patch that might be based on an older revision from the same repo. To have interest in that functionality is completely normal, though.

Isn't is just better to wait untill Dark Shikari gives the OK on this ? He is the GSoC mentor on this project AFAIK, so he can judge the state of this best. He also has the better overview on the whole codebase, maybe the weightp patch breaks things we cannot oversee or or simply dont know about.

But speaking personally; I cant wait to see the results of weightp either ;)

[JEEB]

Yes, I was trying to hint at just that while remaining at the pose of "But if you wish as much as to apply something like that, at least use the newest revision officially available."

[kemuri-_9]

from the current progression of talk in the dev channel
the 3 patches mentioned below will seemingly be committed in the following order:

slicing support, threaded slicetype, weightp
each one breaks a small or decent bit of something for what's following it, so it's going to be a bit longer before weightp will see the main repository

[Razorholt]

x264_x64_r1240_unpatched (http://techouse.project357.com/builds/revision1240/x264.exe) | MD5 (http://techouse.project357.com/builds/revision1240/x264.md5)
GCC 4.4.1 20090803 (x64.core2.Komisar), unpatched, generic, fprofiled

________________________________________________________________________________

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

x264_x64_r1240_techouse (http://techouse.project357.com/builds/x264_x64_r1240_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x64_r1240_techouse.txt)
GCC 4.4.1 20090803 (x86_64.core2.Komisar), fprofiled, -march=core2

Patches used:

x264_hrd_pd_interlace.16.fix.1232.diff (http://pastebin.org/11898)
x264_win_zone_parse_fix_06.diff

Hi Techouse -

Just so you know, that build (x86) makes x264.exe crash on the second pass - at least for me. When I try earlier versions or any other builds from other folks they are running fine. :o

Thanks,
- Dan

UPDATE: It works now, but after I changed the SetMTmode() setting from "1,2" to "2". I don't know what happened here.

[G_M_C]

from the current progression of talk in the dev channel
the 3 patches mentioned below will seemingly be committed in the following order:

slicing support, threaded slicetype, weightp
each one breaks a small or decent bit of something for what's following it, so it's going to be a bit longer before weightp will see the main repository

I suspected as much, as i wrote before.

Isn't is just better to wait untill Dark Shikari gives the OK on this ? He is the GSoC mentor on this project AFAIK, so he can judge the state of this best. He also has the better overview on the whole codebase, maybe the weightp patch breaks things we cannot oversee or or simply dont know about.
[...]


But all three patches/additions you mention will provide big steps forward. x264 is taking great steps in growing towards it's full potential it seems. I think that these are exiting times to be around seeing this happening, and actually be able to take advantage of x264 while its becoming this good :)

[wyti]

sorry for the noob question, but what is threaded slicetype and what will it do quality / speed wise ?

[JEEB]

Threaded slicetype can be dumb'ified as "multithreaded b-adapt 2" I guess, although writing it like this _is_ cutting around corners and isn't the right way.

[shon3i]

can somebody provide new build since slices added? aslo with HRD patch for full BD compilancy :)

[imk]

r1243M built with ICC.

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

Patches used:
x264_icc_08_win.diff
x264_win_zone_parse_fix_06.diff


The HRD patch will need updated. It fails to patch currently. I'll rebuild later when the patch gets updated.

[kemuri-_9]

Threaded slicetype can be dumb'ified as "multithreaded b-adapt 2" I guess, although writing it like this _is_ cutting around corners and isn't the right way.

no that 'dumbification' is actually inappropriate to how it works.

the patch adds a new thread that is persistent throughout the entire code that is dedicated to performing slicetype decisions only.
this does not multi-thread slicetype, but gives it its own HIGH priority dedicated thread just for it.
this would be a stepping stone to multi-threading it.

on average the speedup from this is 5-10%
but from testing some fairly bizarre combinations of settings, the highest i've seen the encoding rate increase was ~56%

[JEEB]

I gave it a slight try (http://pastebin.ca/1549778) (NAL HRD - x264_hrd_pd_interlace.16.fix.1243.test.diff)

It sure as hell builds, looks quite close to what it was and encodes the fprofile things, but I have no idea if it does its job correctly with the newer changes. Also I'll have to see how much modification the open gop patch will need... (once again I have no idea if it will work correctly even if I get to change it correctly).

[techouse]

Yea, I'd also rather wait for the author of the HRD patch to take a look at it before building anything...

[JEEB]

Indeed, I got the open gop patch to build as well with a modified patch, but since the internals have changed this (http://pastebin.ca/1549828) (done from a NAL_HRD patched one) as well can only be viewed as nothing more but a little plaything before the maker of these patches comes to the end of modifying them for the current revision with the added slices. :)

EDIT：

Here's the unpatched build for the time being (64bit, r1243, fprofiled, default configure):
download (http://jeeb.fiveforty.jp/x264/revision1243/x264.exe) ; md5 hash (http://jeeb.fiveforty.jp/x264/revision1243/x264.md5)

[techouse]

x264_x64_r1243_unpatched (http://techouse.project357.com/builds/revision1243/x264.exe) | MD5 (http://techouse.project357.com/builds/revision1243/x264.md5)
GCC 4.4.1 20090803 (x64.core2.Komisar), unpatched, generic, fprofiled

________________________________________________________________________________

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

x264_x64_r1243_techouse (http://techouse.project357.com/builds/x264_x64_r1243_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x64_r1243_techouse.txt)
GCC 4.4.1 20090803 (x86_64.core2.Komisar), fprofiled, -march=core2

Patches used:

x264_win_zone_parse_fix_06.diff

[VFR maniac]

x264_x86_r1243_with_nal-hrd.rar (http://www.esnips.com/doc/bd9f9d67-2923-4b00-9343-966f04ee7297/x264_x86_r1243_with_nal-hrd)
Please use slices + nal-hrd at your own risk.

[shon3i]

why at risk?

[JEEB]

As the comment on the file says, he thinks he has fixed the patch in its current form for building and has built a binary, but he is not sure if it works correctly with slices on. VFR Maniac has much more knowledge than I do therefore if you're going to try, you could do it with his build or by building with his patch instead of what I quickly threw together last night.

In other words, so far every mod. patch is just something that makes the current revision of the patch to work with the current revision of x264. Actual computation and modification to work 100% correctly with slices hasn't been taken into account. For that we wait for the next revision that might come up sooner or later.

[G_M_C]

I vote for that we wait on Tharald fixing this (his ?) patch ;)

[kemuri-_9]

I vote for that we wait on Tharald fixing this (his ?) patch ;)

It is Trahald's, but it seems that him and Dark_Shikari are going about getting MMCO into the main repository to fix the issue with x264's b-pyramid.
so the nal-hrd patch is seemingly on the back burner for a bit.

[moviefan]

Can anyone tell, if the b-pyramid fix, that is being worked on, is going to be Blu-ray compliant afterwards? I ran about some comments about x264's b-pyramid being different from the Blu-ray spec's way of doing b-pyramid. (maybe a bit unprofessionally described, but I don't know about this stuff in detail)

[froggy1]

@moviefan

are you referring to the level of hierarchical b-pyramid implementations or something else? Also, as it now stands, x264 will in the future enforce strictdpb which will be builtin (no option to disable it) in order to comply as much as possible when using the b-pyramid option

[G_M_C]

It is Trahald's, but it seems that him and Dark_Shikari are going about getting MMCO into the main repository to fix the issue with x264's b-pyramid.
so the nal-hrd patch is seemingly on the back burner for a bit.

No matter, i'll wait for his fix rather than we (or anyone else) fixing it, and possibly unintentionally breaking something else :)

[LoRd_MuldeR]

Can anyone tell, if the b-pyramid fix, that is being worked on, is going to be Blu-ray compliant afterwards? I ran about some comments about x264's b-pyramid being different from the Blu-ray spec's way of doing b-pyramid. (maybe a bit unprofessionally described, but I don't know about this stuff in detail)

As far as I know, there's no such thing as "B-Pyramid" in the H.264 standard or in the BD specs.

B-Pyramid is just x264's implementation of "hierarchical B-Frames", but there is no limitation in the standard that says that the hierarchy must be a pyramid.

However there seems to be a problem with the way x264 manages the buffered reference frames, which can break Level compliance...

[moviefan]

Yep, something like that... As I said, I don't know details, but as you are talking about breaking the decoding buffer limit, this is something I can recall. So it would be good if b-pyramids do not break the buffer limits as I think they can be beneficial for compression sometimes.