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.

[microchip8]

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)

[microchip8]

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

[LoRd_MuldeR]

So it would be good if b-pyramids do not break the buffer limits as I think they can be beneficial for compression sometimes.

Well, if froggy1 is right, then this will be fixed soon (see post above).

[rack04]

x264 r1243M x86 (http://www.mediafire.com/?sharekey=b485039630a911f1d0d290dca69ceb5ce04e75f6e8ebb871)

Built by rack04 on September 1, 2009, 10:48:41 AM CST
gcc --version
gcc.exe (GCC) 4.3.4 20090526 (prerelease) (x86.core2.Komisar)
-march=core2
make fprofiled

Patched with:

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

[Lyris]

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.
Muxes successfully with DoStudio Authoring Edition 1.8 Trial without any buffer underflow errors (I got those using just "plain" X264 without the Nal-hrd patch applied and had no luck compiling myself). Doesn't mean that it's fully complaint of course, but it's a very good indicator.

[Tarutaru]

x264 0.75.1246M 5b3c89c (http://www.mediafire.com/?fwmnzlhdrea)

gcc options:

built with gcc: 4.4.1 (x86.core2.Komisar)
-march=core2
-msse4.2
fprofiled


patched with:

x264_win_zone_parse_fix_06.diff

[juGGaKNot]

hrd broken again ?

x264 0.75.1246M 5b3c89c (http://www.mediafire.com/?fwmnzlhdrea)

gcc options:

built with gcc: 4.4.1 (x86.core2.Komisar)
-march=core2
-msse4.2
fprofiled


patched with:

x264_win_zone_parse_fix_06.diff


crashed on startup ( after 60 frames, lookahead for veryslow preset )

building my own without -march=core2, this seems to be the constant problem since 1222

LE :

The mentioned build didn't include nal-hrd patch...

that was a later edit, i do not use hrd. Compiled with same patch as he did, no -march, works fine, don't know why, for me and ~4 people the core2 builds crash, when i do not compile myself i use jeebs.

There is no crashes for me...
Anyway, this built with no -march flag.
x264 0.75.1246M 5b3c89c (http://www.mediafire.com/?kmzgzwhwmju)

same crash, so its not the march, mine works.

[Wishbringer]

hrd broken again ?

crashed on startup

The mentioned build didn't include nal-hrd patch...

[Tarutaru]

hrd broken again ?



crashed on startup ( after 60 frames, lookahead for veryslow preset )

building my own without -march=core2, this seems to be the constant problem since 1222

There is no crashes for me...
Anyway, this built with no -march flag.
x264 0.75.1246M 5b3c89c (http://www.mediafire.com/?kmzgzwhwmju)

[juGGaKNot]

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

Applied patches :

x264_win_zone_parse_fix_06.diff (http://www.mediafire.com/download.php?w4y4mdzymgh)
x264_hrd_pd_interlace.16_r1243.diff (http://www.mediafire.com/download.php?ymi3wyggmxm)

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, ./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

[juGGaKNot]

x264_r1247_juGGaKNot (http://www.mediafire.com/download.php?eocyy13wzzz), GCC 4.4.1, generic, fprofiled, patched, threaded lookahead fix.
Source: GIT

Applied patches :

x264_win_zone_parse_fix_06.diff (http://www.mediafire.com/download.php?w4y4mdzymgh)
x264_hrd_pd_interlace.16_r1243.diff (http://www.mediafire.com/download.php?ymi3wyggmxm)

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, ./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

[JEEB]

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

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

________________________________________________________________________________

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

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


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

built on Sep 3 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.1247.VFRManiac.diff (http://jeeb.pastebin.ca/1552607) (picked it from his 1247 release, and, as it had no specific version number I just added the one I took it from)


Nal-hrd with with slices is not guaranteed to be spec-complying, otherwise it should do the same thing as always. If you don't use nal-hrd at all it should be safe as well.

[rack04]

x264 r1247M x86 (http://www.mediafire.com/?sharekey=10ea7a9fffe22e4f6b21be4093fab7ace04e75f6e8ebb871)

Built by rack04 on September 3, 2009, 9:05:49 AM CST
gcc --version
gcc.exe (GCC) 4.3.4 20090526 (prerelease) (x86.core2.Komisar)
-march=core2
make fprofiled

Patched with:

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

[techouse]

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

________________________________________________________________________________

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

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

Patches used:

x264_win_zone_parse_fix_06.diff

[Trahald]

Here is hrd-pd-interlace version 17. updated using 1246 (will patch to 1247 since didnt change much)

[G_M_C]

Here is hrd-pd-interlace version 17. updated using 1246 (will patch to 1247 since didnt change much)

Super, thx :)

Will try making new BD's for my BD30 now. See if slicing (plus nal-hrd) makes a noticeable difference (suspect not, but at least they are "compliant") :)

[Trahald]

Oh and the other patch probably should have been fine (I didn't look at the code.) Slices dont have an impact on dpb_output_delay and cpb_removal_delay calculation. Slices add some overhead, but x264 already accounts for that so that information is passed to the patch.

[XhmikosR]

Has anybody compiled r1247 with x264_hrd_pd_interlace.17 patch and encode something? It gives me an output video which has very low bitrate, like 75Kbps. If I compile x264 without v17 of the x264_hrd_pd_interlace, then the output video is fine.

[kemuri-_9]

Has anybody compiled r1247 with x264_hrd_pd_interlace.17 patch and encode something? It gives me an output video which has very low bitrate, like 75Kbps. If I compile x264 without v17 of the x264_hrd_pd_interlace, then the output video is fine.


clean git:
x264 [info]: frame I:2 Avg QP:15.75 size: 2118 PSNR Mean Y:74.50 U:78.31 V:76.37 Avg:75.08 Global:53.17
x264 [info]: frame P:126 Avg QP:27.38 size: 4091 PSNR Mean Y:42.89 U:47.43 V:46.95 Avg:43.81 Global:42.82
x264 [info]: frame B:172 Avg QP:31.00 size: 434 PSNR Mean Y:41.85 U:45.69 V:45.32 Avg:42.68 Global:42.27

w/ hrd pd:
x264 [info]: frame I:2 Avg QP:15.75 size: 15710 PSNR Mean Y:74.50 U:78.31 V:76.37 Avg:75.08 Global:53.17
x264 [info]: frame P:126 Avg QP:27.38 size: 46819 PSNR Mean Y:42.89 U:47.43 V:46.95 Avg:43.81 Global:42.82
x264 [info]: frame B:172 Avg QP:31.00 size: 47128 PSNR Mean Y:41.85 U:45.69 V:45.32 Avg:42.68 Global:42.27

something is obviously busted with the frame stats there, even when not using vbv, though everything else is seemingly normal... in this case

patch also broke vbv as on my sample which has 0 underflows with on clean git,
reports an underflow for ~92% of the frames with the patch.
the final output rate with the patch is also about 25% of what it is with clean git when using vbv.
so yeah, the patch is highly broken, don't use it.

[XhmikosR]

Alright, I thought it was something wrong with my builds.

[Trahald]

*sigh* well.. at least everyone has learned to test my patches before posting binaries. I'll get on it.

[Trahald]

I initiated the variable that tracks the size of the current frame in the AUD if statement. so using anyone using --aud would have be fine. w/out it, the variable got exponantially bigger so ratecontrol would think it was getting humungous frames and eventially wasnt able to compensate. i tested with --aud so never caught it. anywho... its fixed. feel free to scrutinize this one before using.

[XhmikosR]

Thank you. Now everything seems to work as usual from my (limited) tests.

[rack04]

x264 r1251M x86 (http://www.mediafire.com/?sharekey=50a56bc048c2cc94d1014a7a667fa2b4e04e75f6e8ebb871)

Built by rack04 on September 6, 2009, 2:06:54 PM CST
GCC 4.3.4 20090526 (prerelease) (x86.core2.Komisar)
-march=core2
fprofiled

Patched with:

x264_hrd_pd_interlace.18.diff (http://forum.doom9.org/showthread.php?p=1322564#post1322564)
x264_win_zone_parse_fix_06.diff (http://kemuri9.net/dev/x264/patches/x264_win_zone_parse_fix_06.diff)

[JEEB]

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

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

________________________________________________________________________________

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

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


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

built on Sep 6 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.19.diff


2009/09/09: Updated the hrd_pd_interlace patch to v1⑨.

[imk]

r1251M built with ICC.

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

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

[techouse]

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

________________________________________________________________________________

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

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

Patches used:

x264_win_zone_parse_fix_06.diff
x264_hrd_pd_interlace.19.diff

[VFR maniac]

Hi Trahald.
I found the streams encoded with x264_hrd_pd_interlace.18.diff make avinaptic display the error.
Is this safe?

Edit: I heard that PSP cannot play that streams.

[mister_no]

Hi Trahald.

I get the error: Assertion failed: dpb_output_delay < pow( 2, sps->vui.nal_hrd_parameters.i_dpb_output_delay_length ), file encoder/set.c, line 652

It is the same error as here (you fixed it): http://forum.doom9.org/showthread.php?p=1316462#post1316462

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.

[shon3i]

Hmm this is strange even MUI Generator reject streams with 264_hrd_pd_interlace.18.diff. What is problem ??

[foxyshadis]

Has anyone made a build with Trahald's b-pyramid/open gop patches? The latest one is on the mailing list, I was interested in trying it but don't have a build environment set up where I am.

[Chengbin]

This question has probably been answered, but please forgive me for not having the time/patience to read 100+ pages :)

Why aren't the patches incorporated into x264 permanently? Is there some sort of problem? Does compiling a patch break anything in x264? Otherwise I don't see a reason (unless someone point it out) to bother a few people here to compile a build every time x264 updates, and x264 updates quite often.

[Dark Shikari]

This question has probably been answered, but please forgive me for not having the time/patience to read 100+ pages :)

Why aren't the patches incorporated into x264 permanently? Is there some sort of problem? Does compiling a patch break anything in x264? Otherwise I don't see a reason (unless someone point it out) to bother a few people here to compile a build every time x264 updates, and x264 updates quite often.Because we're working on it.

[kemuri-_9]

patches are not committed if they don't satisfy a few conditions:
1. It is completely stable (that is it doesn't crash, and it is deterministic in the generated output)
2. It is deemed necessary or useful by the main devs
3. "magical code" is not accepted - that is the maintainer has to know what the code does and why; hacking something together that 'seems' to work without knowing why is not accepted.
4. the code meets the cosmetic standards of x264.

most patches generally fail one of these conditions.

[juGGaKNot]

What about win_zone_parse_fix

i know you use linux and its useless + its the compilers fault but isn't it a quick fix ?

[nakTT]

Hi all. I have a question,

What actually is the difference between Jeeb's patched build and the one that we can get from http://x264.nl/ website?

[J_Darnley]

The patches he applies, and possibly CFLAGS he uses. For his unpatched builds, only the compiler differs.

[kemuri-_9]

What about win_zone_parse_fix

i know you use linux and its useless + its the compilers fault but isn't it a quick fix ?

I use windows primarily, but the patch fails condition #2.

Hi all. I have a question,

What actually is the difference between Jeeb's patched build and the one that we can get from http://x264.nl/ website?

x264.nl provides unpatched builds, so read JEEB's posts to see what his builds are patched with.

[nakTT]

The patches he applies, and possibly CFLAGS he uses. For his unpatched builds, only the compiler differs.


x264.nl provides unpatched builds, so read JEEB's posts to see what his builds are patched with.
I see. Thanks you two.

[juGGaKNot]

if it is not useful whats the point of patching each version with it .....

[Selur]

2. It is deemed necessary or useful by the main devs
not you or a someone building it's own x264 Version ;)

[mopurist]

I know these are stupid questions, as my knowledge of the inner workings of x264 is nil, but...

What is this actually telling me?
x264_sei_picture_timing_write: Assertion `dpb_output_delay < pow( 2, sps->vui.nal_hrd_parameters.i_dpb_output_delay_length )' failed.
(received with r1247 and 1251 builds patched with x264_hrd_pd_interlace.18.diff when using --nal-hrd and specifying --vbv-bufsize and --vbv-maxrate on linux 64-bit)

If I omit vbv-bufsize and vbv-maxrate, x264 doesn't die, but it warns me that NAL HRD requires specifying vbv-maxrate and vbv-bufsize.

So what are sane values for vbv-maxrate and vbv-bufsize when trying to maintain ps3 compatibility? (if it matters, bitrate is usually around 9000). I have tried many combinations from 10000/10000, to 50000/62500.

Thanks!!!

[Trahald]

/me shifts deletes notepad++ -- heres 19

[rack04]

x264 r1251M x86 (http://www.megaupload.com/?d=B2KDOI1F)

Built by rack04 on September 8, 2009, 2:47:19 PM CST
gcc --version
gcc.exe (GCC) 4.3.4 (x86.core2.Komisar)
--extra-cflags="-march=core2"
make fprofiled

Patched with:

x264_hrd_pd_interlace.19.diff (http://forum.doom9.org/showthread.php?p=1323313#post1323313)
x264_win_zone_parse_fix_06.diff (http://kemuri9.net/dev/x264/patches/x264_win_zone_parse_fix_06.diff)

[shon3i]

Thanks rack04, testing right now to see is hal hrd fixed propertly :)

[JEEB]

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

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


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

built on Sep 9 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.19.diff


2009/09/09: Updated the hrd_pd_interlace patch to v1⑨.

Updated the patched builds to the newest version as for the hrd patch goes.
Also, happy ⑨ day everyone, I hope you all find your strongest side today.

[laserfan]

Updated the patched builds to the newest version as for the hrd patch goes.
Also, happy ⑨ day everyone, I hope you all find your strongest side today.Many thanks for your builds JEEB, and happy day to you too! :)

[rack04]

Can someone point me to a post that explains what 01_x264_custom_strtok_r.r1089.diff does? I did a search but it didn't come up with anything. Thanks.

[juGGaKNot]

for correct parsing options like "--zones x1,y1,q=26/x2,y2,b=0.5..."

[G_M_C]

for correct parsing options like "--zones x1,y1,q=26/x2,y2,b=0.5..."

Isn't that the x264_win_zone_parse_fix_06.diff ?

[rack04]

Isn't that the x264_win_zone_parse_fix_06.diff ?

Found this (http://forum.doom9.org/showthread.php?p=1211858#post1211858) post that explains the difference.

[G_M_C]

Found this (http://forum.doom9.org/showthread.php?p=1211858#post1211858) post that explains the difference.

Thx, they both (try to) fix the same thing ;)

[moviefan]

The nal-hrd patch hasn't been fixed properly. I used JEEB's updated patched build of rev. 1251 (32 bit) and got the following error after something around 100k frames (so not right at the beginning of the process):

"Assertion failed: dpb_output_delay < pow( 2, sps->vui.nal_hrd_parameters.i_dpb_output_delay_length ), file encoder/set.c, line 652"

I hope this information helps to debug the nal-hrd patch.

[shon3i]

I use rack04 buld and i not get those errors, i encode almost ten different sources with various VBV settings.

What is you cmd?

[Atak_Snajpera]

I have user with the same problem (http://forum.doom9.org/showthread.php?p=1324157#post1324157)

[G_M_C]

The nal-hrd patch hasn't been fixed properly. I used JEEB's updated patched build of rev. 1251 (32 bit) and got the following error after something around 100k frames (so not right at the beginning of the process):

"Assertion failed: dpb_output_delay < pow( 2, sps->vui.nal_hrd_parameters.i_dpb_output_delay_length ), file encoder/set.c, line 652"

I hope this information helps to debug the nal-hrd patch.

Did you also use --aud in your commandline ? (Tharald commented some days ago about that).

[kemuri-_9]

Did you also use --aud in your commandline ? (Tharald commented some days ago about that).

the --aud issue was supposedly fixed from v17 to v18, who knows if it made it's way back in for v19 tho.

[moviefan]

Did you also use --aud in your commandline ? (Tharald commented some days ago about that).

Yes, I did use --aud and I used a Blu-ray compliant Level 4.0 command line that had been working with revisions before. I will try rack04's build as shon3i stated it should work fine.

[Trahald]

@moviefan
can you give a command line. ive encoded 250k frames and could not duplicate. i also need to know the input frame rate. (the top over bottom , ex. 25000/1000) that the .avs file (or whatever your source method is) is outputing .. see if putting a framerate in your .avs (24000/1001 ; 25000/1000 ; 30000/1001 ) if that helps. the pts variable may be overflowing. (which is something id need to fix)

[moviefan]

Sure, my command line for the 2nd pass was:
--threads auto --thread-input "%IN_TITLE%.avs" --stats "%IN_OUTPUT%.stats" --output "%IN_OUTPUT%.264" --pass 2 --bitrate 6050
--level 4.0 --vbv-bufsize 30000 --vbv-maxrate 24000 --keyint 24 --min-keyint 2 --aud --sar 1:1 --bframes 3 --ref 3 --no-mixed-refs
--no-fast-pskip --ipratio 1.4 --pbratio 1.3 --direct auto --subme 10 --trellis 2 --partitions all --8x8dct --me umh --merange 32
--mvrange 511 --aq-mode 2 --aq-strength 1.0 --qcomp 0.6 --weightb --psy-rd 1.00:0.15 --nal-hrd --deblock -1:-1 --qpfile qpfile.txt
The command line for the 1st pass is identical except for --output null of course and I used --slow-firstpass. The frame rate x264 shows is 23.98fps, actually it is 24000/1001 fps. Right now, I am trying rack04's build of rev. 1251 and there hasn't been an error yet. However, last time (with the same source), the error was a couple of thousand frames ahead from now so I'll see soon if the error repeats.

[woah!]

--aq-strength 1.0 --8x8dct --ipratio 1.4 --pbratio 1.3 --qcomp 0.6 --weightb --bframes 3 --ref 3 <--- these are all default settings you dont need to write them in your cmd line at all...

[kemuri-_9]

--qpfile qpfile.txt

and the contents of that qpfile?

[moviefan]

... <--- these are all default settings you dont need to write them in your cmd line at all... I know, but I like to be explicit about things when I don't read latest changes in which defaults may have changed.

and the contents of that qpfile? The contents have been generated by "qpfilegen" (latest version) and contain the frames which should be I-frames for correct chapter marks. I have done another encode like this a few days ago with (I think) revision 1247 and that worked.

Edit: The same error occured again last night, I just noticed it, and this time I encoded with rack04's build. Something must be wrong...

[nakTT]

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

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

________________________________________________________________________________

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

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


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

built on Sep 6 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.19.diff


2009/09/09: Updated the hrd_pd_interlace patch to v1⑨.
Hi,

Sorry for being noob. May I know what is the different (in english) between your patched build and the unpatched build (http://x264.nl/)? Any impact in quality, speed or anything? Thank you in advance.

:thanks:

[shon3i]

Difference is in patches, unpached buld not use patches while JEEB buld have this patched applyed on unpached source:

* x264_win_zone_parse_fix_06.diff
* x264_hrd_pd_interlace.19.diff

This paches have no effect on speed or quality.

[LoRd_MuldeR]

Different compiler version (GCC 4.3.4 -vs- 3.4.6), different compiler optimizations ("-march=core2" -vs- none) and unofficial patches included (HRD patch and Zone-Parse Fix patch).

[nakTT]

Difference is in patches, unpached buld not use patches while JEEB buld have this patched applyed on unpached source:

* x264_win_zone_parse_fix_06.diff
* x264_hrd_pd_interlace.19.diff

This paches have no effect on speed or quality.
What is the effect then? Thank you in advance.

:thanks:

Different compiler version (GCC 4.3.4 -vs- 3.4.6), different compiler optimizations ("-march=core2" -vs- none) and unofficial patches included (HRD patch and Zone-Parse Fix patch).
In english please (I'm not a programmer). Thank you in advance.

:thanks:

[Dark Shikari]

What is the effect then? Thank you in advance.

:thanks:


In english please (I'm not a programmer). Thank you in advance.

:thanks:Use search and stop asking stupid questions that have been answered dozens of times before.

[nakTT]

Use search and stop asking stupid questions that have been answered dozens of times before.
Why do you think I ask? You can just ignore the question if you don't want to answer. Thank you very much.



To avoid anyone else from getting mad at me, I will quit from this thread and post the same question to noob section. Sorry to all for messing this thread with my noob question.



To MOD: Hope its okay with you if I open another thread in noob section to ask the same question.

[rack04]

Why do you think I ask? You can just ignore the question if you don't want to answer. Thank you very much.



To avoid anyone else from getting mad at me, I will quit from this thread and post the same question to noob section. Sorry to all for messing this thread with my noob question.



To MOD: Hope its okay with you if I open another thread in noob section to ask the same question.

You'll probably get the same answer there. Please perform a search. This has been discussed many times in this very thread. Actually pretty recently.

[nakTT]

You'll probably get the same answer there. Please perform a search. This has been discussed many times in this very thread. Actually pretty recently.
Thanks for your reply. Actually I have performed the search. Anyway, I will try again. Thanks mate.

:thanks:

[LoRd_MuldeR]

In english please (I'm not a programmer). Thank you in advance.

:thanks:

JEEB's builds include two unofficial patches. If you don't know what those patches do or why you need them, they probably aren't relevant for you. But they usually shouldn't hurt either ;)

In fact the one patch fixes a Windows-specific bug with "zone" parameter parsing and the other one adds the "--nal-hrd" option, which is required for BD authoring...

About the different compiler version used to make the build:
That usually shouldn't be relevant for you, as a user! In the best case the newer compiler version produces slightly faster code and doesn't break anything. In the worst case it breaks x264 :p

[Lyris]

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

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

________________________________________________________________________________

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

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


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

built on Sep 6 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.19.diff


2009/09/09: Updated the hrd_pd_interlace patch to v1⑨.

Thanks for posting. Unfortunately, it seems that the HRD patch is not playing nicely. I get a crash not long after encoding starts:

avis [info]: 1920x1080 @ 23.98 fps (14315 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile Main, level 4.1
Assertion failed: dpb_output_delay < pow( 2, sps->vui.nal_hrd_parameters.i_dpb_o
utput_delay_length ), file encoder/set.c, line 652

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

[moviefan]

Thanks that someone else experiences the HRD patch issue too! I hope Trahald will be able to figure out the problem that is causing this error.

[nakTT]

JEEB's builds include two unofficial patches. If you don't know what those patches do or why you need them, they probably aren't relevant for you. But they usually shouldn't hurt either ;)

In fact the one patch fixes a Windows-specific bug with "zone" parameter parsing and the other one adds the "--nal-hrd" option, which is required for BD authoring...

About the different compiler version used to make the build:
That usually shouldn't be relevant for you, as a user! In the best case the newer compiler version produces slightly faster code and doesn't break anything. In the worst case it breaks x264 :p
Many thanks mate. This is the answer that I'm looking for. Concise and Very easy to understand even for noob like me. Thanks again.

:thanks:

[JEEB]

Since the problem might be from my side in the way I build them, the patch or my compiler, here's:

My current buildscript (http://jeeb.pastebin.ca/1564719) just to see if it has any problems (I didn't see anything horribly wrong, the script is horrible in other ways though I guess).
The hrd patch (http://jeeb.pastebin.ca/1564721) I have on my HDD (in case it's somehow gone bad in transfer).

I could try getting a newer compiler in order to test, but I'll see how it goes. Originally I was going to update my GCC two or so months ago, but that kind of got put onto a further date because of some other things coming forward.

[moviefan]

The problem seems not to be on your side since rack04's build causes the error as well.

[rack04]

The problem seems not to be on your side since rack04's build causes the error as well.

Have you tried with an unpatched build?

[moviefan]

Have you tried with an unpatched build?No as I thought the error must be related to the hrd-patch (referring to the error including hrd-variables). Any counter-arguments to that assumption?

[nurbs]

Just to make 100% sure you can try encoding without the --nal-hrd switch. AFAIK you can let the muxer add the HRD stuff.

[shon3i]

Well this is not good because muxer (tsmuxer) assume certain VBV paremeters (buffer @ 30000 and max rate @ 40000) and if i use both @ 15000 because i use long gop (2-48). What would be happen then?

I now encode almost 20 Blu-Ray sources without any error and muxed it flawlessy with Scenarist 5.12. Here is my cmd

--profile high --level 4.1 --pass 2 --bitrate xxxx --stats ".stats" --thread-input --deblock -2:-2 --keyint 48 --min-keyint 2 --b-adapt 2 --direct auto --ref 4 --slices 4 --ipratio 1.1 --pbratio 1.1 --vbv-bufsize 15000 --vbv-maxrate 15000 --rc-lookahead 60 --aq-mode 2 --me umh --partitions all --trellis 2 --psy-rd 1.0:0.2 --no-dct-decimate --no-fast-pskip --qpfile xxx --sar 1:1 --mvrange 511 --aud --output "output" "input"

[Lyris]

Just to make 100% sure you can try encoding without the --nal-hrd switch. AFAIK you can let the muxer add the HRD stuff.
It encodes correctly without the --nal-hrd switch. No crashes.

[alwa]

x264 0.75.1259M dd026f2
built on Sep 15 2009, gcc: 4.3.4 (x86.generic.Komisar) (http://www.mediafire.com/?mmxtddrahjz)

x264 0.75.1259M dd026f2
built on Sep 15 2009, gcc: 4.3.4 (x86_64.generic.Komisar) (http://www.mediafire.com/?7djbjdxyq0q)

Compiled with defaults and fprofiled.

patched with:

x264_win_zone_parse_fix_06.diff
x264_hrd_pd_interlace.19.1259.diff (http://www.mediafire.com/?hd2dmrxwniw) (selfmade)

[juGGaKNot]

recent updates need yasm 0.6.2, see git.

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

also help updated

Improve x264 help

Now has three help options: --help, --longhelp, and --fullhelp.
--help only shows the most basic options; most users should not need more than these.
Add usage examples.
Fix typo in a comment.

[rack04]

recent updates need yasm 0.6.2, see git.

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

also help updated

From what I can tell it requires a minimum of yasm 0.6.2. Any version after that should work.

[LoRd_MuldeR]

recent updates need yasm 0.6.2, see git.

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

That should be no issue for most people building x264. Even my almost on-year-old YASM version (compiled on Oct 8 2008) already is v0.7.2 :p

So that really only effects people who didn't update their development tools for a long time.

Also I think the requirement for YASM v0.6.2 or later did exist before r1257. Maybe since r1067. It's only checked properly now ;)

[kemuri-_9]

Also I think the requirement for YASM v0.6.2 or later did exist before r1257. Maybe since r1067. It's only checked properly now ;)

it's been necessary since the SSE4a additions which were first in r1067 afaik.

[Trahald]

There is a well written patch on the mailing list. ill attach it. please someone make a binary for testing. i haven't tested it.it is made from two older patches. by alex giladi.

backwards compatible options to hrd patch.

[alwa]

Here is a build with the patch above. (http://www.mediafire.com/?mzmvmqwjd5z)
As always also patched with the x264_win_zone_parse_fix_06.diff and compiled fprofiled with defaults.

I had to adjust 2 lines manually because of the new help system (new patch (http://www.mediafire.com/?ojdjnj2ej2j)).

[JEEB]

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

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

________________________________________________________________________________

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

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


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

built on Sep 17 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)
nal_hrd-pic_struct.patch.DIFF (changed the H1s in the x264.c's settings part to H2s)


I herd you liked builds for testing so I put a build in your building thread so you can test builds while you test. Seriously though, the patch had some H1s while the newest revision of x264 had H2s as per the --help / --longhelp / --fullhelp change. Changing those H1s in the x264.c part to H2 fixed it all and let it patch&build nicely.

[burfadel]

Anyone tried the GCC 4.5.0 beta for x264? There's a build of x264 over at xvidvideo.ru that uses it, but don't have time now to test if there are any speed benefits over using previous GCC versions? The GCC 4.5.0 built versions of mpc-hc and ffdshow work fine :)

On a separate note, how come GCC 3.4.6 is still used for the builds on www.x264.nl, especially since I think it was said a while back that nothing before 4.x.x (can't remember the version) should be used to compile it?...

[bob0r]

x264 compiled with gcc 3.4.6 works on all systems.
Some builds compiled with early gcc 4.x had stability problems with fprofiled on some systems.
I have not tested any more versions.

Just let pengvado, dark and intel work on the speed improvements :)

[rack04]

Should NAL HRD be used during fprofile? I'm getting a message that "NAL HRD parameters require VBV max bitrate and buffer size to be specified" during fprofile.

x264 r1259M x86 (http://www.mediafire.com/?sharekey=114c6dc8a287150a7f7ec40ada4772a6e04e75f6e8ebb871)

Built by rack04 on September 17, 2009, 8:55:13 AM CST
gcc.exe (GCC) 4.3.4 (x86.core2.Komisar)
--extra-cflags="-march=core2"
make fprofiled

Patched with:

nal_hrd-pic_struct.patch.1259.diff (http://forum.doom9.org/showthread.php?p=1326162#post1326162)
x264_win_zone_parse_fix_06.diff (http://kemuri9.net/dev/x264/patches/x264_win_zone_parse_fix_06.diff)

[shon3i]

Ok i finished encoding using new nal-hrd. And if i try to load into MUI Generator i get this message

http://img246.imageshack.us/img246/8379/33055107.jpg

and if i try to load it to Elecard Buffer Analyser i got this message

http://img9.imageshack.us/img9/3306/30544559.jpg

So this HRD patch can't produce compilant stream now.

[G_M_C]

Ok i finished encoding using new nal-hrd. And if i try to load into MUI Generator i get this message

http://img246.imageshack.us/img246/8379/33055107.jpg

and if i try to load it to Elecard Buffer Analyser i got this message

http://img9.imageshack.us/img9/3306/30544559.jpg

So this HRD patch can't produce compilant stream now.

It really looks like waiting for the additions Dark Shikari and Tharald announced, that x264 should become fully BD compliant in a short while, is the better option :)

[Trahald]

I'll post the error on the mailing list.

[imk]

r1259M built with ICC.

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

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

[rack04]

Received this error while fprofiling 100 frames of 3840x2160 CrowdRun from the latest git:

http://i11.photobucket.com/albums/a199/rack04/x264fprofile.jpg

[kieranrk]

Received this error while fprofiling 100 frames of 3840x2160 CrowdRun from the latest git:


Out of memory.

[LoRd_MuldeR]

Not very surprising with 3840x2160 video. Try to lower "--rc-lookahead" a bit or make a 64-Bit build instead ;)

[rack04]

Not very surprising with 3840x2160 video. Try to lower "--rc-lookahead" a bit or make a 64-Bit build instead ;)

How do I modify the fprofiled settings?

[LoRd_MuldeR]

How do I modify the fprofiled settings?

Edit "Makefile" like this:

136 fprofiled:
137 $(MAKE) clean
138 mv config.mak config.mak2
139 sed -e 's/CFLAGS.*/& -fprofile-generate/; s/LDFLAGS.*/& -fprofile-generate/' config.mak2 > config.mak
140 $(MAKE) x264$(EXE)
141 $(foreach V, $(VIDS), $(foreach I, 0 1 2 3 4 5 6 7, ./x264$(EXE) $(OPT$I) --threads 1 --rc-lookahead 20 $(V) -o $(DEVNULL) ;))
142 rm -f $(SRC2:%.c=%.o)
143 sed -e 's/CFLAGS.*/& -fprofile-use/; s/LDFLAGS.*/& -fprofile-use/' config.mak2 > config.mak
144 $(MAKE)
145 rm -f $(SRC2:%.c=%.gcda) $(SRC2:%.c=%.gcno)
146 mv config.mak2 config.mak

[rack04]

Edit "Makefile" like this:

136 fprofiled:
137 $(MAKE) clean
138 mv config.mak config.mak2
139 sed -e 's/CFLAGS.*/& -fprofile-generate/; s/LDFLAGS.*/& -fprofile-generate/' config.mak2 > config.mak
140 $(MAKE) x264$(EXE)
141 $(foreach V, $(VIDS), $(foreach I, 0 1 2 3 4 5 6 7, ./x264$(EXE) $(OPT$I) --threads 1 --rc-lookahead 20 $(V) -o $(DEVNULL) ;))
142 rm -f $(SRC2:%.c=%.o)
143 sed -e 's/CFLAGS.*/& -fprofile-use/; s/LDFLAGS.*/& -fprofile-use/' config.mak2 > config.mak
144 $(MAKE)
145 rm -f $(SRC2:%.c=%.gcda) $(SRC2:%.c=%.gcno)
146 mv config.mak2 config.mak

Thanks for the info. I guess the easier option is to not fprofile with crowdrun on my laptop. :p

[LoRd_MuldeR]

Thanks for the info. I guess the easier option is to not fprofile with crowdrun on my laptop. :p

Profiling with the "Crowdrun" sample is overkill anyway. Any clip should do the job, as long as it isn't some "artificial" clip that makes the encoder behave strangely...

[juGGaKNot]

x264 core 76 r1268M d542926
cabac=1 / ref=5 / deblock=1:0:0 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / 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=3 / b_pyramid=0 / b_adapt=2 / b_bias=0 / direct=2 / wpredb=1 / keyint=500 / keyint_min=50 / scenecut=40 / rc_lookahead=60 / rc=2pass / mbtree=1 / bitrate=4700 / ratetol=2.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=20000 / vbv_bufsize=20000 / ip_ratio=1.40 / aq=2:1.00

New parameter: b_annexb, on by default

I do not see it

[LoRd_MuldeR]

New parameter: b_annexb, on by default

I do not see it

Who said that x264 necessarily does write all paramters in x264_param2string() ???

[DarkZell666]

Who said that x264 does write all paramters in param2string() ???

I suppose having cplxblur and qpstep in there means they're all supposed to be in there ;)

[juGGaKNot]

how can you disable it if its not in --fullhelp ?

New parameter: b_annexb, on by default. If disabled, startcodes are replaced by sizes as in mp4.

[LoRd_MuldeR]

how can you disable it if its not in --fullhelp ?

New parameter: b_annexb, on by default. If disabled, startcodes are replaced by sizes as in mp4.

As far as I understand, that is something to be controlled by the application that calls libx264 (depending on the target container's needs) and not directly by the user.

I suppose having cplxblur and qpstep in there means they're all supposed to be in there

Is sync-lookahead there? ^^

[MasterNobody]

Is sync-lookahead there? ^^
No, because it doesn't effect the bitstream (but only the encoding speed). The only parameter I known of which effects bitstream and don't there is fast-pskip. And annexb is not there and not in the CLI params because it usage depends not from user preferences but from container format (and after muxing to another container it may change).

[LoRd_MuldeR]

No, because it doesn't effect the bitstream (but only the encoding speed). The only parameter I known of which effects bitstream and don't there is fast-pskip.

Still any option could effect the output, even if it isn't supposed to. Bugs can happen ;)

And annexb is not there and not in the CLI params because it usage depends not from user preferences but from container format (and after muxing to another container it may change).

That's what I assumed...

[techouse]

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

________________________________________________________________________________

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

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

Patches used:

x264_win_zone_parse_fix_06.diff

nal_hrd-pic_struct.patch.1259.diff

[Snowknight26]

That NAL-HRD patch isn't fully fixed?

Without specifying any parameters pertaining to the NAL HRD patch:
x264 [warning]: NAL HRD parameters require VBV max bitrate and buffersize to be specificed

[Dark Shikari]

The patch hasn't been updated to take into account the effect of the patch, so I'm not entirely sure it's a good idea to blindly use it yet...

[moviefan]

Would encoding without nal-hrd and after encoding pass the stream through h264info adding "Picture Structure" keep BD compliance? So that h264info replaces the nal-hrd patch...

[techouse]

Yea, DS is right. I'll make a build w/o it for now. Awaiting fix....

[techouse]

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

________________________________________________________________________________

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

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

Patches used:

x264_win_zone_parse_fix_06.diff

NOTE:
nal_hrd-pic_struct.patch.1259.diff wasn't used cause DS says so.

[juGGaKNot]

x264_core_76_r1271M_496d79d_juGGaKNot (http://www.mediafire.com/download.php?gyndu5j2gny), GCC 4.4.1, generic, 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, ./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

[shon3i]

Can somebody compile last rev with x264_hrd_pd_interlace.16.1247.VFRManiac.diff (http://jeeb.pastebin.ca/1552607) which is lastest good HRD patch

[rack04]

Can somebody compile last rev with x264_hrd_pd_interlace.16.1247.VFRManiac.diff (http://jeeb.pastebin.ca/1552607) which is lastest good HRD patch

It does not patch the latest git correctly.

[VFR maniac]

x264_x86_r1271_with_nal-hrd.rar (http://www.esnips.com/doc/5f8b13f3-3ac1-46fc-8fc0-2157ff004676/x264_x86_r1271_with_nal-hrd)

gcc: 4.4.0
-march=core2

[moviefan]

What nal-hrd patch has been used and has it been tested for correctness? By the way, could you please upload to some other hoster? I'm not really keen on downloading any special software for the file download...

[shon3i]

Thanks VFR maniac, but i told you to use x264_hrd_pd_interlace.16 because Trahald something broke in 17/18/19, because x264 crash with GOP 24. Thanks

[moviefan]

x264_hrd_pd_interlace.16.diff and x264_hrd_pd_interlace.16.fix.1232.diff fail to patch.

[VFR maniac]

x264_x86_rev1271_with_nal_hrd_16.rar (http://www.mediafire.com/download.php?yohdgyztmm2)

gcc: 4.4.0
-march=core2

The difference between 16 and 19 is the calculation of frame_size and dpb_output_delay.

[moviefan]

Strange that you could successfully patch the r1271 with hrd16... Does hrd16 work properly or are there any bugs?

Not to forget: Thanks for patching and hosting at mediafire!

[shon3i]

Thanks a lot :) well rev 19 is always crash x264 with gop 1,2-24, people reported here several times, while rev 16 work normal. I am going to test now.

[MythCreator]

x264_x86_rev1271_patched_build.exe (http://www.filefront.com/14615457/x264_x86_rev1271_patched_build.exe)

Applied Patches:
x264_AQ2mod.diff
x264_hrd_pd_interlace.19_r1268.diff
x264_thread_pool_v2.2.diff
x264_win_zone_parse_fix_06.diff

[thewebchat]

What is x264_AQ2mod.diff?

[MythCreator]

Just a mod, written by Bug Master

[kemuri-_9]

Just a mod, written by Bug Master

that's especially descriptive in how it modifies AQ...
something like this would of been more useful:

[12:15] <BugMaster> And alternative to my "--aq-mode 3" patch: http://stashbox.org/643517/x264_AQ2mod.diff which expands "--aq-mode 2" to "--aq-mode 3 equal" by setting second param of --aq-strength equal to first. For example, --aq-mode 2 --aq-strength 0.8:0.8 is equal to --aq-mode 3 --aq-strength 0.8, and --aq-mode 2 --aq-strength 0.5:0 (second param is optional and when don't specified is equal to zero) is equal to standard --aq-mode 2 --aq-strength 0

[MythCreator]

AQ2mod.v2.diff (Add second parameter for strength in AQ-modes
"#1:#2" where #1 - aq-strength; #2 - frame QP offset; >1.0 -- more 'loves' fades and dark frames.
Patch made by BugMaster)

From Komisar's site

[shon3i]

Ok i finished testing and results are positive. I sucessfulyu mux stream into scenarist.

I use VFR Maniac x264_x86_rev1271_with_nal_hrd_16.rar build

and i use following cmd

--profile high --level 4.1 --pass 2 --bitrate 8437 --stats ".stats" --thread-input --deblock -2:-2 --keyint 24 --min-keyint 2 --b-adapt 2 --direct auto --ref 4 --slices 4 --ipratio 1.1 --pbratio 1.1 --vbv-bufsize 30000 --vbv-maxrate 30000 --rc-lookahead 60 --aq-mode 2 --me umh --partitions all --trellis 2 --psy-rd 1.0:0.2 --no-dct-decimate --no-fast-pskip --sar 1:1 --mvrange 511 --aud --nal-hrd --output "output" "input"

[MasterNobody]

[12:15] <BugMaster> And alternative to my "--aq-mode 3" patch: http://stashbox.org/643517/x264_AQ2mod.diff which expands "--aq-mode 2" to "--aq-mode 3 equal" by setting second param of --aq-strength equal to first. For example, --aq-mode 2 --aq-strength 0.8:0.8 is equal to --aq-mode 3 --aq-strength 0.8, and --aq-mode 2 --aq-strength 0.5:0 (second param is optional and when don't specified is equal to zero) is equal to standard --aq-mode 2 --aq-strength 0.5

For some reason the end of message was truncated in IRC (--aq-strength 0.5 not --aq-strength 0).

[komisar]

[deleted]
heh... BugMaster faster... :)

[moviefan]

Ok i finished testing and results are positive. I sucessfulyu mux stream into scenarist.

I use VFR Maniac x264_x86_rev1271_with_nal_hrd_16.rar build

and i use following cmd

Thanks for your report! As far as I know about nal-hrd, it somehow influences the buffer calculations which is also the reason why encoding without nal-hrd and afterwards reprocessing the stream with h264info (Add Picture Structure) does not guarantee Blu-ray compliance. Can you confirm that buffer limits have not been exceeded and that the stream is thus totally Blu-ray compliant?

[imk]

r1271M built with ICC.

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

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

[shon3i]

Thanks for your report! As far as I know about nal-hrd, it somehow influences the buffer calculations which is also the reason why encoding without nal-hrd and afterwards reprocessing the stream with h264info (Add Picture Structure) does not guarantee Blu-ray compliance. Can you confirm that buffer limits have not been exceeded and that the stream is thus totally Blu-ray compliant?
Well Elecard Buffer Analyser report no Overflows/Underflows, scenarist also, and scenarist is very strict compilant when is buffer/maxrate ratio very low, and CBP removal relay different than 0.9

Stream info:
file name : 00102.264
file size : 2 466 162 628 bytes

video format : AVC/H.264
initial CBP removal relay : 0.90 sec
buffer size : 30 000 000 bits
declared bitrate : 30 000 000 bps
declared frame rate : 23.98 fps
bitrate type : VBR
padding : 0 bits

http://img71.imageshack.us/img71/515/vbv.jpg

Using 3-party apps such H264Info or TsMuxer to insert HRD is not good idea at all because, they assume certain VBV.

This HRD patch still have issues when use VBV-init different than 0.9 in x264

[moviefan]

This HRD patch still have issues when use VBV-init different than 0.9 in x264
Conclusion: I have to set --vbv-init 0.9? You didn't in your posted command line... Or do I get something wrong?

[nixo]

From x264:
--vbv-init <float> Initial VBV buffer occupancy [0.9]

It's the default value.

--
Nikolaj

[moviefan]

Oh, okay, sorry... I didn't look up the default setting...

[JEEB]

I end up writing this even though I promised to myself that I wouldn't build x264 with nal-hrd patched before the official stuff gets in. As I saw shon3i encoding without problemos with VFR Maniac's rev16 I thought that making a build with it would be better than just leaving the older one as "newest" (as the last one I made was a r1259 with a certainly broken hrd patch, so I guess doing this might even have a better effect on the end results if someone was still using my builds).

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

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

________________________________________________________________________________

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

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


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

built on Sep 17 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_r1271.diff

[laserfan]

...doing this might even have a better effect on the end results if someone was still using my buildsYes some of us love your builds! I will give this a try...

[cgp-2k9]

I end up writing this even though I promised to myself that I wouldn't build x264 with nal-hrd patched before the official stuff gets in. As I saw shon3i encoding without problemos with VFR Maniac's rev16 I thought that making a build with it would be better than just leaving the older one as "newest" (as the last one I made was a r1259 with a certainly broken hrd patch, so I guess doing this might even have a better effect on the end results if someone was still using my builds).

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

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

________________________________________________________________________________

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

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


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

built on Sep 17 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_r1271.diff


Finally you released one of your builds. Thanks for that. Been waiting for you to do it as I always use your builds.

Thanks once again.

cgp

[laserfan]

I end up writing this even though I promised to myself that I wouldn't build x264 with nal-hrd patched before the official stuff gets in. As I saw shon3i encoding without problemos with VFR Maniac's rev16 I thought that making a build with it would be better than just leaving the older one as "newest"...

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_r1271.diff
I'm not clear on what the problems might be with the hrd patch, but FWIW your patched 32bit build with --nal-hrd option used worked fine for me, thanks!

[MythCreator]

x264_x86_rev1280.unpatched.exe (http://www.filefront.com/14672627/x264_x86_rev1280.unpatched.exe)



x264_x86_rev1280.patched_build.1.exe (http://www.filefront.com/14672639/x264_x86_rev1280.patched_build.1.exe)
with patches below:
x264_hrd_pd_interlace.19_r1280.diff
x264_win_zone_parse_fix_06.diff



x264_x86_rev1280.patched_build.2.exe (http://www.filefront.com/14672701/x264_x86_rev1280.patched_build.2.exe)
with patches below:
x264_hrd_pd_interlace.19_r1280.diff
x264_win_zone_parse_fix_06.diff
x264_thread_pool_v2.2.diff
x264_AQ2mod




All compiled in GCC 4.4.1,with fprofile

[ACrowley]

Hello

I made a reencode of my own XMen origins Wolferine BluRay.

Some Scenes contains alot of grain so i want to try the Tune-grain Option

program --profile high --level 4.1 --preset veryslow --tune grain --pass 2 --bitrate 14800 --stats ".stats" --thread-input --deblock -3:-3 --bframes 3 --b-adapt 2 --direct auto --b-bias 0 --scenecut 40 --ref 5 --vbv-bufsize 30000 --vbv-maxrate 40000 --rc-lookahead 60 --aq-mode 1 --merange 24 --me umh --subme 9 --partitions p8x8,b8x8,i4x4,i8x8 --trellis 2 --no-dct-decimate --no-fast-pskip --output "output" "input"

Tune Option" Grain" applies :
psy-rd 1:0.25, no-dct-decimate, ipratio 1.1, pbratio 1.1, aq-strength 0.5, deadzone-intra 6, deadzone-inter 6, qcomp 0.8

But now i get VBV Underflow Errors in 2nd Pass :

---[NoImage] avis [info]: 1920x816 @ 23.98 fps (154439 frames)
---[NoImage] x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
---[NoImage] x264 [info]: profile High, level 4.1
---[NoImage] x264 [warning]: VBV underflow (-4324 bits)
---[NoImage] x264 [warning]: VBV underflow (-157491 bits)
---[NoImage] x264 [warning]: VBV underflow (-437251 bits)
---[NoImage] x264 [warning]: VBV underflow (-547867 bits)
---[NoImage] x264 [warning]: VBV underflow (-330667 bits)
---[NoImage]
---[NoImage] x264 [info]: frame I:4476 Avg QP:18.34 size:124334
---[NoImage] x264 [info]: frame P:49369 Avg QP:18.40 size: 92992
---[NoImage] x264 [info]: frame B:100594 Avg QP:18.88 size: 67158
---[NoImage] x264 [info]: consecutive B-frames: 2.9% 11.0% 35.7% 50.4%
---[NoImage] x264 [info]: mb I I16..4: 44.0% 46.0% 10.0%
---[NoImage] x264 [info]: mb P I16..4: 3.5% 11.1% 1.0% P16..4: 44.7% 24.2% 14.9% 0.0% 0.0% skip: 0.6%
---[NoImage] x264 [info]: mb B I16..4: 1.7% 3.8% 0.3% B16..8: 54.3% 2.0% 3.2% direct:20.6% skip:14.0% L0:42.7% L1:46.6% BI:10.8%
---[NoImage] x264 [info]: 8x8 transform intra:62.8% inter:41.8%
---[NoImage] x264 [info]: direct mvs spatial:90.1% temporal:9.9%
---[NoImage] x264 [info]: coded y,uvDC,uvAC intra:95.7% 73.7% 54.9% inter:62.2% 41.9% 13.9%
---[NoImage] x264 [info]: ref P L0 58.7% 17.6% 11.9% 6.6% 5.2%
---[NoImage] x264 [info]: ref B L0 74.7% 12.6% 8.0% 4.8%
---[NoImage] x264 [info]: kb/s:14783.3
---[NoImage] encoded 154439 frames, 2.03 fps, 14784.57 kb/s
--[Information] Final statistics
---[NoImage] Video Bitrate Desired: 14800 kbit/s
---[NoImage] Video Bitrate Obtained (approximate): 14784 kbit/s
--[Information] [06.10.2009 13:16:51] Postprocessing
--[Information] [06.10.2009 13:16:51] Job completed

What can i do ? Will the stream contain Errors and can it cause Playback Problems on HW Players ? PC Playback works fine so far i can see

[Dark Shikari]

It seems I'll really have to spend some time investigating this weekend...

in the meantime, just use 1-pass mode instead.

[Fr4nz]

It seems I'll really have to spend some time investigating this weekend...

in the meantime, just use 1-pass mode instead.

I bet these overflows (which is a different problem from what I've encountered, anyway) come from the same scenes in which I had problems with my blu-ray player...first 6-8 minutes of the movie.

[ACrowley]

I bet these overflows (which is a different problem from what I've encountered, anyway) come from the same scenes in which I had problems with my blu-ray player...first 6-8 minutes of the movie.

Mhh...my Sony BDP S350 and also Popcornhour A110 plays it well (untouched Source)

I never had x264 undeflows before! But it was the 1st Time i used the Tune-Grain Option
So maybe the Tune/Grain Options are the Problem on this Source or the Source itself /heavy Grain at some Scenes)

[Fr4nz]

Mhh...my Sony BDP S350 and also Popcornhour A110 plays it well (untouched Source)

In fact we are talking of the encoded movie...

[shon3i]

So problem is generaly i x264 VBV model then.

[Dark Shikari]

So problem is generaly i x264 VBV model then.No, it's the 2-pass VBV algorithm. My one-pass is still fine.

I would recommend using CRF + VBV for most ordinary encoding tasks if you're having issues with 2-pass + VBV.

[ACrowley]

In fact we are talking of the encoded movie...


maybe you read a few Popstings above:rolleyes:

Im talking about the reencode in Fact!

As i say, 2pass VBR with VBV Buffer 30000/ MaxBitrate 40000 works fine in all cases last Time
But not with Tuningmode -Grain "and or" Xmen Wolferin Origins BluRay Source.
So i was talking about the Source :)

[Fr4nz]

No, it's the 2-pass VBV algorithm. My one-pass is still fine.

I would recommend using CRF + VBV for most ordinary encoding tasks if you're having issues with 2-pass + VBV.

Do you plan to fix the 2-pass algorithm in the near future?

[nm]

A few posts back:
It seems I'll really have to spend some time investigating this weekend...

[Fr4nz]

A few posts back:

He didn't mention the VBV 2 pass algo.

[nm]

That was implied by "in the meantime, just use 1-pass mode instead", and he clarified it already in the next post that you quoted.

[techouse]

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

________________________________________________________________________________

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

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

Patches used:

x264_win_zone_parse_fix_06.diff

[JEEB]

Nice to see that the r16 works for some people :3 Edited and diff -NdurwBE'd the 1271 patch so that it patches (linky (http://jeeb.pastebin.ca/1601582)), let's see how it goes.

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

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

________________________________________________________________________________

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

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


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

built on Oct 7 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_r1281.diff (http://jeeb.pastebin.ca/1601582) (fixed a stupid error pointed by VFR Maniac)

[VFR maniac]

x264_hrd_pd_interlace.16_r1281.diff (http://jeeb.pastebin.ca/1601373)

The code is obviously wrong.
It should be the following.
@@ -1493,8 +1521,11 @@ static void update_vbv( x264_t *h, int bits )
if( rct->buffer_fill_final < 0 )
x264_log( h, X264_LOG_WARNING, "VBV underflow (frame %d, %.0f bits)\n", h->i_frame, rct->buffer_fill_final );
rct->buffer_fill_final = X264_MAX( rct->buffer_fill_final, 0 );
- rct->buffer_fill_final += rct->buffer_rate;
+ // we will honor vfr (when applicable) for the final buffer while prediction routines
+ // will continue to use the average frame rate
+ rct->buffer_fill_final += vfrlowhigh == 3 ? rcc->buffer_rate_vfr_high : rcc->buffer_rate_vfr_low;
rct->buffer_fill_final = X264_MIN( rct->buffer_fill_final, rct->buffer_size );
+ h->param.rc.i_buffer_fill_final = x264_clip3f( rct->buffer_fill_final, 0, rct->buffer_size - 1000 );
}

// provisionally update VBV according to the planned size of all frames currently in progress

[JEEB]

Ugh, that's one of the parts I manually edited. inb4 FFFFUUUUU.

Thanks and redoing. Now this is why I link my patches.

[EDIT]
I guess this one is fine then with your edit?
Linky (http://jeeb.pastebin.ca/1601582)

[Underground78]

Does this patch (http://mailman.videolan.org/pipermail/x264-devel/2009-October/006412.html) do the same thing than Trahald's one ?

[shon3i]

Does this patch (http://mailman.videolan.org/pipermail/x264-devel/2009-October/006412.html) do the same thing than Trahald's one ?
Yes but is broken

[rack04]

Yes but is broken

What is broken about it?

[shon3i]

What is broken about it?
http://forum.doom9.org/showthread.php?p=1326570#post1326570

I don't know is been updated since then.

[rack04]

http://forum.doom9.org/showthread.php?p=1326570#post1326570

I don't know is been updated since then.

It was updated Wed Oct 7 21:03:07 CEST 2009

Attached is the new version of the HRD patch with several changes due
to the inputs from Dark_Shikari, Manao and Trahald.
The two major fixes cpb_removal_delay for IDR frames and calculation
of initial_cpb_removal_delay.


Here is a build if you want to test:

x264 r1281M x86 (http://www.megaupload.com/?d=7T5VMMGS)

Built by rack04 on October 7, 2009, 3:24:36 PM CST
gcc.exe (GCC) 4.3.4 (x86.core2.Komisar)
--extra-cflags="-march=core2"
make fprofiled

Patched with:

x264-r1281-nal_hrd-pic_struct-v8.diff (http://mailman.videolan.org/pipermail/x264-devel/2009-October/006412.html)
x264_win_zone_parse_fix_06.diff (http://kemuri9.net/dev/x264/patches/x264_win_zone_parse_fix_06.diff)

[shon3i]

Very nice thanks :) I'm going now to test

[techouse]

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

________________________________________________________________________________

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

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

Patches used:

x264_win_zone_parse_fix_06.diff (http://kemuri9.net/dev/x264/patches/x264_win_zone_parse_fix_06.diff)
x264-r1281-nal_hrd-pic_struct-v8.diff (http://mailman.videolan.org/pipermail/x264-devel/attachments/20091007/cfbeacbe/attachment-0001.obj)

[shon3i]

Ok i do a deep test bettween x264_hrd_pd_interlace.16_r1281.diff and x264-r1281-nal_hrd-pic_struct-v8.diff (Rack04 vs JEEB build) and x264-r1281-nal_hrd-pic_struct-v8.diff is still broken. Elecard Buffer Analyser now scan whole stream and at the end show message "HRD parameters are not presented", while Scenarist MUI Generator just give ERROR message. 264_hrd_pd_interlace.16_r1281.diff still produce compilant stream :)

btw cmd i used for testing:

-profile high --level 4.1 --pass 2 --bitrate 8000 --stats ".stats" --thread-input --deblock -2:-2 --keyint 24 --min-keyint 2 --b-adapt 2 --direct auto --ref 4 --slices 4 --ipratio 1.1 --pbratio 1.1 --vbv-bufsize 30000 --vbv-maxrate 30000 --rc-lookahead 60 --aq-mode 2 --me umh --partitions all --trellis 2 --psy-rd 1.0:0.2 --no-dct-decimate --no-fast-pskip --sar 1:1 --aud --nal-hrd --output "output" "input"

[ACrowley]

I made a few encodes with CRF 18. Im wondering that the average Bitarte is around 6-8 Mbps with CRF 18 ? Isn it a litte bit low ? Quants are fine so far

[LoRd_MuldeR]

I made a few encodes with CRF 18. Im wondering that the average Bitarte is around 6-8 Mbps with CRF 18 ? Isn it a litte bit low ? Quants are fine so far

Why do you complain about too low bitrate? You can't expect a specific bitrate from a specific CRF value, because CRF highly depends on the source.

So if the quality is okay at CRF 18 and 6-8 Mbps, then be happy :)

And if the quality is not okay for you at CRF 18, simply use an even lower CRF value. The CRF should be chosen by target quality, not by target bitrate.

For target bitrate encodes there is 2-Pass mode ...

[ACrowley]

Why do you complain about too low bitrate? You can't expect a specific bitrate from a specific CRF value, because CRF highly depends on the source.

So if the quality is okay at CRF 18 and 6-8 Mbps, then be happy :)

And if the quality is not okay for you at CRF 18, simply use an even lower CRF value. The CRF should be chosen by target quality, not by target bitrate.

For target bitrate encodes there is 2-Pass mode ...

im not complainig. I just wondering because i was expecting higher Bitrate with CRF 18. I usually encode 1080p with 8-15Mbps.

[LoRd_MuldeR]

im not complainig. I just wondering because i was expecting higher Bitrate with CRF 18. I usually encode 1080p with 8-15Mbps.

1. As said before, CRF highly depends on the source. So your current source may simply need fewer bits to look good.

2. MB-Tree RC redefined the CRF scale and generally reduces the bitrate requirement (that is: it retains better quality at same bitrate, or same quality at lower bitrate).

Maybe you are comparing a MB-Tree RC encode to an old encode that was done without MB-Tree ???

[ACrowley]

1. As said before, CRF highly depends on the source. So your current source may simply need fewer bits to look good.

2. MB-Tree RC redefined the CRF scale and generally reduces the bitrate requirement (that is: it retains better quality at same bitrate, or same quality at lower bitrate).

Maybe you are comparing a MB-Tree RC encode to an old encode that was done without MB-Tree ???

Its latest encode from Xmen Origins Wolferine Bluray.
The Source incldues a lot of Scenes with heavy Grain so i was suprised that the average Bitrate/Filesize is so low with crf 18.

Yes, some old encdes without MBtree have higher Bitrate/Size at CRF 18 so i cant compare it with ne MBtree encodes.

Maybe i should go down to crf 16 or 17

THX for your help

[LoRd_MuldeR]

Maybe i should go down to crf 16 or 17

Nobody can tell you what CRF values give acceptable quality for you, because this is highly subjective!

Simply use the highest possible CRF value that still gives good results for your eyes. If CRF 18 looks good for you, then no need to go any lower.

But if it looks bad for you, don't hesitate to try CRF 17 or 16 ;)

[ACrowley]

Nobody can tell you what CRF values give acceptable quality for you, because this is highly subjective!

Simply use the highest possible CRF value that still gives good results for your eyes. If CRF 18 looks good for you, then no need to go any lower.

But if it looks bad for you, don't hesitate to try CRF 17 or 16 ;)

Im very satisfied with my 2pass VBR encodes which are mostly around 10-12Mbps average Bitrate.

I want the same Quality/Size. CRF was only a thought because it works faster. I will test it .
THX

[LoRd_MuldeR]

Im very satisfied with my 2pass VBR encodes which are mostly around 10-12Mbps average Bitrate.

I want the same Quality/Size. CRF was only a thought because it works faster. I will test it .
THX

Again: If you use CRF mode, then choose your CRF value with a specific level of quality in mind, not with a specific target bitrate in mind!

So you should adjust the CRF value until you get the desired quality instead of modifying it until you hit a specific bitrate. For the latter case we have 2-Pass mode :D

[komisar]

Hey, guys, gcc-miscompiling-saga again...
I have tested unpatched builds again and found the following results:
1281 builds:
x264.nl gcc 3.4.6 -- OK
BugMaster gcc 4.3.3 TDM -- OK
BugMaster gcc 4.3.4 20090220 (prerelease) (x32.generic.Komisar) (not profiled) -- OK
Komisar gcc 4.3.4 (x86_64.core2.Komisar) -- OK
Komisar gcc 4.3.4 (x86.generic.Komisar) -- OK
Komisar gcc 4.4.1 (x86.core2.Komisar) -- FAILURE
JEEB gcc 4.3.4 20090220 (prerelease) (x64.generic.Komisar) -- FAILURE
techouse gcc 4.4.1 (x86_64.core2.Komisar) -- FAILURE
rack04 (patched build) gcc 4.3.4 (x86.core2.Komisar) -- FAILURE


gcc sucks again... :eek:

[JEEB]

Oh nice~

Thank you for your information, I'll get to building a new GCC and a new x264 as soon as I'll get home :/ Kind of hatin' the whole miscompilation stuff.

In short: *censored* (Holy Hanyuu I hate these cases)

[kemuri-_9]

what is the problem that is occurring in x264 with these 'broken' builds?
and what is the issue in gcc that's causing them

[LoRd_MuldeR]

Komisar, how exactly do you test the builds? And does "FAILURE" mean crash, bad output or what? How would I realize? :confused:

BTW: Did anybody else test GCC 4.4.1 TDM-2 yet?

[MythCreator]

My build is compile by TDM GCC。。。And what things are failure on 4.4.X?

[LoRd_MuldeR]

My build is compile by TDM GCC。。。And what things are failure on 4.4.X?

That's what I wonder too. There are basically two things that can happen:

1. Unexpected crash -> easy to detect and easy to fix (re-build until it stops crashing)
2. Bad output -> hard to detect, unless the output is broken so bad that it causes obvious artifacts

Since (1) does happen with my GCC 4.4.1 TDM-2 builds and there also is no obvious indication for (2), I'd assume these builds are okay.
But there may be a more subtle problem. So how do I check properly ???

[techouse]

Yea, I wanna know that too. :/

[MasterNobody]

LoRd_MuldeR, techouse
If you were at x264dev IRC yesterday you would know that it doesn't cause obvious artifacts. It is caused by used addressing in x264 and gcc. The quick workaround is replacing of all dct2x2[0][coeff] with dct2x2[coeff>>1][coeff&1] in macroblock.c

[komisar]

Test made by "%x% --threads 1 --ssim -o %x%.264 TestVideo.y4m"

"FAILURE" mean BIG difference (above 5 kilobytes) (FAILURE) with x264.nl x32 build... :)
Raw stream of "OK"-bulds is identical with x264.nl x32 build...

[kemuri-_9]

we discussed the issue on #x264dev last night and discovered the discrepancy in the output and the underlying cause in the code.

the underlying code was found in
x264_mb_optimize_chroma_dc within encoder/macroblock.c

the problem with the output not being bitwise equivalent is that the chroma macroblocks can be slightly different from what they should be.

the visual difference is generally unnoticeable and there's a slight bitrate difference when encoding in CRF mode.

the method to test if your build has this issue:
1. take a build that was listed as 'OK' by komisar and use it as a reference
2. ./x264_reference --qp 24 --ipratio 1 -o a1.h264 <input>
3. ./x264_reference --qp 25 --ipratio 1 -o a2.h264 <input>
4. ./x264_your_own --qp 24 --ipratio 1 -o b1.h264 <input>
5. ./x264_your_own --qp 25 --ipratio 1 -o b2.h264 <input>

if your build has problems then
a1.h264 & b1.h264 should be different
a2.h264 & b2.h264 should be bitwise equivalent

the problem has only been reported for mingw as of yet, so it's either only affecting mingw or no one's just tested for other platforms.

[tph]

dct2x2[2][2] could also be changed into dct2x2[4] instead (after adjusting all relevant code), at least that seems to do the trick for me and should theoretically be faster than doing some bit manipulation. The same probably holds for all other DCT arrays.

[kemuri-_9]

dct2x2[2][2] could also be changed into dct2x2[4] instead (after adjusting all relevant code), at least that seems to do the trick for me and should theoretically be faster than doing some bit manipulation. The same probably holds for all other DCT arrays.

that's the plan of attack as it already stands:

<kemuri-_9> so what is going to be done to fix the issue?
<pengvado> eliminate multidimensional arrays in any context that needs to iterate over multiple dimensions
<pengvado> if the standard doesn't allow that feature to work, then we can't use it
<pengvado> you know, most of the time it's not actually useful to treat dct as 2d...

[techouse]

LoRd_MuldeR, techouse
If you were at x264dev IRC yesterday you would know that it doesn't cause obvious artifacts. It is caused by used addressing in x264 and gcc. The quick workaround is replacing of all dct2x2[0][coeff] with dct2x2[coeff>>1][coeff&1] in macroblock.c
OK, I'll use this quick workaround and post 3 builds in a few minutes.

EDIT:

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

Patches used:

the quick GCC 4.4.x workaround (http://pastebin.ca/1612400)

________________________________________________________________________________

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

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

Patches used:

x264_win_zone_parse_fix_06.diff (http://kemuri9.net/dev/x264/patches/x264_win_zone_parse_fix_06.diff)
x264_hrd_pd_interlace.16_r1281.diff (http://jeeb.pastebin.ca/1601582)
the quick GCC 4.4.x workaround (http://pastebin.ca/1612400)

[burfadel]

Is this issue still present in the GCC 4.5.0 beta?

Using the latest ffdshow and mpc-hc from xvidvideo.ru both of which are compiled with gcc 4.5.0, they seem to work fine...

[Kurtnoise]

Keep in mind that mpc-hc uses lavc decoder, not x264...

[LoRd_MuldeR]

LoRd_MuldeR, techouse
If you were at x264dev IRC yesterday you would know that it doesn't cause obvious artifacts. It is caused by used addressing in x264 and gcc. The quick workaround is replacing of all dct2x2[0][coeff] with dct2x2[coeff>>1][coeff&1] in macroblock.c

Test made by "%x% --threads 1 --ssim -o %x%.264 TestVideo.y4m"

"FAILURE" mean BIG difference (above 5 kilobytes) (FAILURE) with x264.nl x32 build... :)
Raw stream of "OK"-bulds is identical with x264.nl x32 build...

Thanks for the info!

But since I build x264 as a shared library, I guess testing will be more difficult for me, because there are more places where things can go wrong and I don't have a reference build :eek:

Anyway, could anybody be so kind and post a patch with the "quick workaround" for me :thanks:

[techouse]

Anyway, could anybody be so kind and post a patch with the "quick workaround" for me :thanks:

Here you go :)

http://pastebin.ca/1612400

[LoRd_MuldeR]

Here you go :)

http://pastebin.ca/1612400

That's all? Thanks for the patch :D

[techouse]

That's all? Thanks for the patch :D
Yea, well, altogether 4 entries had to be replaced in a single file, so yea, that's all :D

[shon3i]

OK, I'll use this quick workaround and post 3 builds in a few minutes.

EDIT:

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

Patches used:

the quick GCC 4.4.x workaround (http://pastebin.ca/1612400)

________________________________________________________________________________

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

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

Patches used:

x264_win_zone_parse_fix_06.diff (http://kemuri9.net/dev/x264/patches/x264_win_zone_parse_fix_06.diff)
x264-r1281-nal_hrd-pic_struct-v8.diff (http://mailman.videolan.org/pipermail/x264-devel/attachments/20091007/cfbeacbe/attachment-0001.obj)
the quick GCC 4.4.x workaround (http://pastebin.ca/1612400)
techouse please don't use x264-r1281-nal_hrd-pic_struct-v8.diff because can't produce compilant BD streams. Obviously you don't read this topic cearfully. For now use x264_hrd_pd_interlace.16_r1281.diff or not use any hrd patch.

[techouse]

techouse please don't use x264-r1281-nal_hrd-pic_struct-v8.diff because can't produce compilant BD streams. Obviously you don't read this topic cearfully. For now use x264_hrd_pd_interlace.16_r1281.diff or not use any hrd patch.Sorry, I must have missed it! I'll get on it straight away.

EDIT:
Fixed. The links to the builds remain the same, the binareis have changed, so please RE-download them.

[Dark Shikari]

techouse please don't use x264-r1281-nal_hrd-pic_struct-v8.diff because can't produce compilant BD streams. Obviously you don't read this topic cearfully. For now use x264_hrd_pd_interlace.16_r1281.diff or not use any hrd patch.Isn't the first patch the one sent out by Alex Giladi? I recall an earlier version of that one passed official Sony BD Verifier tests (newer hasn't been tested yet).

[ACrowley]

Is there a special Reason why i get his Warning with the fixed rev1281 Techhouse Build ?
x264 [warning]: NAL HRD parameters require VBV max bitrate and buffer size to be specified

I never got this Warning before. My cmd is without nal hrd Parameter. I dont think nal hrd is enabled by default/autom(maybe through Level 4.1 Settings) ?
--preset veryslow --tune grain --crf 18.0 --level 4.1 --deblock -3:-3 --ref 5 --no-fast-pskip --partitions p8x8,b8x8,i4x4,i8x8 --subme 9 --bframes 3

Questions over Questions the last Days....

[shon3i]

Isn't the first patch the one sent out by Alex Giladi? I recall an earlier version of that one passed official Sony BD Verifier tests (newer hasn't been tested yet).
Yes, i think is from Alex Giladi, but Elecard and Sonic reject streams completly, while Trahald's work fine up to rev16, because in later rev's (19) changed some calculations which crash x264 with GOP 24

[kemuri-_9]

Is there a special Reason why i get his Warning with the fixed rev1281 Techhouse Build ?
x264 [warning]: NAL HRD parameters require VBV max bitrate and buffer size to be specified

I never got this Warning before. My cmd is without nal hrd Parameter.

the patch used by techouse does

if( h->param.rc.i_vbv_max_bitrate == 0 || h->param.rc.i_vbv_buffer_size == 0 )
{
x264_log( h, X264_LOG_WARNING, "NAL HRD parameters require VBV max bitrate and buffer size to be specified\n" );
h->param.vui.b_nal_hrd_parameters_present = 0;
}

so it always throws a warning if you're not using vbv-bufsize and/or vbv-maxrate.

the if condition should be more like

if( h->param.vui.b_nal_hrd_parameters_present && (!h->param.rc.i_vbv_max_bitrate || !h->param.rc.i_vbv_buffer_size) )

so it properly only warns if you are actually requesting nal-hrd

[techouse]

Yep, x264-r1281-nal_hrd-pic_struct-v8.diff has that fault but x264_hrd_pd_interlace.16_r1281.diff hasn't, so this error is irrelevant in my latest build. Thanx for pointing it out, kemuri-_9 :)

[techouse]

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

Patches used:

the quick GCC 4.4.x workaround (http://pastebin.ca/1612400)

________________________________________________________________________________

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

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

Patches used:

x264_win_zone_parse_fix_06.diff (http://kemuri9.net/dev/x264/patches/x264_win_zone_parse_fix_06.diff)
x264_hrd_pd_interlace.16_r1281.diff (http://jeeb.pastebin.ca/1601582)
the quick GCC 4.4.x workaround (http://pastebin.ca/1612400)

[juGGaKNot]

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

Applied patches :

x264_win_zone_parse_fix_06.diff (http://www.mediafire.com/download.php?citmmz1jmcq)
x264_hrd_pd_interlace.16_r1281.diff (http://www.mediafire.com/download.php?mu4ydt3zwjz)
Quick_GCC_4.4.x_Workaround.diff (http://www.mediafire.com/download.php?u12telnj0jn)

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, ./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

[Dark Shikari]

People should probably stop compiling GCC 4.4 bugs until we fix the miscompilation issues...

[LoRd_MuldeR]

People should probably stop compiling GCC 4.4 bugs until we fix the miscompilation issues...

So is the "workaround" patch not fixing the miscompilation? :confused:

http://pastebin.ca/1612400

[techouse]

:confused:

[Dark Shikari]

So is the "workaround" patch not fixing the miscompilation? :confused:

http://pastebin.ca/1612400Until we eliminate all such uses of 2D arrays, I don't trust GCC 4.4 to produce valid output.

[LoRd_MuldeR]

Until we eliminate all such uses of 2D arrays, I don't trust GCC 4.4 to produce valid output.

I see. Thanks for info. Awaiting official commit :)

[rack04]

Until we eliminate all such uses of 2D arrays, I don't trust GCC 4.4 to produce valid output.

How about GCC 4.3.4?

[Dark Shikari]

How about GCC 4.3.4?Fix has already been committed, so... :p

[techouse]

One patch a day keeps the encoder away. :P

[shroomM]

Just a quick noob question...

The 1286 build on x264.nl (compiled with "32bit: gcc 3.4.6 make fprofiled") should be OK, yes?

The reason for asking is that I get some corrupted video with it and would just like to know if I should wait for 1287 or report the bug. :p

Thanks, A

[MythCreator]

Try it,if it still incorrect then report it.

Besides:GCC 4.4.2 is coming soon

[techouse]

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

________________________________________________________________________________

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

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

Patches used:

x264_win_zone_parse_fix_06.diff (http://kemuri9.net/dev/x264/patches/x264_win_zone_parse_fix_06.diff)
x264_hrd_pd_interlace.16_r1281.diff (http://jeeb.pastebin.ca/1601582)

[rack04]

Using r1287 I get a crash using the following command line:

--profile baseline --preset slower --tune animation --crf 18 --level 3 --vbv-bufsize 10000 --vbv-maxrate 10000 --aud --sar 1:1 --output "C:\Personal\Videos\94518080-output.264" "C:\Personal\Videos\94518080.avs"

94518080.avs
LoadPlugin("C:\Program Files\DGAVCIndex\DGAVCDecode.dll")
AVCSource("C:\Personal\Videos\94518080.dga")
Spline64Resize(480,256)

Sample (http://www.megaupload.com/?d=HHTTTJ1H)

The video encodes normally using the following command line:

--preset slower --tune animation --crf 18 --aud --sar 1:1 --output "C:\Personal\Videos\94518080-output.264" "C:\Personal\Videos\94518080.avs"

[shroomM]

Tried using techouse's 1287 and unpatched 1286 from x264.nl, both had corrupted video...

Here's the generated stream (1286 x264.nl) ... http://www.mediafire.com/download.php?lzjzwmfdj4z

and here's the Techouse's... http://www.mediafire.com/download.php?njwl2yogmzz

The source was the 2012 trailer from Apple (http://www.apple.com/trailers/sony_pictures/2012/ - Trailer 2, 1080p).

Source file:
File : 2012-tlr2_h1080p.mov
Size : 225.797.353 bytes
SHA-1: 693d9f752be7fafe375426e26fd02fb426172d17

Demuxed video:
File : 2012-tlr2_h1080p_track1.h264
Size : 215.677.417 bytes
SHA-1: 974bba87c3f9103d09229a33d67e90757d0ea9a0

Indexed using DGAVCDec, log file:
Stream Type: AVC Elementary
Profile: Main
Level: 4.1
Frame Size: 1920x800
SAR: Unspecified
Display Size:
Frame Rate: 25.000000 fps
Colorimetry: BT.709 [1]
Frame Structure: Frame
Frame Type: not yet
Coded Number: 4033
Playback Number: 4033
Frame Repeats: 0
Field Repeats: 0
Bitrate: 1.575
Bitrate (Avg): 10.471
Bitrate (Max): 53.588
Elapsed: 0:00:11
Remain: 0:00:00
FPS:
Info: Finished!

My AVS script:
LoadPlugin("c:\Programs\DGAVCDec\DGAVCDecode.dll")
avcsource("2012-tlr2_h1080p_track1.dga")
ConvertToYV12()
AddBorders(0,140,0,140)
Spline36Resize(1280,720)
Trim(0,750)

The 1287 has Trim(500,750) to reduce the size of the stream.

The AVS script plays fine, without glitches.

x264 output (1286):
c:\work\2012>x264.exe --preset medium --tune film --pass 1 --bitrate 7000 --stats 2012.stats --level 4.1 --keyint 25 --bframes 3 --vbv-bufsize 30000 --vbv-maxrate 7000 --rc-lookahead 25 --output NUL 2012_software.avs
avis [info]: 1280x720 @ 25.00 fps (751 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [info]: profile Main, level 4.1
x264 [info]: frame I:46 Avg QP:15.87 size: 66662
x264 [info]: frame P:426 Avg QP:15.12 size: 39939
x264 [info]: frame B:279 Avg QP:15.02 size: 15979
x264 [info]: consecutive B-frames: 33.3% 40.3% 4.3% 22.1%
x264 [info]: mb I I16..4: 57.2% 0.0% 42.8%
x264 [info]: mb P I16..4: 36.2% 0.0% 0.0% P16..4: 27.4% 0.0% 0.0% 0.0% 0.0% skip:36.4%
x264 [info]: mb B I16..4: 4.3% 0.0% 0.0% B16..8: 17.2% 0.0% 0.0% direct:17.3% skip:61.2% L0:32.3% L1:41.1% BI:26.7%
x264 [info]: coded y,uvDC,uvAC intra: 54.0% 53.4% 39.4% inter: 23.6% 25.8% 11.5%

x264 [info]: i16 v,h,dc,p: 44% 28% 15% 13%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 22% 31% 13% 5% 6% 5% 7% 5% 6%
x264 [info]: kb/s:6534.93

encoded 751 frames, 31.26 fps, 6534.93 kb/s

c:\work\2012>x264.exe --preset medium --tune film --pass 2 --bitrate 7000 --stats 2012.stats --level 4.1 --keyint 25 --ref 3 --bframes 3 --vbv-bufsize 30000 --vbv-maxrate 7000 --rc-lookahead 25 --aud --output 2012.mp4 2012_software.avs
avis [info]: 1280x720 @ 25.00 fps (751 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [info]: profile High, level 4.1
mp4 [info]: initial delay 1 (scale 25)
x264 [info]: frame I:46 Avg QP:15.97 size: 70757
x264 [info]: frame P:426 Avg QP:15.06 size: 43238
x264 [info]: frame B:279 Avg QP:20.88 size: 4620
x264 [info]: consecutive B-frames: 33.3% 40.3% 4.3% 22.1%
x264 [info]: mb I I16..4: 38.1% 46.6% 15.3%
x264 [info]: mb P I16..4: 7.7% 20.2% 5.7% P16..4: 14.6% 9.1% 5.0% 0.0% 0.0% skip:37.7%
x264 [info]: mb B I16..4: 0.5% 0.8% 0.1% B16..8: 12.1% 0.6% 1.0% direct: 4.6% skip:80.3% L0:42.4% L1:48.3% BI: 9.3%
x264 [info]: 8x8 transform intra:56.9% inter:67.7%
x264 [info]: coded y,uvDC,uvAC intra: 61.2% 64.0% 58.6% inter: 17.0% 20.0% 11.6%

x264 [info]: i16 v,h,dc,p: 64% 18% 4% 14%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 17% 29% 25% 4% 5% 4% 5% 4% 6%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 19% 39% 17% 3% 5% 4% 5% 3% 4%
x264 [info]: ref P L0: 82.5% 11.9% 5.6%
x264 [info]: ref B L0: 88.9% 11.1%
x264 [info]: kb/s:6115.35

encoded 751 frames, 25.12 fps, 6115.35 kb/s

x264 output (1287):
c:\work\2012>x264_1287_techouse.exe --preset medium --tune film --pass 1 --bitrate 7000 --stats c:\work\2012\2012.stats --level 4.1 --keyint 25 --bframes 3 --vbv-bufsize 30000 --vbv-maxrate 7000 --rc-lookahead 25 --output NUL c:\work\2012\2012_software.avs
avis [info]: 1280x720 @ 25.00 fps (251 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [info]: profile Main, level 4.1
x264 [info]: frame I:26 Avg QP:20.17 size: 93538
x264 [info]: frame P:130 Avg QP:26.33 size: 40665
x264 [info]: frame B:95 Avg QP:26.37 size: 15812
x264 [info]: consecutive B-frames: 24.0% 57.8% 4.0% 14.2%
x264 [info]: mb I I16..4: 41.3% 0.0% 58.7%
x264 [info]: mb P I16..4: 29.4% 0.0% 0.0% P16..4: 39.9% 0.0% 0.0% 0.0% 0
.0% skip:30.7%
x264 [info]: mb B I16..4: 4.4% 0.0% 0.0% B16..8: 22.8% 0.0% 0.0% direct:
16.8% skip:56.1% L0:28.3% L1:36.1% BI:35.6%
x264 [info]: coded y,uvDC,uvAC intra: 68.2% 69.2% 56.5% inter: 27.8% 34.0% 13.4%

x264 [info]: i16 v,h,dc,p: 35% 36% 19% 10%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 23% 36% 10% 4% 5% 4% 7% 5% 6%
x264 [info]: kb/s:7347.11

encoded 251 frames, 21.55 fps, 7347.11 kb/s

c:\work\2012>x264_1287_techouse.exe --preset medium --tune film --pass 2 --bitrate 7000 --stats c:\work\2012\2012.stats --level 4.1 --keyint 25 --ref 3 --bframes 3 --vbv-bufsize 30000 --vbv-maxrate 7000 --rc-lookahead 25 --aud --output c:\work\2012\2012_1287.mp4 c:\work\2012\2012_software.avs
avis [info]: 1280x720 @ 25.00 fps (251 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [info]: profile High, level 4.1
mp4 [info]: initial delay 1 (scale 25)
x264 [info]: frame I:26 Avg QP:20.44 size: 97332
x264 [info]: frame P:130 Avg QP:26.02 size: 45084
x264 [info]: frame B:95 Avg QP:37.30 size: 3068
x264 [info]: consecutive B-frames: 24.0% 57.8% 4.0% 14.2%
x264 [info]: mb I I16..4: 25.3% 55.7% 19.0%
x264 [info]: mb P I16..4: 2.7% 13.2% 4.8% P16..4: 26.4% 15.0% 7.7% 0.0% 0
.0% skip:30.2%
x264 [info]: mb B I16..4: 0.1% 0.1% 0.0% B16..8: 18.4% 0.2% 0.3% direct:
5.5% skip:75.3% L0:43.5% L1:49.6% BI: 6.9%
x264 [info]: 8x8 transform intra:59.8% inter:77.0%
x264 [info]: coded y,uvDC,uvAC intra: 71.5% 73.3% 62.8% inter: 23.3% 31.3% 16.6%

x264 [info]: i16 v,h,dc,p: 62% 25% 8% 5%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 16% 40% 12% 4% 5% 5% 6% 5% 7%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 25% 40% 11% 3% 4% 4% 5% 3% 5%
x264 [info]: ref P L0: 79.9% 13.2% 6.9%
x264 [info]: ref B L0: 90.2% 9.8%
x264 [info]: kb/s:6918.80

encoded 251 frames, 19.28 fps, 6918.80 kb/s

Tried playing the MP4 in MPC using ffmpeg-mt, libavcodec and DivX H.264 decoder. All have the same problem.

The most obvious error shows at about 00:24 in the video (where the statue falls).

My specifications...
Intel Core i7 920
6GB RAM
Vista Business x64

The same glitches appeared when encoding on my second PC..
Core2 Quad Q9300
4GB RAM
Windows 7 Professional x64

Regards,
A

[LoRd_MuldeR]

Just a quick noob question...

The 1286 build on x264.nl (compiled with "32bit: gcc 3.4.6 make fprofiled") should be OK, yes?

The reason for asking is that I get some corrupted video with it and would just like to know if I should wait for 1287 or report the bug. :p

Thanks, A

The issue fixed in r1287 didn't cause any obvious artifacts and it's not for GCC 3.x.x compiler (as used for the x264.nl builds) anyway.

So if you get "corrupted video", then the problem must be elsewhere. But before blaming x264, you should first carefully check your source script as well as your hardware, if not already done so...

[techouse]

LOL, I don't know if I could handle another patch/commit today :P

[shroomM]

Yeah, it's been crazy today. Kudos to everyone :)

Just retried with r1287 on x264.nl, the same error occurs (both PCs). Same source.

Regards,
A

[Dark Shikari]

It's not a glitch, it's row-based VBV in B-frames acting up. Screw this shit, I add it to fix one issue and it causes another...

[techouse]

Here we go again....

[juGGaKNot]

but fixed (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=a65d36142b765516dd80a6bed5bff7444b24f4aa) so ... haha

[Dark Shikari]

Also, seriously, linking me to an Apple Trailers page is useless. I am not going to spend three hours trying to get my damned user-agent spoofing working just so I can download a movie to test a user-reported bug.

If you want me to fix your bugs, upload your movies in a place that it is actually possible for me to download them. If wget doesn't work I won't fix your bug.

[techouse]

If wget doesn't work I won't fix your bug.
Hahahahahahahahaha! That quote made my day :D :D :D

[shroomM]

Yeah, you are right, sorry about that, was a bit in a hurry when reporting it.

Will try to do better next time, I promise :)

[dragonkeeper]

For the last week I've been toying Encore trying to make it mux a blu-ray disk whereas i've used the x264 codec to encode the video. So far i have had no luck. As Encore will tell me I don't have the necessary codecs to render the video, or it wants to transcode the video (painfully slow process with their built in encoder), or it chokes on muxing the disk and has issues with buffer underflows. Can some one point me to a x264 build that produces Scenarist compliant streams?

[techouse]

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

________________________________________________________________________________

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

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

Patches used:

x264_win_zone_parse_fix_06.diff (http://kemuri9.net/dev/x264/patches/x264_win_zone_parse_fix_06.diff)
x264_hrd_pd_interlace.16_r1281.diff (http://jeeb.pastebin.ca/1601582)

[shroomM]

In case you still need it, here's the file, shortened and still produces artifacts...

http://www.filedropper.com/trl

Didn't really know in which format to put it, so I used Y4M (640x352), I hope that's OK...

The command line ...

x264_1288_techouse.exe --preset medium --tune film --pass 1 --bitrate 7000 --stats c:\work\2012\2012.stats --level 4.1 --keyint 25 --bframes 3 --vbv-bufsize 30000 --vbv-maxrate 7000 --rc-lookahead 25 --output NUL trl.y4m 640x352
x264_1288_techouse.exe --preset medium --tune film --pass 2 --bitrate 7000 --stats c:\work\2012\2012.stats --level 4.1 --keyint 25 --ref 3 --bframes 3 --vbv-bufsize 30000 --vbv-maxrate 7000 --rc-lookahead 25 --aud --output c:\work\2012\2012_1288_th.mp4 trl.y4m 640x352

Edit: saw in the other post that it's fixed already. Damn, you're quick! :)

[rack04]

x264_x86_r1289M (http://www.megaupload.com/?d=K0S3MUES)

Built by rack04 on October 12, 2009, 3:49:58 PM CST
gcc.exe (GCC) 4.4.1 (x86.core2.Komisar)
--extra-cflags="-march=core2"
make fprofiled

Patched with:

x264_hrd_pd_interlace.16_r1281.diff (http://jeeb.pastebin.ca/1601582)
x264_win_zone_parse_fix_06.diff (http://kemuri9.net/dev/x264/patches/x264_win_zone_parse_fix_06.diff)

[techouse]

Damn, this will be the 4th build today... This is worse than running a marathon :P

[techouse]

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

________________________________________________________________________________

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

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

Patches used:

x264_win_zone_parse_fix_06.diff (http://kemuri9.net/dev/x264/patches/x264_win_zone_parse_fix_06.diff)
x264_hrd_pd_interlace.16_r1281.diff (http://jeeb.pastebin.ca/1601582)

[Blue_MiSfit]

Get ready for another one if Dark_Shikari fixes the bug I just found... :P

~MiSfit

[techouse]

I have unending love for the project so you can rest assured that I will build wahatever you throw at me in the shortest amount of time. :)

[kemuri-_9]

[18:39] <Dark_Shikari> blue_misfit: committed locally
[18:39] <Dark_Shikari> since it's an old/rare bug, I won't push it right now


so you can rest easy at the compiling trigger..... for now :devil:

[techouse]

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

________________________________________________________________________________

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

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

Patches used:

x264_win_zone_parse_fix_06.diff (http://kemuri9.net/dev/x264/patches/x264_win_zone_parse_fix_06.diff)
x264_hrd_pd_interlace.16_r1281.diff (http://jeeb.pastebin.ca/1601582)

[elguaxo]

What kind of glitches were addressed here (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=e381f6d0093504a545fe4d90e3a6f178c6877cc7)? I did some encodes with 1281 using that options (slow-firstpass + weightb + multiref + 2pass) and I wonder if I should do them again.

[kemuri-_9]

What kind of glitches were addressed here (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=e381f6d0093504a545fe4d90e3a6f178c6877cc7)? I did some encodes with 1281 using that options (slow-firstpass + weightb + multiref + 2pass) and I wonder if I should do them again.

i saw someone's generated video stream that was affected by this specific bug,
it had a stutter-like effect visible in numerous macroblocks when progressing in a smoothly panning scene.

[elguaxo]

it had a stutter-like effect visible in numerous macroblocks when progressing in a smoothly panning scene.

Thanks, I'll check for that.

[juGGaKNot]

Writing library : x264 core 77 r1292M e381f6d
Encoding settings : cabac=1 / ref=5 / deblock=1:0:0 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / 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 / constrained_intra=0 / bframes=3 / b_pyramid=0 / b_adapt=2 / b_bias=0 / direct=2 / wpredb=1 / keyint=300 / keyint_min=30 / scenecut=40 / rc_lookahead=60 / rc=2pass / mbtree=1 / bitrate=4300 / ratetol=2.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=20000 / vbv_bufsize=20000 / ip_ratio=1.40 / aq=2:1.00

I do not see nal-hrd in mediainfo with the latest builds, is this normal ?

start "encode" /b /low /wait "%mypath%\bin\x264.exe" --pass 1 --preset veryslow --level %mylevel% --bitrate %btrate_x264% --stats "%mypath%\%mpath%\T1\movie.stats" --ref %myrefs% --min-keyint %mint% --keyint %kint% --bframes 3 --ratetol 2.0 --merange 32 --direct temporal --aq-mode 2 --no-fast-pskip --no-dct-decimate --sar 1:1 --vbv-maxrate 20000 --vbv-bufsize 20000 --nal-hrd --aud --output NUL %myavs%

[VFR maniac]

Trahald's nal-hrd patch doesn't write parameter string in User Data Unregistered SEI, while Alex's does.

[ACrowley]

Ive one last Question about VBV.

So far i know VBV is recommend in with 2 pass and not in 1 pass.

But the VBV Algorythm was updated a few Times.
Is VBV recommend in 1 pass CRF ? Or should i better use 2 pass with VBV?
X264 Wiki :
"It is highly recommended, though not required, to use 2pass bitrate mode with VBV"

I need VBV to handle high Peaks because i use Standalones for Playback.

[LoRd_MuldeR]

Ive one last Question about VBV.

So far i know VBV is recommend in with 2 pass and not in 1 pass.

But the VBV Algorythm was updated a few Times.
Is VBV recommend in 1 pass CRF ? Or should i better use 2 pass with VBV?
X264 Wiki :
"It is highly recommended, though not required, to use 2pass bitrate mode with VBV"

I need VBV to handle high Peaks because i use Standalones for Playback.

That information is outdated. In up-to-date x264 the 1-Pass VBV (CRF mode) should work perfectly fine. I think the Lookahead VBV, introduced in r1213, fixed it :)

You should decided 2-Pass -vs- CRF depending on whether you want to hit a specific level of quality or you want to hit a specific file size...

[shon3i]

Dark Shikari last time very clear say that 1pass VBV algo is more stable and recommended than 2pass algo. I personaly newer have issues with 2pass VBV, little in early days (which is fixed) and with your killer sample.

[ACrowley]

Dark Shikari last time very clear say that 1pass VBV algo is more stable and recommended than 2pass algo. I personaly newer have issues with 2pass VBV, little in early days (which is fixed) and with your killer sample.

So VBV ist Ok and safe in both modes today...THX

[Blue_MiSfit]

Yeah. 1 pass VBV is actually pretty awesome :) 2 passes is basically no longer necessary for CBR anyway :D

[iko417]

I was wondering where i can download compiled up-to-date x264.exe with mixaq patch integrated?
The last version i have is "x264.1240.mixaq32.exe".

Forgot to mention in that file i have it has enabled
aq-mode 2
mb-tree

Thanks,
Ivan

[Rodger]

Hi guys!
Since it seems again there is a problem with the update servers,

which is the the current realease advised to use with Megui?

[Astrophizz]

That request should be posted in the MeGUI thread. I don't think MeGUI has been updated in a while but look on the thread to see if a new update server has been posted (last I checked kurtnoise was hosting it).

[LoRd_MuldeR]

I was wondering where i can download compiled up-to-date x264.exe with mixaq patch integrated?
The last version i have is "x264.1240.mixaq32.exe".

Forgot to mention in that file i have it has enabled
aq-mode 2
mb-tree

Thanks,
Ivan

AQ Mode 2 is committed, any up-to date x264 build does have it. The same applies to MB Tree.

[iko417]

AQ Mode 2 is committed, any up-to date x264 build does have it. The same applies to MB Tree.

What about "mixaq", i have really good results with that, i like to encode with smaller bitrate and with mixaq i'm getting good picture.

Thanks for your reply.

[LoRd_MuldeR]

What about "mixaq", i have really good results with that, i like to encode with smaller bitrate and with mixaq i'm getting good picture.

Thanks for your reply.

Well, there was an unofficial "MixAQ" patch floating around. But it seems most people building x264 don't use it currently.

Also the only MixAQ patch I found by a quick search is for x264 r1240. So if somebody is still interested in this patch, he would need to update the patch for x264 r1292, I guess ;)

x264_MixAQ_r1240.diff (http://jeeb.pastebin.ca/1547858) -> Rejects (http://pastie.org/659399)

[VFR maniac]

MixAQ had been born in my idea, and I have been maintaining it now. (Main maintainer seraphy had dropped of supporting it now because he is busy.)
If you want to encode with MixAQ builds, download my x264_DANGEROUS builds.
They are available from here (http://www.esnips.com/web/x264dangerous).


x264_DANGEROUS is highly dangerous builds, because they are applied with many patches and my programming knowledge and skill is poor.
The builds includes fgo, thread_pool, nal-hrd(19), Japanese AQ(MixAQ and/or OreAQ) and timestamps control.

I think weak fgo + psy-rd keep constant grain well on Japanese Anime.

Timestamps control (http://www.esnips.com/doc/62941ca8-7eec-4cf3-9c33-0f50983a773e/x264_ts_ctrl_10_r1281) is available for direct VFR output.
This patch supports VFR VBV, but it is still incomplete because I don't understand ratecontrol algorithm sufficiently.
VBV underflows cause on 2pass encoding, especially when the frame rate bursts locally.
This patch also eliminates initial decoding delay for B-frames in MP4 container with DTS hacking.

[iko417]

Thank you both, VFR maniac & LoRd_MuldeR

[JEEB]

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

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

________________________________________________________________________________

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

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


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

built on Oct 19 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_r1281.diff (http://jeeb.pastebin.ca/1601582)


おもちうにょ～ん。

[techouse]

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

________________________________________________________________________________

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

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

Patches used:

x264_win_zone_parse_fix_06.diff (http://kemuri9.net/dev/x264/patches/x264_win_zone_parse_fix_06.diff)
x264_hrd_pd_interlace.16_r1281.diff (http://jeeb.pastebin.ca/1601582)

[Dark Shikari]

Perfect timing, techouse! :p:p:p:p

[wyti]

speaking of updates : "Make B-pyramid spec-compliant"
is the second mode is fully compliant ? it's only blue-ray who use it's own rules and need more to be blue-ray compliant right ?

[Dark Shikari]

speaking of updates : "Make B-pyramid spec-compliant"
is the second mode is fully compliant ? it's only blue-ray who use it's own rules and need more to be blue-ray compliant right ?Correct.

[techouse]

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

________________________________________________________________________________

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

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

Patches used:

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

[rack04]

I get the following error when I try to fprofile:

http://i11.photobucket.com/albums/a199/rack04/x264.jpg

gcc.exe (GCC) 4.4.1 (x86.core2.Komisar)
--extra-cflags="-march=core2"
make fprofiled

Patched with:

x264_hrd_pd_interlace.16_r1281.diff (http://jeeb.pastebin.ca/1601582)
x264_win_zone_parse_fix_06.diff (http://kemuri9.net/dev/x264/patches/x264_win_zone_parse_fix_06.diff)

[moviefan]

Concerning the new b-pyramid description in the GIT log, does it mean the 2nd method is not Blu-ray compliant?

[juGGaKNot]

Concerning the new b-pyramid description in the GIT log, does it mean the 2nd method is not Blu-ray compliant?

--b-pyramid strict: Strictly heirarchical pyramid
--b-pyramid normal: Non-strict (not Blu-ray compatible)

1) strict b-pyramid, while worse for compression, follows the rule mandated by Blu-ray (no P-frames can reference B-frames)
2) normal b-pyramid, which is like the old mode except fully compliant.

http://forum.doom9.org/showthread.php?t=108570&page=45 last post, 898.

[Kurtnoise]

Concerning the new b-pyramid description in the GIT log, does it mean the 2nd method is not Blu-ray compliant?
if you want BD compliancy, use --b-pyramid strict




edit: /me too slow

[moviefan]

Fine, thanks guys! Is the nal-hrd again incompatible to the latest revision?

[VFR maniac]

I get the following error when I try to fprofile:

Rename nal-hrd's i_dts. Please don't remove that.
B-pyramid implementation's i_dts is not equal to nal-hrd's.

[shon3i]

Ok how is now safe to use --b-pyramid strict with --ref 4 and --bframes 3 since every encoder (mc, elecard, ateme....) automaticly decrase number of ref's or bframes if some ilegal combination is set. For example allowed combinations in scenarist/cinevision are:

3 bframes + 3refs + pyramid = allowed
3 bframes + 4refs = allowed
2 bframes + 4refs + pyramid = allowed

3 bframes + 4refs + pyramid = not allowed ref decrased to 3.

Generaly same problem is been with old x264 pyramid. The question is that, did will x264 automaticly decrase or warn settings that make violation

[VFR maniac]

x264_x86_r1301_with_nal-hrd_16.rar (http://www.mediafire.com/download.php?iyhjod2e2dn)

gcc: 4.4.1-dw2 (TDM-2)
-march=core2

[akupenguin]

2 bframes + 4refs + pyramid = allowed
3 bframes + 4refs + pyramid = not allowed ref decrased to 3.
No. Number of b-frames doesn't affect DPB size.

[kemuri-_9]

GCC 4.4.2 released,
those using 4.4.1 should update when possible.

[moviefan]

No. Number of b-frames doesn't affect DPB size.

So 3 b-frames + 4 refs + b-pyramid strict should be fine for 1080p24 Blu-ray compliance?

[shon3i]

No. Number of b-frames doesn't affect DPB size.
My mistake, but original question stays: is 3 bframes + 4refs + pyramid (strict) allowed?, or can do violation as previous?

should be fine for 1080p24 Blu-ray compliance? Something still not smell good to me :) Anyway bpyramid strict can't incrase quality that much.

[jpsdr]

According a lot of things i've read, 4 ref without bpyramid, 3 ref with bpyramid.

[akupenguin]

is 3 bframes + 4refs + pyramid (strict) allowed?
Yes. --refs selects the DPB size, and individual frames just use as many refs as they can within that constraint.
(Except that pyramid forces the DPB to be at least 4, so if you select a smaller value of --refs it skips motion search on some of them, thus only using the specified number for inter prediction. Which means that "--b-pyramid strict --refs 4" is now the same as "--b-pyramid strict --refs 3", since both imply DPB=4 and strict pyramid with DPB=4 never has more than 3 refs available for any given frame. "--b-pyramid normal --refs 4" sometimes can use 4 refs, and thus is different from "--b-pyramid normal --refs 3" even though they have the same DPB.)

According a lot of things i've read, 4 ref without bpyramid, 3 ref with bpyramid.
A lot of things you've read were written before today's commit.

[shon3i]

"--b-pyramid strict --refs 4" is now the same as "--b-pyramid strict --refs 3"That is i want to hear. So basicly encoder decrase refs?

[JEEB]

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

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

________________________________________________________________________________

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

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


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

built on Oct 19 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_r1301.diff (http://www.mediafire.com/download.php?iyhjod2e2dn)


Over 1300～なの

[rack04]

x264_x86_r1301M (LINK)

Built by rack04 on October 19, 2009, 4:14:04 PM CST
gcc.exe (GCC) 4.4.2 (x86.generic.Komisar)
--extra-cflags="-march=core2"
make fprofiled

Patched with:

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

[Alf Bundy]

Hi, what is the default now with the new b-pyramid spec-compliant ?

--b-pyramid / --b-pyramid normal / --b-pyramid strict / or not set by default ?


Sorry to ask, but I don't know (yet) how to use command line --longhelp.
I tried (in WinXP) Start -> Run -> "path to\x264.exe" --longhelp, but the command window only shows for a tenth of a second, and I'm too slow to hit "pause/break" in time. :(

x264.exe used : rack04's build just above (x264_x86_r1301M). Thanks

[bob0r]

Hi, what is the default now with the new b-pyramid spec-compliant ?

--b-pyramid / --b-pyramid normal / --b-pyramid strict / or not set by default ?


Sorry to ask, but I don't know (yet) how to use command line --longhelp.
I tried (in WinXP) Start -> Run -> "path to\x264.exe" --longhelp, but the command window only shows for a tenth of a second, and I'm too slow to hit "pause/break" in time. :(

x264.exe used : rack04's build just above (x264_x86_r1301M). Thanks

Start -> Run -> cmd -> cd "path to x264.exe" -> x264.exe --longhelp

[Alf Bundy]

Thanks bob0r, I will finally be able to encode without the help of GUI's. :)

And thanks to all of you being involved in x264 development. Great work !

[benwaggoner]

Start -> Run -> cmd -> cd "path to x264.exe" -> x264.exe --longhelp
And if you'd like to review it in your favorite text reader, just append ">x264_longhelp.txt" to the end of your command line to dump the --longhelp output into a .txt.

[Widok]

JEEB, techouse
Why you do not use x264_AQ2mod.diff? After all in a theme (http://forum.doom9.org/showthread.php?t=147067) more than positive responses.
You after all are not afraid of innovative decisions in a positive side influencing quality of a coded material?

[LoRd_MuldeR]

JEEB, techouse
Why you do not use x264_AQ2mod.diff? After all in a theme (http://forum.doom9.org/showthread.php?t=147067) more than positive responses.
You after all are not afraid of innovative decisions in a positive side influencing quality of a coded material?

If you refer to "AutoVAQ" (that is what was discussed in the theread (http://forum.doom9.org/showthread.php?t=147067) you link to), then the patch isn't used because its superflous ;)

AutoVAQ has been committed long ago and is available as "--aq-mode 2" in any unmodified build of x264.

[komisar]

LoRd_MuldeR, Widok refer to new variant of commited patch. In new version BugMaster add additional parameter to --aq-strength... AQ2mod patch (http://forum.doom9.org/showthread.php?p=1331855#post1331855)

[Dark Shikari]

x264 needs fewer psy options, not more. I refuse to commit any patch that increases the number of tweakable psy options unless extraordinary evidence is shown to me suggesting that it is useful.

If an feature needs user tweaking to make it useful, the feature is useless.

(On a related note, I have it on my agenda to eventually merge psy-trellis with psy-RD for this reason.)

[Widok]

komisar Thanks for specification.

LoRd_MuldeR
x264_AQ2mod.diff (Add second parameter for strength in AQ-modes
"#1:#2" where #1 - aq-strength; #2 - frame QP offset;
#2 >0.0 -- more 'loves' fades and dark frames (1.0 -- optimal).
Patch made by BugMaster)
--aq-mode 2 --aq-strength 1.0:1.0

[Dark Shikari]

Allocating more bits to dark frames should be controlled by qcomp, not by a second AQ parameter.

[komisar]

Dark Shikari, qcomp with mb-tree mean differ than without mb-tree

[Dark Shikari]

Dark Shikari, qcomp with mb-tree mean differ than without mb-treeThen x264 should compensate, not the user.

[komisar]

Dark Shikari :) if x264 could not compensate, maybe user try... moreover second aq-strength parameter can be omitted and remain the "standard" behavior...

[LoRd_MuldeR]

Dark Shikari :) if x264 could not compensate, maybe user try... moreover second aq-strength parameter can be omitted and remain the "standard" behavior...

Still the proper/desired solution would be to find out why the second parameter must be adjusted at all and how the optimal value depends on the video content. Then one could develop an algorithm that will do the required adjustment automatically...

[komisar]

LoRd_MuldeR, BugMaster may describe more correct this changes

P.S. small tests from www.x264.info (http://www.x264.info/2009-08/aq-mode-3/)

[Ulf]

Why doesn't --aud show up in --longhelp for the latest patched versions of x264? It's a part of "x264_hrd_pd_interlace.16_r1301.diff" as far as I have understood.

[kemuri-_9]

the help description for aud moved to --fullhelp with that revision that added the --fullhelp option.

[LoRd_MuldeR]

And it's not a part of the HRD patch. It's supported by unmodified x264 from GIT.

But if you are using x264 with the HRD patch, then you probably are targeting for BluRay and then you also need to enabled AUD (Access Unit Delimiters).

[burfadel]

I have to say, the AQ mod patch (setting aq-strength to 1.0:1.0) seems to work quite well. Perceptively it seems better, thats the main thing :) I'm guessing from what I've read on here though that it won't be committed though...

[menlvd]

I have to say, the AQ mod patch (setting aq-strength to 1.0:1.0) seems to work quite well. Perceptively it seems better, thats the main thing :) I'm guessing from what I've read on here though that it won't be committed though...

using that a long time. mine things same - quite well :)

[JEEB]

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

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

________________________________________________________________________________

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

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


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

built on Oct 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_r1301.diff (http://www.mediafire.com/download.php?iyhjod2e2dn)


Patches seem ok by the log, let's see how it goes.

[rack04]

x264_x86_r1310M (http://www.mediafire.com/?sharekey=293e523b0b16a6678d78a0e555291609e04e75f6e8ebb871)

Built by rack04 on October 27, 2009, 9:22:27 AM CST
gcc.exe (GCC) 4.3.4 (x86.core2.Komisar)
--extra-cflags="-march=core2"
make fprofiled

Patched with:

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

[rack04]

x264_x86_r1318M (http://www.mediafire.com/?sharekey=63dbd186229a03b16b21be4093fab7ace04e75f6e8ebb871)

Built by rack04 on October 30, 2009, 9:15:04 AM CST
gcc.exe (GCC) 4.3.4 (x86.core2.Komisar)
--extra-cflags="-march=core2"
make fprofiled

Patched with:

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

[JEEB]

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

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

________________________________________________________________________________

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

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


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

built on Oct 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_r1301.diff (http://www.mediafire.com/download.php?iyhjod2e2dn)

[Fr4nz]

Where are techouse and imk? I want them... :\

[juGGaKNot]

Where are techouse and imk? I want them... :\

Patch not enough ? :)

or do you want 4.4.2 ?

[Fr4nz]

Patch not enough ? :)

or do you want 4.4.2 ?

Well, I was interested in ICC x264 compiled versions...

PS: Imk has been missing for 3 weeks in this forum...I'm starting to worry... :\
Anyone has infos about him?

[aegisofrime]

imk's builds have never worked for me :( Does it have anything to do with the fact that I'm using the Phenom II?

[XhmikosR]

I don't know why they don't work for you, but they always worked for me (Intel Q6600). And speed improvement wasn't bad. :)

[LoRd_MuldeR]

imk's builds have never worked for me :( Does it have anything to do with the fact that I'm using the Phenom II?

By default ICL 11 uses "/arch:SSE2", so you need a SSE2-capable CPU at least. That should be okay for the Phenom II though.

But if the "/Qx" option is used (maybe imk used that switch), ICL generates a binary that will run on Intel CPU's only. It will simply abort on Non-Intel CPU's :rolleyes:

However with "/arch:IA32 /QaxSSE2" it should generate a binary that will run on any x86 CPU, but still use a SSE2 optimized path on Intel CPU's.

[roozhou]

So far I have not seen any ICL x264 build running faster than GCC 4 or MSVC build. I tested on Core2, P4E and K8, all slower than GCC and MSVC build.

IMO from /arch:SSE2 programs only benefits on running SSE2 float point instructions instead of FPU instructions.

[LoRd_MuldeR]

Well, you could also use ""/arch:IA32 /QaxSSE2,SSE4.1" to generate three code paths (generic x86, SSE2-optimized and SSE4.1-optimized).

Not sure if x264 does benefit form that though, because I did not test it yet ;)

[aegisofrime]

Thanks for the reply Lord Mulder. I had to search the thread to find Imk's last post.

The relevant portion of his build info is here:

Patches used:
x264_icc_09_win.diff
x264_win_zone_parse_fix_06.diff

Common build arguments for icc:
-O3 -Qprec-div- -Qstd=c99 -I. -I.. -I./resources -I../common
-I../encoder -I../extras -I./pth -DNDEBUG -DHAVE_MMX
-DAVIS_INPUT -DHAVE_PTHREAD -DPTW32_STATIC_LIB -DUSE_REAL_PTHREAD
-D_MBCS -EHsc -MT -W0 -nologo -c

Specific build arguments for icc:
-QxSSE2
-Qprof_gen -Qprof_dir. (for generating profiling information)
-Qipo -Qprof_use -Qprof_dir. (for using the profiling information)
-DARCH_X86 (for 32-bit build)
-DARCH_X86_64 (for 64-bit build)

Additional flags used for icc:
-D_LIB (when building libx264.lib)
-D_CONSOLE -DWIN32 (when building x264.exe)
-DMP4_OUTPUT
-DIMF (if built with IMF)

Looks like /qx is used?

@roozhou: I have seen before a build comparison page, the location of which escapes me now, that shows Imk's builds consistently being a few FPS faster than gcc builds. Which in the course of a 2 hr video can be quite substantial I guess.

[Fr4nz]

@roozhou: I have seen before a build comparison page, the location of which escapes me now, that shows Imk's builds consistently being a few FPS faster than gcc builds. Which in the course of a 2 hr video can be quite substantial I guess.

Well, IIRC the speedup reported by Imk was in order of 2-3% ...minimal, but better than nothing :D

[XhmikosR]

I had done a little benchmark (http://forum.doom9.org/showthread.php?p=1246872#post1246872).

EDIT: imk has also posted a few benchmarks (http://spreadsheets.google.com/pub?key=pbffjdC6iUPWs2HtYHwZ2VQ&hl=sv).

[LoRd_MuldeR]

Thanks for the reply Lord Mulder. I had to search the thread to find Imk's last post.

The relevant portion of his build info is here:

Specific build arguments for icc:
-QxSSE2
-Qprof_gen -Qprof_dir. (for generating profiling information)
-Qipo -Qprof_use -Qprof_dir. (for using the profiling information)
-DARCH_X86 (for 32-bit build)
-DARCH_X86_64 (for 64-bit build)

Looks like /qx is used?

Yes. That build will run on SSE2-capable Intel CPU's only!

I would recommend imk to use "/arch:IA32 /QaxSSE2" or at least "/arch:SSE2 /QaxSSE2" to make builds that are optimized specifically for Intel CPU's and still run on Non-Intel's.

More info: http://cache-www.intel.com/cd/00/00/22/23/222300_222300.pdf

[Fr4nz]

Yes. That build will run on SSE2-capable Intel CPU's only!

I would recommend imk to use "/arch:IA32 /QaxSSE2" or at least "/arch:SSE2 /QaxSSE2" to make builds that are optimized for Intel CPU's and still run on Non-Intel's.

Unfortunately Imk seems to be missing...is here anyone able to make ICC builds, like the imk ones?

[JEEB]

The last I saw the Intel C/C++ compilers for Windows

A) weren't free even for personal use
B) had some bugs around here and there in binaries (if that was just due to some compiler options, I do not know)

[LoRd_MuldeR]

Unfortunately Imk seems to be missing...is here anyone able to make ICC builds, like the imk ones?

The problem is that the MSVC project files for x264 have been removed. And don't know to compile x264 with ICC without a MSVC project file ;)

Nor do I currently have the time to find it out. Compiling with GCC is easy, because you can use the original configure/make files.

The last I saw the Intel C/C++ compilers for Windows

* A) weren't free even for personal use

You can get a 30 days evaluation copy for free. That's not the problem at all.

[JEEB]

You can get a 30 days evaluation copy for free. That's not the problem at all.

Oh yes, you can get an evaluation copy indeed. But that would really restrict the time area I could build stuff in ;).

And yeah, the MSVC project files got removed :3

[LoRd_MuldeR]

Oh yes, you can get an evaluation copy indeed. But that would really restrict the time area I could build stuff in ;).

You can request a new evaluation copy after 30 days. Not really nice, but at least a way to use ICC. If it really produces faster code, it's worth the effort, I think ;)

And yeah, the MSVC project files got removed :3

So how do people build x264 with ICC? From the commandline or from MSVC? With a fully custom build script / project file? Or even with a modified x264 make file?

If somebody can put me to the right direction, I probably could manage to make a build...

[XhmikosR]

@LM: Download the latest (http://imk.cx/pc/x264/x264-r1271M-imk-win.7z) available ICL build from imk and see the readme. The process is well described although I did tried in the past to build an ICL build of x264 but didn't succeed.

EDIT: BTW if you figure out how to compile an ICL build, share your knowledge. :)

[LoRd_MuldeR]

@LM: Download the latest (http://imk.cx/pc/x264/x264-r1271M-imk-win.7z) available ICL build from imk and see the readme. The process is well described although I did tried in the past to build an ICL build of x264 but didn't succeed.

EDIT: BTW if you figure out how to compile an ICL build, share your knowledge. :)

It seems x264 sources need to be patched for ICL. But the provided patch fails with current x264.

Until somebody updates the ICL patch for up-to-date x264, I give up ;)

[XhmikosR]

I know, I was hoping that you were gonna do it. :p

[roozhou]

@roozhou: I have seen before a build comparison page, the location of which escapes me now, that shows Imk's builds consistently being a few FPS faster than gcc builds. Which in the course of a 2 hr video can be quite substantial I guess.

A few FPS faster, are you joking? Even doing real-time encoding, a few FPS faster means more than 10% speed boost!!

If both built with profiling, the performance difference should always be less than 1%.

[brunogm]

Just a question, if it is possible to use the LLVM 2.6/ (http://lwn.net/Articles/358646/) and if someone already tested?

[boxXx]

One tiny little question, i updated my x264 to the newest build but now when i want to run my Process it says :

[Error] An error occurred: x264 [error]: could not open input file 'J:\rescue\1.avs'

Any idea ? i tried some older versions but it wont work at all...

[bob0r]

Open 'J:\rescue\1.avs' with VirtualDub. And see what error it gives.

[boxXx]

does it just fine, its when i start the process, when i open it in Vdub there's no problem.

[J_Darnley]

Do you have 64-bit x264? Do you have 64-bit avisynth?
If you said yes to the first, you need to say second. Or pipe it with something like avs2yuv

[Audionut]

Weightp just got commited. :)

[juGGaKNot]

Indeed, am 2 bugs fixed on it.

but

All weightp modes may cause minor breakage in non-compliant decoders that take shortcuts in deblocking reference frame checks.
"Smart" may cause serious breakage in non-compliant decoders that take shortcuts in handling of duplicate reference frames.

What decoders ?

[Astrophizz]

CoreAVC for one, as has already been stated. Fix should be in 2.0.

[juGGaKNot]

About that i know but divx one ?

[jpsdr]

It seems x264 sources need to be patched for ICL. But the provided patch fails with current x264.

Until somebody updates the ICL patch for up-to-date x264, I give up ;)

Does compile with Intel compiler realy worth it ?
I mean, is all the code of x264 written in C (or C++),
or are the critical parts written in assembler ?
In the last case, compile with Intel compiler
is not realy worthwile.

[jethro]

Does compile with Intel compiler realy worth it ?
I mean, is all the code of x264 written in C (or C++),
or are the critical parts written in assembler ?
In the last case, compile with Intel compiler
is not realy worthwile.

Maybe this is true, but it is faster in real encodings.

I had done a little benchmark (http://forum.doom9.org/showthread.php?p=1246872#post1246872).

EDIT: imk has also posted a few benchmarks (http://spreadsheets.google.com/pub?key=pbffjdC6iUPWs2HtYHwZ2VQ&hl=sv).

[DarkZell666]

Does compile with Intel compiler realy worth it ?
I mean, is all the code of x264 written in C (or C++),
or are the critical parts written in assembler ?
In the last case, compile with Intel compiler
is not realy worthwile.

The critical parts are written in assembly language indeed, so the benefit from using compiler X vs compiler Y (be it icc, msvc, gcc or anything else) won't be more than 1%, give or take.
However, 1% is still better than nothing ;)

[roozhou]

The critical parts are written in assembly language indeed, so the benefit from using compiler X vs compiler Y (be it icc, msvc, gcc or anything else) won't be more than 1%, give or take.
However, 1% is still better than nothing ;)

The fact is benefit of compiling with profiling is ~3% using gcc and ~5% using msvc. Since the asm part benefit little from profiling, apparently C language part of x264 does take a significant part in performance.

[Dark Shikari]

The fact is benefit of compiling with profiling is ~3% using gcc and ~5% using msvc. Since the asm part benefit little from profiling, apparently C language part of x264 does take a significant part in performance.On a Core i7, 40% of time is spent in C functions, roughly.

[rack04]

x264_x86_r1330M (http://www.mediafire.com/?znexi3tmrzm)

Built by rack04 on November 9, 2009, 9:17:38 AM CST
gcc.exe (GCC) 4.3.4 (x86.core2.Komisar)
--extra-cflags="-march=core2"
make fprofiled

Patched with:

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

[aegisofrime]

Did anyone else find R1330 slower? Usually on my TGMC encodes I get from 10 to 11 FPS, but now I'm running at 7.8 FPS. Is it because of Weighted-P?

[JEEB]

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

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

________________________________________________________________________________

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

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


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

built on Nov 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_pd_interlace.16_r1301.diff (http://www.mediafire.com/download.php?iyhjod2e2dn)


Okies, doesn't seem to be miscompiled (tested with the patched 64bit build). Although if you do find something, please do mention.

[wyti]

Yes weightedp slow things down, you can desactivate it and see if it help

[aegisofrime]

Yes weightedp slow things down, you can desactivate it and see if it help

Is the quality worth the performance tradeoff? Hope this question is okay, since the thread is about patches and how they affect output afterall. :thanks:

[microchip8]

Is the quality worth the performance tradeoff? Hope this question is okay, since the thread is about patches and how they affect output afterall. :thanks:

It helps a lot in fades, esp with mbtree on

[juGGaKNot]

If you have a lot of fades, for my source it is.

[wyti]

Weighted P is only used on fade detection for now, may weighted P be useful for something else (and on the future have a weightedp 3 who would increase quality in a lot of case ) or is weightedp only useful on fades ?

[LoRd_MuldeR]

I have noticed it is used also in sequences that contain no fades. So it seems to do 'something' even on non-fade sequences.

Well, maybe those sequences are "fades" in Weight-P's definition, but I wouldn't have classified those as fades.

Anyway, I think we can assume that Weight-P may even help in places where we (as humans) wouldn't have expected fades...

[microchip8]

there was a weightp 3 option, which was k-means, but it was dropped for some reasons and you'll have to ask the devs why. Note that dropped in this case does not mean that it'll never hit x264 at some point in the future. There were some issues with it and it was decided (IIRC) to work on it after weightp was committed so in the future the devs may very well add it at some point

[rack04]

x264_x86_r1332M (http://www.mediafire.com/?1dkzyxz0jyo)

Built by rack04 on November 10, 2009, TIME 9:04:01 CST
GCC 4.3.4 (x86.core2.Komisar)
--extra-cflags="-march=core2"
make fprofiled

Patched with:

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

[techouse]

x264_x64_r1332_unpatched (http://techouse.project357.com/builds/revision1332/x264.exe) | MD5 (http://techouse.project357.com/builds/revision1332/x264.md5)
GCC 4.4.2 20091019 (x86_64.core2.Komisar), unpatched, generic, fprofiled

________________________________________________________________________________

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

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

Patches used:

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


P.S.: The reason why i haven't built any new revisions in the past 2 weeks is that my PSU died and I had to wait 2 damn weeks for a new one. Yea...shit happens...

[techouse]

x264_x64_r1336_unpatched (http://techouse.project357.com/builds/revision1336/x264.exe) | MD5 (http://techouse.project357.com/builds/revision1336/x264.md5)
GCC 4.4.2 20091019 (x86_64.core2.Komisar), unpatched, generic, fprofiled

________________________________________________________________________________

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

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

Patches used:

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

[JEEB]

x264 r1336 64bit unpatched:
download (http://x264.fushizen.eu/files/revision1336/x264.exe) ; hash (http://x264.fushizen.eu/files/revision1336/x264.md5)

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

________________________________________________________________________________

x264 r1336 32bit
download (http://x264.fushizen.eu/files/1336/x264.exe) ; release notes

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


x264 r1336 64bit
download (http://x264.fushizen.eu/files/1336_x64/x264.exe) ; release notes

built on Nov 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_pd_interlace.16_r1301.diff (http://www.mediafire.com/download.php?iyhjod2e2dn)


Lazy compiler posts lazy builds :3 Switched from the .jp server to the fushizen domain as the .jp one was acting weirdly (and because it will be taken offline in March or so).

[MasterNobody]

x264 r1336 32/64 bit compiled with ICC 11.1: download (http://stashbox.org/697692/x264_1336_icc.rar); x264_icc_r1336.diff patch (http://stashbox.org/697652/x264_icc_r1336.diff)
"Qax" builds was compiled with /QaxSSE4.2 option but in reality they can be even slower than normal builds.

[XhmikosR]

Thanks for the patch... and the builds. :)

[Fr4nz]

x264 r1336 32/64 bit compiled with ICC 11.1: download (http://stashbox.org/697692/x264_1336_icc.rar); x264_icc_r1336.diff patch (http://stashbox.org/697652/x264_icc_r1336.diff)
"Qax" builds was compiled with /QaxSSE4.2 option but in reality they can be even slower than normal builds.

Thank you for your ICC builds MNB!

PS: Could you make an x264 build with these two patches?
* x264_win_zone_parse_fix_06.diff
* x264_hrd_pd_interlace.16_r1301.diff

You can get them here: http://forum.doom9.org/showpost.php?p=1342503&postcount=2589
Thanks!

[jpsdr]

Thanks MNB. Is it possible to have a link to the project ?
I personnaly want to try compiling with /Qx option, and not /Qax.

[MasterNobody]

Fr4nz
x264_win_zone_parse_fix_06.diff - not needed
x264_hrd_pd_interlace.16_r1301.diff - don't like it (it is still not stable enough)
So NO.

jpsdr
Link to the patch with all needed (except sources of x264 which you can get from x264 git) is in my previous post

[Fr4nz]

Fr4nz
x264_hrd_pd_interlace.16_r1301.diff - don't like it (it is still not stable enough)
So NO.


Well, actually Jeeb, Techouse and others have been using that patch without problems since many revisions ago...keep in mind, also, that hrd is needed for blu-ray compliancy.

If I'd were you I'd reconsider my NO... :)

[[ReX]]

x264_x64_r1336_unpatched (http://techouse.project357.com/builds/revision1336/x264.exe) | MD5 (http://techouse.project357.com/builds/revision1336/x264.md5)
GCC 4.4.2 20091019 (x86_64.core2.Komisar), unpatched, generic, fprofiled

________________________________________________________________________________

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

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

Patches used:

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

--version gives me (x86):
x264 0.77.1292M e381f6d
built by techouse on Oct 13 2009, gcc: 4.4.1 (x86.core2.Komisar)

[JEEB]

The nal-hrd patch "seems to work", but is still a hackwork as far as I've heard. I, too, would rather see a really working patch done, but currently it seems like not enough people are interested in it or really are in a desperate need of a nal-hrd patch.

Therefore I can understand MasterNobody's opinion as well.

Anyways, any new benchmarks between GCC'd and ICC'd builds, and also a question -- do I need MSVS to compile with ICC with this patch (as I'm seeing MSVS-project-like files)?

[kemuri-_9]

Anyways, any new benchmarks between GCC'd and ICC'd builds, and also a question -- do I need MSVS to compile with ICC with this patch (as I'm seeing MSVS-project-like files)?

this is for ICL not ICC (the difference being the former is for windows to replace MSVC's cl and the latter being for linux to replace gcc)
iirc, ICL can not even be installed without having MSVC installed first.

and i do think it's unfair for ICL to be supported and not ICC, seeing at how the latter is free for linux platforms (with some standard catches) while the former is only available as a limited trial.

Edit:
I do have to say i'm also heavily against readding bloated msvs sln/projs back to the repo which are only used for icl,
it would be more cleaner to add icc/icl to configure and then port configure to something natively windows supported, i.e. vbscript (a good portion of said porting i have done already)
and either use some windows port of make (msys's or gnuwin32's) or attempting to port the current GNU makefile to nmake (which will also be nontrivial).

[komisar]

Another small speed testing :)
Source: PlanetEarth_952x540_25fps.y4m 1000 frames with fades
"BM" -- MasterNobody ICC 11.1 builds
techouse build from here (http://forum.doom9.org/showthread.php?p=1343413#post1343413)
JEEB buld from here (http://forum.doom9.org/showthread.php?p=1343454#post1343454)

http://komisar.gin.by/test/speed.jpg

P.S. Can anybody make similar benchmark on AMD processor for comparison? Because results can differ there from my.

[[ReX]]

x264 r1336 32/64 bit compiled with ICC 11.1: download (http://stashbox.org/697692/x264_1336_icc.rar); x264_icc_r1336.diff patch (http://stashbox.org/697652/x264_icc_r1336.diff)
"Qax" builds was compiled with /QaxSSE4.2 option but in reality they can be even slower than normal builds.

I keep getting warnings and x264 is not compiled.

Which ICC command line did you use for libx264 and x264?
Maybe I'm missing some include, bin or whatever paths in MSVC? :confused:

[Boolsheet]

Another small speed testing :)
Hm, on my Core i7 920 MasterNobody's ICC builds are equal or slightly faster than the GCC builds from JEEB and techouse. Only did it over 64 bit executables:
x264_64_pf.exe : 28.22 fps
x264_64_pf_Qax.exe : 28.32 fps
x264.1336M.x64.JEEB : 27.30 fps
x264.1336M.x64.techouse: 28.04 fps
And it looks like the Qax optimization helps x264.

Options: -o NUL --preset slower --quiet --tune film matchpoint.y4m
Source was a downsized version (with FFmpeg's bicubic filter to 960x540) of the Match Point trailer (http://cid-bee3c9ac9541c85b.skydrive.live.com/browse.aspx/.Public/Match%20Point) which is "chock full of fades".

[popper]

The nal-hrd patch "seems to work", but is still a hackwork as far as I've heard. I, too, would rather see a really working patch done, but currently it seems like not enough people are interested in it or really are in a desperate need of a nal-hrd patch.

Therefore I can understand MasterNobody's opinion as well.

Anyways, any new benchmarks between GCC'd and ICC'd builds, and also a question -- do I need MSVS to compile with ICC with this patch (as I'm seeing MSVS-project-like files)?

i wonder why we dont see a current LLVM 2.6
http://llvm.org/releases/download.html#2.6 compile too, is that to slow in operation today compared to the other two.

and has any x264/ffmpeg Dev considering going to their IRC Channel: irc.oftc.net #llvm
and helping patch that for better x264/ffmpeg LLVM speed ?

[JEEB]

x264 r1339 64bit unpatched:
download (http://x264.fushizen.eu/files/revision1339/x264.exe) ; hash (http://x264.fushizen.eu/files/revision1339/x264.md5)

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

________________________________________________________________________________

x264 r1339 32bit
download (http://x264.fushizen.eu/files/1339/x264.exe) ; release notes

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


x264 r1339 64bit
download (http://x264.fushizen.eu/files/1339_x64/x264.exe) ; release notes

built on Nov 15 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_r1301.diff (http://www.mediafire.com/download.php?iyhjod2e2dn)


Lazy compiler's lazy builds continue. Bugfixes and the flv output doing a comeback.

[aegisofrime]

Does r1339 fix the freezing issue?

[tph]

Does r1339 fix the freezing issue?
http://git.videolan.org/?p=x264.git;a=commit;h=e76a4adb1c8ee27748847656450c815f60d2fe6d

[schweinsz]

I found that the x264 only has the slice-level thread parallel. How much is the efficiency loss on Rate-distortion performance when 4 slices are used for HD contents generally?

[aegisofrime]

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

Thank you very much. Too bad I already started my 8 hour encoding job with 2 hours done. Oh well :/

Also, I have been looking for that page for quite a while, much appreciated :D

[burfadel]

Has anyone tested the speed of the x264.exe over at xvidvideo.ru in comparison to the other builds available? it, along with mplayerc and ffdshow, are apparently always compiled with the latest daily build of GCC 4.5.0

[nm]

I found that the x264 only has the slice-level thread parallel.

Only ancient x264 versions had slice-based multithreading. When frame-based threading model was introduced, support for multiple slices was dropped completely. It was only reintroduced a while ago, without connection to the threading model.

How much is the efficiency loss on Rate-distortion performance when 4 slices are used for HD contents generally?

I think this was discussed when multi-slice support was added back to x264 a few months ago. Try searching.

[LoRd_MuldeR]

I found that the x264 only has the slice-level thread parallel.

Wrong. It uses Frame-parallel encoding for multi-threading. Slices are supported, but not used for parallel encoding.

Some info on efficiency loss cased by multiple slices:
threads.txt (http://git.videolan.org/gitweb.cgi?p=x264.git;a=blob;f=doc/threads.txt)

[techouse]

x264_x64_r1339_unpatched (http://techouse.project357.com/builds/revision1339/x264.exe) | MD5 (http://techouse.project357.com/builds/revision1339/x264.md5)
GCC 4.4.2 20091019 (x86_64.core2.Komisar), unpatched, generic, fprofiled

________________________________________________________________________________

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

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

Patches used:

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

[JEEB]

x264 r1342 64bit unpatched:
download (http://x264.fushizen.eu/files/revision1342/x264.exe) ; hash (http://x264.fushizen.eu/files/revision1342/x264.md5)

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

________________________________________________________________________________

x264 r1342 32bit
download (http://x264.fushizen.eu/files/1342/x264.exe) ; release notes

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


x264 r1342 64bit
download (http://x264.fushizen.eu/files/1342_x64/x264.exe) ; release notes

built on Nov 16 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_r1301.diff (http://www.mediafire.com/download.php?iyhjod2e2dn)


Lazy compiler's lazy builds continue. Weightp bugfixes.

[imk]

r1342M built with ICC.

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


I was away for about a month and a half so I didn't have any builds in between then.

x264 has been updated quite a bit since my last build (r1271). Because of all the changes between the two, I think that before using this build for anything serious, run some smaller tests on a sample with both a GCC build and my ICC build and compare the results. I'll run some tests of my own later on. I expect it to match up, but test yourself just to be sure.

[rack04]

x264_x86_r1342M (http://www.mediafire.com/?mylzybygl5z)

Built by rack04 on November 16, 2009, 9:26:16 AM CST
GCC 4.3.4 (x86.core2.Komisar)
--extra-cflags="-march=core2"
make fprofiled

Patched with:

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

[Atak_Snajpera]

Our x264 guru says that GCC 4.x.x sucks but people still use it. Why ???

[Inventive Software]

Because people don't know how to read or know any better?! :confused:

[Dark Shikari]

Our x264 guru says that GCC 4.x.x sucks but people still use it. Why ???Because people eventually learn to ignore my whining and use it because it's faster ;)

[shon3i]

Because people eventually learn to ignore my whining and use it because it's faster ;)

It is faster, over five million... :D

http://www.youtube.com/watch?v=7Ntr-pw_6C0


On mine Athlon Phenom Techouse bulds are bit faster. Can somebody compile ICC for AMD processors?

[juGGaKNot]

ACC you mean ? haha

[MasterNobody]

x264 r1342M 32/64 bit ICC builds by imk (patched for AMD processors with SSE2): download (http://stashbox.org/702304/x264_1342M_icc_%5Bimk%5D.zip)

My own x264 r1342M 32/64 bit ICC builds: download (http://stashbox.org/702303/x264_1342M_icc.zip)

[shon3i]

Thanks MasterNobody, but i can't download your build propertly, download hang after few seconds. Anyway can you patch it with hrd aslo, just for testing.

[skystrife]

Our x264 guru says that GCC 4.x.x sucks but people still use it. Why ???

Unless it has changed recently, mingw64 can only use gcc 4 and above, so that would be why you don't see gcc 3.x, x86_64 builds (for windows).

For x86, lolidunno.

[XhmikosR]

I did a comparison between various ICC builds compiled with different settings (and a GCC build just for reference).

CPU: Intel Q6600 @ 3Ghz
OS: Windows 7 Pro 32bit
Test video: 2000 frames Big Buck Bunny 720p Lagarith
4 two-pass encodes for each build with the following command line:

x264 --preset slow --tune animation -p 1 -B 2500 --stats "stats.stats" --threads auto --thread-input -o NUL "test.avs"

x264 --preset slow --tune animation -p 2 -B 2500 --stats "stats.stats" --threads auto --thread-input -o NUL "test.avs"


x264.x86.r1342M.ICC11-QxSSSE3 -Qx profiled
encoded 2000 frames, 19.29 fps, 2525.29 kb/s
encoded 2000 frames, 19.46 fps, 2525.29 kb/s
encoded 2000 frames, 19.32 fps, 2525.29 kb/s
encoded 2000 frames, 19.46 fps, 2525.29 kb/s
encoded 2000 frames, 14.63 fps, 2502.33 kb/s
encoded 2000 frames, 14.80 fps, 2502.33 kb/s
encoded 2000 frames, 14.59 fps, 2502.33 kb/s
encoded 2000 frames, 14.82 fps, 2502.33 kb/s
average: 19.38/14.71

x264.x86.r1342M.ICC11-QaxSSSE3 -O3 profiled
encoded 2000 frames, 17.33 fps, 2525.29 kb/s
encoded 2000 frames, 17.80 fps, 2525.29 kb/s
encoded 2000 frames, 17.73 fps, 2525.29 kb/s
encoded 2000 frames, 17.77 fps, 2525.29 kb/s
encoded 2000 frames, 14.19 fps, 2502.33 kb/s
encoded 2000 frames, 14.38 fps, 2502.33 kb/s
encoded 2000 frames, 14.23 fps, 2502.33 kb/s
encoded 2000 frames, 14.37 fps, 2502.33 kb/s
average: 17.66/14.30

x264.x86.r1342M.ICC11-imk -O3 /QxSSE2 profiled
encoded 2000 frames, 19.31 fps, 2525.29 kb/s
encoded 2000 frames, 19.48 fps, 2525.29 kb/s
encoded 2000 frames, 19.39 fps, 2525.29 kb/s
encoded 2000 frames, 19.47 fps, 2525.29 kb/s
encoded 2000 frames, 14.56 fps, 2502.33 kb/s
encoded 2000 frames, 14.78 fps, 2502.33 kb/s
encoded 2000 frames, 14.54 fps, 2502.33 kb/s
encoded 2000 frames, 14.79 fps, 2502.33 kb/s
average: 19.41/14.67

x264.x86.r1342M.ICC11-MasterNobody
encoded 2000 frames, 17.54 fps, 2525.29 kb/s
encoded 2000 frames, 17.59 fps, 2525.29 kb/s
encoded 2000 frames, 17.56 fps, 2525.29 kb/s
encoded 2000 frames, 17.65 fps, 2525.29 kb/s
encoded 2000 frames, 14.14 fps, 2502.33 kb/s
encoded 2000 frames, 14.41 fps, 2502.33 kb/s
encoded 2000 frames, 14.18 fps, 2502.33 kb/s
encoded 2000 frames, 14.41 fps, 2502.33 kb/s
average: 17.59/14.29

x264.x86.r1342M.gcc.core2.mssse3 fprofiled
encoded 2000 frames, 17.86 fps, 2525.29 kb/s
encoded 2000 frames, 17.94 fps, 2525.29 kb/s
encoded 2000 frames, 17.95 fps, 2525.29 kb/s
encoded 2000 frames, 17.77 fps, 2525.29 kb/s
encoded 2000 frames, 14.08 fps, 2502.33 kb/s
encoded 2000 frames, 14.36 fps, 2502.33 kb/s
encoded 2000 frames, 14.48 fps, 2502.33 kb/s
encoded 2000 frames, 14.41 fps, 2502.33 kb/s
average: 17.88/14.33

So it seems the only real benefit in speed is when the Qx switch is used, although QxSSE2 and QxSSSE3 are almost the same, at least for my CPU. The disadvantage is that Qx builds won't run on AMD CPUs.
All the builds I used are (http://www.mediafire.com/?sharekey=3f33c77c2cf9ce25ab1eab3e9fa335cab0357954fbd64bc8) here. Can someone with a Core i7 make some tests?

[Trahald]

***snip*** is Alex' current hrd patch if someone wants to give it a try (someone that has access to applications to test the outputs validity.) Streams are accepted by scenarist (although i didnt try a mux)

[shon3i]

Yes i want to try, somebody compile it please :), If this passes can we expect soon to be merged into git?

[JEEB]

Have a build: clicky (http://x264.fushizen.eu/files/x264-20091119-nalhrd.exe)

I wonder why I'm still awake :3

Edit:

It's built with the win zone parsing fix and the nal-hrd patch linked by Trahald just now.
32bit, fprofiled, i686.

[Trahald]

Thanks. I just realized that the mail was private (gmail sorted in the same 'thread' as the mailing list posts), although im sure alex probably wouldnt mind (considering the patch is destined for open source) I removed the link from the other post. (until alex publiclly posts the patch) Anyone interested in testing use JEEBs build.

[Dark Shikari]

Thanks. I just realized that the mail was private (gmail sorted in the same 'thread' as the mailing list posts), although im sure alex probably wouldnt mind (considering the patch is destined for open source) I removed the link from the other post. (until alex publiclly posts the patch) Anyone interested in testing use JEEBs build.He's already posted the patch publicly AFAIK, and he wants it to be public, and the GPL requires it to be public, and... :p

[shon3i]

Ok i do a quick test, and use following cmd

--preset slow --tune film --bitrate 8306 --pass 2 --stats "" --keyint 24 --min-keyint 2 --slices 4 --vbv-maxrate 30000 --vbv-bufsize 30000 --sar 1:1 --level 4.1 --threads 12 --aud --nal-hrd --output fnf2.264 fnf2.avs

Stream is fine, it's passed by Elecard and MUIGenerator, but there is a huge problem, after loading in Elecard stream shows this

Stream info:
file name : I:\fnf2.264
file size : 43 276 602 bytes

video format : AVC/H.264
initial CBP removal relay : 0.76 sec
buffer size : 35 326 976 bits
declared bitrate : 35 326 976 bps
declared frame rate : 23.98 fps
bitrate type : VBR
padding : 0 bits


but i put in my commandline --vbv-maxrate 30000 --vbv-bufsize 30000, so that is not good at all. And Scenarist aslo refuse to import stream with following error Error "Content : Value of Cpb_size is not supported in the BD standard.", which is normal, because buffsize is over 30000, looks like hrd not follow VBV model.

[Underground78]

(until alex publiclly posts the patch)

http://mailman.videolan.org/pipermail/x264-devel/2009-November/006551.html

[jpsdr]

So it seems the only real benefit in speed is when the Qx switch is used, although QxSSE2 and QxSSSE3 are almost the same, at least for my CPU. The disadvantage is that Qx builds won't run on AMD CPUs.
Can someone with a Core i7 make some tests?

Hello.
I'm having an i7, but i would like to test the 2 followings :
- Qx SSE4.2 + O3
- Qx SSE4.2 + O2
If you can provide me these, i can make some tests.

Edit : In fact, if for both so, or if to long, doing only the following :
/O3 /QxSSE4.2 /Qopenmp /Qparallel (or -O3 -xSSE4.2 -openmp -parallel)
and, if possible, also :
/O2 /QxSSE4.2 /Qopenmp /Qparallel (or -O2 -xSSE4.2 -openmp -parallel)

[XhmikosR]

Hello.
I'm having an i7, but i would like to test the 2 followings :
- Qx SSE4.2 + O3
- Qx SSE4.2 + O2
If you can provide me these, i can make some tests.

Edit : In fact, if for both so, or if to long, doing only the following :
/O3 /QxSSE4.2 /Qopenmp /Qparallel (or -O3 -xSSE4.2 -openmp -parallel)
and, if possible, also :
/O2 /QxSSE4.2 /Qopenmp /Qparallel (or -O2 -xSSE4.2 -openmp -parallel)

I cannot fprofile with these CPU instructions since I don't have a CPU which supports them. So I only built a build with -Qx /QxSSE4.2 /Qopenmp /Qparallel but not profiled.

http://www.mediafire.com/?sharekey=3f33c77c2cf9ce25ab1eab3e9fa335cab0357954fbd64bc8

[shon3i]

@techouse. again you are too fast, and not read comments about hrd :) patch is still somehow broken :) http://forum.doom9.org/showthread.php?p=1345340#post1345340

[Trahald]

@techouse
yeah.. I only linked the patch so that a testing build could be made. I would say continue to use the old patch for now.

[moviefan]

I'm just wondering: what is the problem with the old hrd-patch?

[Trahald]

The output is likely fine. Its just that the code needs alot of cleanup. The new patch is fairly clean codewise, it just hasn't been publicly exposed as long so needs some bug killing.

[jpsdr]

I cannot fprofile with these CPU instructions since I don't have a CPU which supports them. So I only built a build with -Qx /QxSSE4.2 /Qopenmp /Qparallel but not profiled.


Ok, i'll make some test this evening, and report my result.
I'll probably doing test with 1000 frame 1080p lagarith
video, comparing SSE4.2 with standard nl build.
Wich optimisation have you used ? O2... O3...?

[shon3i]

The output is likely fine. Its just that the code needs alot of cleanup. The new patch is fairly clean codewise, it just hasn't been publicly exposed as long so needs some bug killing.
Isn't there a some limitation? when interlaced/pulldown is used or something, it think i found some comments by you or some other member, which point on that limitation? or i something overlooked.

[XhmikosR]

Ok, i'll make some test this evening, and report my result.
I'll probably doing test with 1000 frame 1080p lagarith
video, comparing SSE4.2 with standard nl build.
Wich optimisation have you used ? O2... O3...?

I used Qx (Full optimization). I don't know the real difference between this and -O3. So I added a build with -O3 too. The link is the same.

[jpsdr]

You can find things here :
http://software.intel.com/sites/products/documentation/hpc/compilerpro/en-us/cpp/win/compiler_c/index.htm
In Optimizing application -> using compiler optimization

[XhmikosR]

I know that, I was blind it appears. I was using /Ox.

[jpsdr]

I've made tests on my i7, and results are... very odd !!

Video test : a 2000 frames 1920x1080 anime video encoded in Lagarith YV12.
Command line the same than in post #2634, except bitrate set to 15000.

SSE4.2 + O3 :
1st pass : 4.99fps, 2nd pass : 5,73fps.
SSE4.2 :
1st pass : 4.62fps, 2nd pass : 5,72fps.
On these 2 tests, both 1st and 2nd pass were multithreaded : All my 8 CPU were almost at 100%.

SSSE3 :
1st pass : 8,78fps, 2nd pass : 6,58fps.
Standard nl built :
1st pass : 8,97fps, 2nd pass : 6,52fps.
On these 2 tests, 1st pass was having only 1 CPU a 100%, 2nd pass all CPU at almost 100%.

These results realy surprise me !!

[Vitaliy Gorbatenko]

I for some reason I can not use the settings above "fast". result - broken video output (anime). I can lay out a small spot on FTP. In RAW. x264 build 1342 (i'm try all generic, core2, patched and not) Help please!
x264.exe --profile high --preset slow --pass 1 --bitrate 1000 --stats "H:\Encoding\03Last.stats" --slow-firstpass --thread-input --output NUL "H:\Encoding\03Last.avs"
x264.exe --profile high --preset slow --pass 2 --bitrate 1000 --stats "H:\Encoding\03Last.stats" --thread-input --output "H:\Encoding\03Last.mkv" "H:\Encoding\03Last.avs"

avis [info]: 1024x768 @ 23.98 fps (501 frames)
x264 [warning]: NAL HRD parameters require VBV max bitrate and buffer size to be specified
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.1 Cache64
x264 [info]: profile High, level 3.1
x264 [info]: frame I:3 Avg QP:16.52 size: 18108
x264 [info]: frame P:177 Avg QP:20.25 size: 9125
x264 [info]: frame B:321 Avg QP:22.73 size: 3026
x264 [info]: consecutive B-frames: 7.8% 9.2% 28.3% 54.6%
x264 [info]: mb I I16..4: 15.1% 70.5% 14.5%
x264 [info]: mb P I16..4: 7.7% 5.7% 1.1% P16..4: 32.3% 8.3% 5.3% 0.0% 0.0% skip:39.6%
x264 [info]: mb B I16..4: 0.5% 0.5% 0.2% B16..8: 35.8% 0.5% 0.8% direct: 2.1% skip:59.6% L0:39.9% L1:56.5% BI: 3.6%
x264 [info]: final ratefactor: 19.66
x264 [info]: 8x8 transform intra:42.5% inter:82.0%
x264 [info]: direct mvs spatial:98.8% temporal:1.2%
x264 [info]: coded y,uvDC,uvAC intra: 30.4% 25.6% 5.5% inter: 9.6% 8.8% 0.1%
x264 [info]: i16 v,h,dc,p: 73% 13% 5% 9%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 19% 9% 25% 7% 8% 10% 6% 9% 6%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 24% 13% 17% 7% 9% 10% 7% 7% 6%
x264 [info]: Weighted P-Frames: Y:25.4%
x264 [info]: ref P L0: 60.3% 8.2% 15.2% 4.0% 9.8% 2.4% 0.1%
x264 [info]: ref B L0: 90.2% 5.9% 2.5% 1.4%
x264 [info]: kb/s:1010.95

encoded 501 frames, 15.76 fps, 1010.95 kb/s
avis [info]: 1024x768 @ 23.98 fps (501 frames)
x264 [warning]: NAL HRD parameters require VBV max bitrate and buffer size to be specified
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.1 Cache64
x264 [info]: profile High, level 3.1
x264 [info]: frame I:3 Avg QP:16.73 size: 15952
x264 [info]: frame P:177 Avg QP:19.98 size: 9232
x264 [info]: frame B:321 Avg QP:22.25 size: 2894
x264 [info]: consecutive B-frames: 7.8% 9.2% 28.3% 54.6%
x264 [info]: mb I I16..4: 51.4% 37.3% 11.3%
x264 [info]: mb P I16..4: 7.6% 5.8% 0.9% P16..4: 33.5% 9.3% 5.6% 0.0% 0.0% skip:37.4%
x264 [info]: mb B I16..4: 0.6% 0.4% 0.1% B16..8: 36.1% 0.5% 0.9% direct: 2.3% skip:59.1% L0:42.0% L1:53.4% BI: 4.5%
x264 [info]: 8x8 transform intra:39.5% inter:81.6%
x264 [info]: direct mvs spatial:93.1% temporal:6.9%
x264 [info]: coded y,uvDC,uvAC intra: 27.7% 28.3% 7.3% inter: 10.4% 9.8% 0.1%
x264 [info]: i16 v,h,dc,p: 74% 13% 5% 9%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 21% 7% 17% 8% 9% 12% 7% 10% 7%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 27% 11% 15% 7% 10% 11% 6% 7% 5%
x264 [info]: Weighted P-Frames: Y:25.4%
x264 [info]: ref P L0: 58.0% 10.3% 20.6% 3.4% 6.1% 1.5% 0.1%
x264 [info]: ref B L0: 89.2% 7.2% 2.6% 1.0%
x264 [info]: kb/s:999.53

encoded 501 frames, 18.18 fps, 999.53 kb/s

[Dark Shikari]

Without a sample, input or output, bug reports aren't very useful...

[Vitaliy Gorbatenko]

Send in PM.

[Vitaliy Gorbatenko]

Sorry! It's CoreAVC 1.9.5 decoder bug! ffdshow play it fine!
http://forum.corecodec.com/viewtopic.php?f=3&t=3123

[Trahald]

Ok i do a quick test, and use following cmd



Stream is fine, it's passed by Elecard and MUIGenerator, but there is a huge problem, after loading in Elecard stream shows this



but i put in my commandline --vbv-maxrate 30000 --vbv-bufsize 30000, so that is not good at all. And Scenarist aslo refuse to import stream with following error Error "Content : Value of Cpb_size is not supported in the BD standard.", which is normal, because buffsize is over 30000, looks like hrd not follow VBV model.

@shon3i

...the current patch multiplies the buffer size by a 'panic factor', and he needs to set the size and the rate manually (--vui-hrd-bit-rate and--vui-hrd-cpb-size). I'll fix that (leaving the panic to the user) the factor is 1.15
...caught a couple of stupid things, will issue a fix probably tonight (from IRC)

[techouse]

Damn it :D I'll build another build with the old patch...

[Trahald]

Damn it :D I'll build another build with the old patch...

:D .. feel free to (actually please do) make an extra build from alex' patch when he releases it later. Real world testing is invaluable. It will undergo code scrutiny before commit but real world testing will bring up things that wont find. Once output is deemed to be equal to or better than the current patch the switch of unofficial patches can occur. (Assuming it hadn't been committed yet)

Thank you.

[shon3i]

@Trahald, thanks for info :)

btw i tryed to set --vui-hrd-bit-rate and --vui-hrd-cpb-size to 30000 but x264 refuse commandline with invalid argument? while other new params vui-hrd-cbr work just fine.

[kemuri-_9]

@Trahald, thanks for info :)

btw i tryed to set --vui-hrd-bit-rate and --vui-hrd-cpb-size to 30000 but x264 refuse commandline with invalid argument? while other new params vui-hrd-cbr work just fine.

seems to be an inconsistency in the patch:
vui-hrd-bit-rate and vui-hrd-cpb-size are added to libx264
while
vui-hrd-bit-rate-value and vui-hrd-cpb-size-value were added to x264cli

this causes the parameters to be unusable in x264cli

applying

diff --git a/encoder/encoder.c b/encoder/encoder.c
index feb8ff6..d1e707a 100644
--- a/encoder/encoder.c
+++ b/encoder/encoder.c
@@ -773,7 +773,7 @@ static int x264_validate_parameters( x264_t *h )

h->param.b_sei_pic_timing += h->param.i_pulldown;

- if( h->param.rc.i_vbv_max_bitrate == 0 || h->param.rc.i_vbv_buffer_size == 0 )
+ if( h->param.vui.b_nal_hrd_parameters_present && (!h->param.rc.i_vbv_max_bitrate || !h->param.rc.i_vbv_buffer_size) )
{
x264_log( h, X264_LOG_WARNING, "NAL HRD parameters require VBV max bitrate and buffer size to be specified\n" );
h->param.vui.b_nal_hrd_parameters_present = 0;
diff --git a/x264.c b/x264.c
index 4263890..cc1ddc7 100644
--- a/x264.c
+++ b/x264.c
@@ -541,7 +541,7 @@ static struct option long_options[] =
{ "sei-pic-timing", no_argument, NULL, 0 },
{ "vui-timing-info-present", required_argument, NULL, 0 },
{ "vui-nal-hrd-parameters-present", required_argument, NULL, 0 },
- { "vui-hrd-bit-rate-value", required_argument, NULL, 0 },
- { "vui-hrd-cpb-size-value", required_argument, NULL, 0 },
+ { "vui-hrd-bit-rate", required_argument, NULL, 0 },
+ { "vui-hrd-cpb-size", required_argument, NULL, 0 },
{ "vui-hrd-cbr", required_argument, NULL, 0 },
{ "vui-hrd-initial-cpb-removal-delay", required_argument, NULL, 0 },

on top of the patch should fix this issue.

Edit:
updated patch to fix the constant nal-hrd warning well.

[shon3i]

Thanks kemuri-_9 :) i hope will be fixed asap. Btw can somebody recompile or wait for new patch. I realy want to do a deeper test.

[Trahald]

http://pastebin.com/d72a44cf2 is the newest patch from alex.. does not include kemuri-_9's code.

[VFR maniac]

x264_x86_r1342_with_Alex's_nal-hrd (http://www.mediafire.com/?ddrthklzzdz)

gcc: 4.4.2-dw2
-march=core2
patch: http://pastebin.com/d72a44cf2

Edit: Alex removed prefix "vui-" from param names.
vui-timing-info-present -> timing-info-present
vui-nal-hrd-parameters-present -> nal-hrd-parameters-present
and so on.

[techouse]

x264_x64_r1342_unpatched (http://techouse.project357.com/builds/revision1342/x264.exe) | MD5 (http://techouse.project357.com/builds/revision1342/x264.md5)
GCC 4.4.2 20091019 (x86_64.core2.Komisar), unpatched, generic, fprofiled

________________________________________________________________________________

x264_x86_r1342_NAL-HRD-ALEX_techouse (http://techouse.project357.com/builds/x264_x86_r1342_NAL-HRD-ALEX_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x86_r1342_NAL-HRD-ALEX_techouse.txt)
GCC 4.4.2 20091019 (x86.core2.Komisar), fprofiled, -march=core2

x264_x64_r1342_NAL-HRD-ALEX_techouse (http://techouse.project357.com/builds/x264_x64_r1342_NAL-HRD-ALEX_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x64_r1342_NAL-HRD-ALEX_techouse.txt)
GCC 4.4.2 20091019 (x86_64.core2.Komisar), fprofiled, -march=core2

Patches used:

x264_win_zone_parse_fix_06.diff (http://kemuri9.net/dev/x264/patches/x264_win_zone_parse_fix_06.diff)
x264-r1342-nal_hrd-pic_struct-v10a.patch (http://pastebin.com/d72a44cf2)

________________________________________________________________________________

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

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

Patches used:

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

[Selur]

little side question: will vui-hrd-bit-rate-value and vui-hrd-cpb-size-value be used instead of vbv-maxrate and vbv-bufsize when using --nal-hrd or need both (the vbv and the vui-hrd values) to be specified ?

[Dark Shikari]

little side question: will vui-hrd-bit-rate-value and vui-hrd-cpb-size-value be used instead of vbv-maxrate and vbv-bufsize when using --nal-hrd or need both (the vbv and the vui-hrd values) to be specified ?No, because I won't commit any patch that makes such a distinction.

[Brazil2]

x264_x86_r1342_NAL-HRD-ALEX_techouse (http://techouse.project357.com/builds/x264_x86_r1342_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x86_r1342_NAL-HRD-ALEX_techouse.txt)
GCC 4.4.2 20091019 (x86.core2.Komisar), fprofiled, -march=core2


x264_x86_r1342_NAL-HRD-16-1301_techouse (http://techouse.project357.com/builds/x264_x86_r1342_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x86_r1342_NAL-HRD-16-1301_techouse.txt)
GCC 4.4.2 20091019 (x86.core2.Komisar), fprofiled, -march=core2
404 Not Found for both.
Only the unpatched version is available.

[Fr4nz]

404 Not Found for both.
Only the unpatched version is available.

Go here: http://techouse.project357.com/

[Trahald]

@Selur
the intent of the parameter is only when you want to have HRD say syntactically something different from the real VBV settings
so, it shouldn't ever be used w/o a very good reason ;-)

[Selur]

missed that, thanks

[jpsdr]

End of the test of version compiled with Intel compiler. Exactly the same video/settings/etc than in post #2653.
SSE4.2 profiled version :
1rt pass : 9.51fps, 2nd pass : 6.73fps.

[Brazil2]

Go here: http://techouse.project357.com/
Thanks :)

[XhmikosR]

End of the test of version compiled with Intel compiler. Exactly the same video/settings/etc than in post #2653.
SSE4.2 profiled version :
1rt pass : 9.51fps, 2nd pass : 6.73fps.

So there is a gain over the x264.nl build and over my QxSSSE3 build.
Your results put all together:

CPU: Intel Core i7
Video test : a 2000 frames 1920x1080 anime video encoded in Lagarith YV12.
x264 --preset slow --tune animation -p 2 -B 15000 --stats "stats.stats" --threads auto --thread-input -o NUL "test.avs"

/Ox /QxSSE4.2 profiled :
1st pass : 9.51fps, 2nd pass : 6.73fps.
/Ox /QxSSSE3 profiled :
1st pass : 8,78fps, 2nd pass : 6,58fps.
x264.nl built profiled:
1st pass : 8,97fps, 2nd pass : 6,52fps.

[shon3i]

Ok, sorry for wait, i been bussy these days. I do test with VRF Maniac buld. First i use classical command line posted here (http://forum.doom9.org/showthread.php?p=1345340#post1345340) and i get exatly same values for VBV. Then i add HRD VBV values

--keyint 24 --min-keyint 2 --slices 4 --vbv-maxrate 30000 --vbv-bufsize 30000 --sar 1:1 --level 4.1 --threads 12 --aud --nal-hrd --hrd-bit-rate 30000 --hrd-cpb-size 30000

And i get

Stream info:
file name : I:\fnf2.264
file size : 25 177 156 bytes

video format : AVC/H.264
initial CBP removal relay : 0.88 sec
buffer size : 30 720 000 bits
declared bitrate : 30 720 000 bps
declared frame rate : 23.98 fps
bitrate type : VBR
padding : 0 bits

Which isn't good at all, out of specs.. :(, i hope new patch comming ASAP.

[kemuri-_9]

sounds like it's using a multiply by 1024 where it should be using a multiply by 1000

[VFR maniac]

x264_x86_r1342_with_Alex's_nal-hrd_v11 (http://www.mediafire.com/?1dywd5lmjqn)

gcc: 4.4.2-dw2
-march=core2
patch: http://mailman.videolan.org/pipermail/x264-devel/2009-November/006563.html

[Boolsheet]

Can someone with a Core i7 make some tests?
Here's what I got:
CPU: Intel Core i7 920 @ 3045 Mhz
OS: Windows Vista 64bit
Test video: first 2000 frames Big Buck Bunny 720p raw y4m
4 two-pass encodes for each build with the following command line:

--preset slow --tune animation -p 1 -B 2500 --quiet --no-progress --stats "stats.stats" -o NUL bbb.y4m
--preset slow --tune animation -p 2 -B 2500 --quiet --no-progress --stats "stats.stats" -o NUL bbb.y4m

Pass 1 Pass 2
ICC11-QxSSE4.2: 22.10 / 23.52
ICC11-QxSSSE3: 20.56 / 22.83
ICC11-imk: 20.53 / 22.78
ICC11-QaxSSSE3: 20.50 / 22.74
ICC11-MasterNobody: 20.48 / 22.71
gcc.core2.mssse3: 20.57 / 22.52

All runs (http://pastebin.com/f68fba3d0)

Hyperthreading is on. I thought this would have a bigger impact on the first pass performance.
ICC11-QxSSE4.2 without HT:
x264.x86.r1342M.ICC11-QxSSE4.2.exe
Pass 1
22.18 fps, 2470.67 kb/s
22.19 fps, 2470.67 kb/s
22.18 fps, 2470.67 kb/s
22.19 fps, 2470.67 kb/s
Pass 2
18.14 fps, 2496.70 kb/s
18.21 fps, 2496.70 kb/s
18.16 fps, 2496.70 kb/s
18.19 fps, 2496.70 kb/s

[jpsdr]

sounds like it's using a multiply by 1024 where it should be using a multiply by 1000

Most of people forget or don't know, that in the international standard unit system, ONLY kiloBYTE is 1024 bytes, NOTHING else.
Megabyte or gigabyte are 10e6 and 10e9 bytes, in reference to the international standard system unit.
In windows (don't know about linux/unix), size are 1024² and 1024^3, but it's not standard.

[techouse]

404 Not Found for both.
Only the unpatched version is available.
Sorry for those broken links. I forgot to update them....

[techouse]

Another test build :D

x264_x86_r1342_NAL-HRD-ALEX-11_techouse (http://techouse.project357.com/builds/x264_x86_r1342_NAL-HRD-ALEX-11_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x86_r1342_NAL-HRD-ALEX-11_techouse.txt)
GCC 4.4.2 20091019 (x86.core2.Komisar), fprofiled, -march=core2

x264_x64_r1342_NAL-HRD-ALEX-11_techouse (http://techouse.project357.com/builds/x264_x64_r1342_NAL-HRD-ALEX-11_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x64_r1342_NAL-HRD-ALEX-11_techouse.txt)
GCC 4.4.2 20091019 (x86_64.core2.Komisar), fprofiled, -march=core2

Patches used:

x264_win_zone_parse_fix_06.diff (http://kemuri9.net/dev/x264/patches/x264_win_zone_parse_fix_06.diff)
x264-r1342-nal_hrd-pic_struct-v11.patch (http://mailman.videolan.org/pipermail/x264-devel/2009-November/006563.html)

[wyti]

Most of people forget or don't know, that in the international standard unit system, ONLY kiloBYTE is 1024 bytes, NOTHING else.
Megabyte or gigabyte are 10e6 and 10e9 bytes, in reference to the international standard system unit.
In windows (don't know about linux/unix), size are 1024² and 1024^3, but it's not standard.
Wrong KiloByte (kB), MegaByte(Mb), GigaByte,... always mean 1000^1,2,3 and there is an another unit, that some linux (debian based IIRC) use, it's the kibibyte (kiB), Mébibyte (MiB), gibibyte (GiB) and always mean 2^10,20,30...

[jpsdr]

Wrong KiloByte (kB), MegaByte(Mb), GigaByte,... always mean 1000^1,2,3 and there is an another unit, that some linux (debian based IIRC) use, it's the kibibyte (kiB), Mébibyte (MiB), gibibyte (GiB) and always mean 2^10,20,30...
I didn't know kibi, mébi, etc...
Wrong for kilo-byte and only kilo-byte. I don't know if it's has been changed since. I know that around the 80's, in the standard unit system, the kilo-byte have been specialy introduced to do 1024 bytes (it's when i was around 15, in around 84, that i've learned that). But only the kilo-byte, neither the kilo-bit or any mega-giga byte. Now, i've searched a little and it seems that in 1998, there has been some changed in the standard unit system. So, it's not impossible that the kilo-byte has gone back from 1024 bytes to 1000 bytes, but i've not been able to find out. But one thing is sure, it has been a period in the standard unit system where 1kB=1024 bytes. In this period, the concept on mega-byte was total science-fiction. But when capacity increased, this has lead to a false extend of the kB to the others (MB, GB...).
So kB (and only it) has not always mean 1000 bytes.

[MatLz]

Interesting...
I'm really not an expert and have bad english but I think you two are wright. Aren't there 'rough size' and 'actual size' cause computer numbers have to be 2 to the power of x ?
I don't remember where I have read that.
Don't ask me more!

[LoRd_MuldeR]

Well, if we are talking about storage media with binary addressing (may that be a hard drive, a memory chip or whatever), then we use the SI-Prefixes the following way:
1 Kilobyte (kB) = 1024 Byte, 1 Megabyte (MB) = 1024 Kilobyte = 1024 · 1024 Byte = 1.048.576 Byte.

That is common practice. Convention. (Almost) everybody will understands it that way. If you claim anything else, then you ignore how the SI-Prefixes are used in the real (IT) world ;)

However it is not correct in the original meaning of the SI-Prefixes, yes!

Therefore attempts have been made to establish new "binary" prefixes. Also it was proposed to use the old SI-Prefixes only in the (originally intended) decimal way:
1 Kilobyte (kB) = 2^10 Byte = 1000 Byte, 1 Kibibyte (kiB) = 2^10 = 1024 Byte.

Only that nobody uses those "correct" prefixes. It's kind of useless to argue that people should use "kiB" instead of "kB" when they mean 1024 Byte, because we all know what is meant :D

However one oddity is, that if we talk about "Bits" in the context of data transmission, 1 kB/s commonly refers to 1000 Bits/s.

[buzzqw]

HD manufacturer use the "right" meaning..

BHH

P.S. sorry for the OT

[roozhou]

I think only HDD manufacturers use 1GB = 1,000,000,000 Bytes. A 2GB RAM module has 2^30 Bytes not 2,000,000,000 Bytes.

[LoRd_MuldeR]

I think only HDD manufacturers use 1GB = 1,000,000,000 Bytes.

Yes, but only because they can make more money that way :p

If you sell a "1 TB" hard disk, everybody would expect 1099511627776 Bytes. But what you actually get are 1000000000000 Bytes. That's only 0.9 TB in the commonly used meaning!

Of course "1 TB" sounds better then "0.9 TB", especially if your competitors also use the "1GB = 1,000,000,000 Bytes" meaning ;)

[JEEB]

x264 r1347 64bit unpatched:
download (http://x264.fushizen.eu/files/revision1347/x264.exe) ; hash (http://x264.fushizen.eu/files/revision1347/x264.md5)

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

________________________________________________________________________________

x264 r1347 32bit
download (http://x264.fushizen.eu/files/1347/x264.exe)

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


x264 r1347 64bit
download (http://x264.fushizen.eu/files/1347_x64/x264.exe)

built on Nov 23 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_zmgorynych_20091123_irc.diff (http://pastebin.com/m39b12a8e) (should have the 1024/1000 stuff fixed)


git log: clicky (http://x264.fushizen.eu/files/git_log.txt)

Bugfixes, faster subme1, cosmetics etc.

EDIT: Hurr wrong revision number, thanks for the reminder D_S.

[shon3i]

Wow this is perfect :D finaly work as should :)

Stream info:
file name : I:\fnf2.264
file size : 25 177 204 bytes

video format : AVC/H.264
initial CBP removal relay : 0.90 sec
buffer size : 30 000 000 bits
declared bitrate : 30 000 000 bps
declared frame rate : 23.98 fps
bitrate type : VBR
padding : 0 bits

I use VFRManiac buld :) and this comandline:

--preset slow --tune film --bitrate 8306 --pass 2 --stats "" --keyint 24 --min-keyint 2 --slices 4 --vbv-maxrate 30000 --vbv-bufsize 30000 --sar 1:1 --level 4.1 --threads 12 --aud --nal-hrd --output fnf2.264 fnf2.avs

Scenarist muxed stream without errors.

So that mean GIT, GIT, GIT, GIT

EDIT: JEEB did you buld contain newer patch than VRFManiac and Techouse or it's same?

[JEEB]

EDIT: JEEB did you buld contain newer patch than VRFManiac and Techouse or it's same?

It's a patch from the author grabbed from the development channel around 12.5 hours ago. Therefore I guess it's the currently newest official revision of the patch.

So that mean GIT, GIT, GIT, GIT

More like, official devs starting to check the code now that it seems to be rewritten at least once 8)

[jpsdr]

HD manufacturer use the "right" meaning..

BHH

P.S. sorry for the OT

Media (HDD/CD/DVD/BR) use in fact the rigth value in the internationnal standard unit system, reason are (in my opinion)
- You can in fact beleive having more, because people have been used to think in 1024.
- They are strictly conform with the SI, so you can't sue them for providing false information beacause you're are (falsely) used to 1024 power steps.
1 single layer DVD is 4,7GB (but it's 4,37 in 1024 power), but according to SI, the information is absolutely correct.
.... In fact i think it's time i'll stop the off topic...

[VFR maniac]

EDIT: JEEB did you buld contain newer patch than VRFManiac and Techouse or it's same?

I checked whether there are any differences.
Result: x264_hrd_pd_interlace_zmgorynych_20091123_irc.diff == x264-r1342-nal_hrd-pic_struct-v11.patch

[JEEB]

I checked whether there are any differences.
Result: x264_hrd_pd_interlace_zmgorynych_20091123_irc.diff == x264-r1342-nal_hrd-pic_struct-v11.patch

Oh lol. I just grabbed it as it looked to be the newest. Which it still is. :3


<Zm_Gorynych> new HRD patch version: http://pastebin.com/m39b12a8e
<Zm_Gorynych> wewk:
<Zm_Gorynych> fixed the 1024/1000 shafu kemuri-_9 found
<Zm_Gorynych> snafu

[laserfan]

I checked whether there are any differences.
Result: x264_hrd_pd_interlace_zmgorynych_20091123_irc.diff == x264-r1342-nal_hrd-pic_struct-v11.patchThanks for this!

[techouse]

x264_x64_r1347_unpatched (http://techouse.project357.com/builds/revision1347/x264.exe) | MD5 (http://techouse.project357.com/builds/revision1347/x264.md5)
GCC 4.4.2 20091019 (x86_64.core2.Komisar), unpatched, generic, fprofiled

________________________________________________________________________________

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

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

Patches used:

x264_win_zone_parse_fix_06.diff (http://kemuri9.net/dev/x264/patches/x264_win_zone_parse_fix_06.diff)
x264-r1342-nal_hrd-pic_struct-v11.patch (http://mailman.videolan.org/pipermail/x264-devel/2009-November/006563.html)

[VFR maniac]

Hm, x264-r1342-nal_hrd-pic_struct-v11.patch (http://mailman.videolan.org/pipermail/x264-devel/2009-November/006563.html) lacks --bff of long_options[].

[kemuri-_9]

Hm, x264-r1342-nal_hrd-pic_struct-v11.patch (http://mailman.videolan.org/pipermail/x264-devel/2009-November/006563.html) lacks --bff of long_options[].

there will be a new version of the patch later to fix some issues (that one among others).

[Boulder]

How to build x264 using the Intel C++ Compiler? No one posted the method here so I'm asking for some instructions.. I tried setting things up the way that is described in imk's build package, but my efforts fail because of the "Not a git repository.." error after entering the "make A=x86" command

This is what version.sh contains (it seems that the process bombs there):
#!/bin/bash
git rev-list HEAD | sort > config.git-hash
LOCALVER=`wc -l config.git-hash | awk '{print $1}'`
if [ $LOCALVER \> 1 ] ; then
VER=`git rev-list origin/master | sort | join config.git-hash - | wc -l | awk '{print $1}'`
if [ $VER != $LOCALVER ] ; then
VER="$VER+$(($LOCALVER-$VER))"
elif git status | grep -q "modified:" ; then
VER="${VER}M"
fi
VER="$VER $(git rev-list HEAD -n 1 | head -c 7)"
echo "#define X264_VERSION \" r$VER\"" >> config.h
else
echo "#define X264_VERSION \"\"" >> config.h
VER="x"
fi
rm -f config.git-hash
API=`grep '#define X264_BUILD' < x264.h | sed -e 's/.* \([1-9][0-9]*\).*/\1/'`
echo "#define X264_POINTVER \"0.$API.$VER\"" >> config.h

The x264 sources snapshot is extracted to a main folder (with subfolders extracted). The icc folder from imk's package is a subfolder of the main folder.

[XhmikosR]

x264 r1347 x86 ICC11 + GCC (http://www.mediafire.com/?sharekey=3f33c77c2cf9ce25ab1eab3e9fa335ca2f2536f3517cf1e6).
Patches used:
x264_win_zone_parse_fix_06.diff
x264-r1347-nal_hrd-pic_struct-v11.patch

I've built an ICC QaxSSSE3 version which is supposed to work on AMD CPUs also, and a QxSSSE3 which is for Intel CPUs only.

@Boulder: I never got able to use imk's package so here (http://www.mediafire.com/?y3l4ezedjtm) is my package which uses MasterNobody's ICC patch and some stuff from imk's package (libgpac and inttypes.h). It's much easier to compile (no need for Cygwin or MSYS). I've put a Readme inside with some directions.

[Boulder]

x264 r1347 x86 ICC11 + GCC (http://www.mediafire.com/?sharekey=3f33c77c2cf9ce25ab1eab3e9fa335ca2f2536f3517cf1e6).
Patches used:
x264_win_zone_parse_fix_06.diff
x264-r1347-nal_hrd-pic_struct-v11.patch

I've built an ICC QaxSSSE3 version which is supposed to work on AMD CPUs also, and a QxSSSE3 which is for Intel CPUs only.

@Boulder: I never got able to use imk's package so here (http://www.mediafire.com/?y3l4ezedjtm) is my package which uses MasterNobody's ICC patch and some stuff from imk's package (libgpac and inttypes.h). It's much easier to compile (no need for Cygwin or MSYS). I've put a Readme inside with some directions.
Thank you, I've got a vacation this week so I'm able to do some comparison on my E6850 regarding performance. My initial test on your previous ICC builds showed that the Qx version had a noticable edge over the x264.nl build.

[LoRd_MuldeR]

I've built an ICC QaxSSSE3 version which is supposed to work on AMD CPUs also

Only if they support SSE2 at least. If you use /QaxSSSE3, the Intel compiler will still default to /arch:SSE2 for the "base" code path.

[XhmikosR]

@L_M: I don't have an AMD CPU so I don't really care if it works.:) The package is there, everyone can build everything they want.

[LoRd_MuldeR]

Yeah, sure.

But if you did use "/QaxSSSE3 /arch:SSE" then you'd get a binary that runs on any x264-capable CPU (x264 with ASM enabled requires SSE) and still uses a special "optimized" path on suitable Intel CPU's.

[imk]

Yeah, sure.

But if you did use "/QaxSSSE3 /arch:SSE" then you'd get a binary that runs on any x264-capable CPU (x264 with ASM enabled requires SSE) and still uses a special "optimized" path on suitable Intel CPU's.

I did some experiments with this and came to the conclusion not to mess with it.

Using /Qax<level> will only generate a codepath for the specified SSE level. If you use /QaxSSSE3, then only processors with SSSE3 will benefit, and not those with SSE2 or SSE3. The documentation specifies that if you would like to target more than one, then specify it multiple times on the same switch, i.e. /QaxSSSE3,SSE3,SSE2. However, this will only work correctly if you do not profile the binary. If you do profile it, then problems arise and the binary may crash for people, or produce awkward results.

Since this only benefits the C functions and not the ASM (which will likely be used anyway), I found it best to just limit it to SSE2 processors via /QxSSE2. /arch defaults to SSE2 so no change is needed there for me.


Also, Windows build of x264 r1347 built with ICC:
x264-r1347M-imk-win.7z (http://imk.cx/pc/x264/x264-r1347M-imk-win.7z)
win_build_info.txt (http://imk.cx/pc/x264/win_build_info.txt)

Added in x264-r1347-nal_hrd-pic_struct-v11.patch

[LoRd_MuldeR]

I found it best to just limit it to SSE2 processors via /QxSSE2. /arch defaults to SSE2 so no change is needed there for me.

One remark: The /Qx and /arch options are mutually exclusive. Only /Qax can be used in addition to /arch.

But if you use the /Qx option, then /arch is replaced and the resulting binary will run on suitable Intel CPU's only. It will abort with error message on Non-Intel CPU's.

Only if neither /Qx is used nor /arch is set explicitly, the Intel compiler will default to /arch:SSE2, which runs on any SSE2 capable CPU.

[imk]

One remark: The /Qx and /arch options are mutually exclusive. Only /Qax can be used in addition to /arch.

But if you use the /Qx option, then /arch is replaced and the resulting binary will run on suitable Intel CPU's only. It will abort with error message on Non-Intel CPU's.

Only if neither /Qx is used nor /arch is set explicitly, the Intel compiler will default to /arch:SSE2, which runs on any SSE2 capable CPU.

Yeah, you're right. I knew that, too. I just got mixed up in what I was writing. Good for other people to know, though.

[olapanekala]

x264 r1347 x86 ICC11 + GCC (http://www.mediafire.com/?sharekey=3f33c77c2cf9ce25ab1eab3e9fa335ca2f2536f3517cf1e6).
Patches used:
x264_win_zone_parse_fix_06.diff
x264-r1347-nal_hrd-pic_struct-v11.patch

I've built an ICC QaxSSSE3 version which is supposed to work on AMD CPUs also, and a QxSSSE3 which is for Intel CPUs only.

@Boulder: I never got able to use imk's package so here (http://www.mediafire.com/?y3l4ezedjtm) is my package which uses MasterNobody's ICC patch and some stuff from imk's package (libgpac and inttypes.h). It's much easier to compile (no need for Cygwin or MSYS). I've put a Readme inside with some directions.

Congrats !!!! QxSSS3 version rocks..... :thanks:

[techouse]

x264_x64_r1352_unpatched (http://techouse.project357.com/builds/vanilla/x64/revision1352.7z)
GCC 4.4.2 20091019 (x86_64.core2.Komisar), unpatched, generic, fprofiled

________________________________________________________________________________

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

x264_x64_r1352_techouse (http://techouse.project357.com/builds/x64/x264_x64_r1352_techouse.7z) | INFO (http://techouse.project357.com/nfo/x64/x264_x64_r1352_techouse.txt)
GCC 4.4.2 20091019 (x86_64.core2.Komisar), fprofiled, -march=core2

Patches used:

x264_win_zone_parse_fix_06.diff (http://kemuri9.net/dev/x264/patches/x264_win_zone_parse_fix_06.diff)
x264-r1352-nal_hrd-pic_struct-v11.patch (http://techouse.pastebin.com/fe24657)

[techouse]

x264_x64_r1353_unpatched (http://techouse.project357.com/builds/vanilla/x64/revision1353.7z)
GCC 4.4.2 20091019 (x86_64.core2.Komisar), unpatched, generic, fprofiled

________________________________________________________________________________

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

x264_x64_r1353_techouse (http://techouse.project357.com/builds/x64/x264_x64_r1353_techouse.7z) | INFO (http://techouse.project357.com/nfo/x64/x264_x64_r1353_techouse.txt)
GCC 4.4.2 20091019 (x86_64.core2.Komisar), fprofiled, -march=core2

Patches used:

x264_win_zone_parse_fix_06.diff (http://kemuri9.net/dev/x264/patches/x264_win_zone_parse_fix_06.diff)
x264-r1352-nal_hrd-pic_struct-v11.patch (http://techouse.pastebin.com/fe24657)

[JEEB]

x264 r1353 64bit unpatched:
download (http://x264.fushizen.eu/files/revision1353/x264.exe) ; hash (http://x264.fushizen.eu/files/revision1353/x264.md5)

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

________________________________________________________________________________

x264 r1353 32bit
download (http://x264.fushizen.eu/files/1353/x264.exe)

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


x264 r1353 64bit
download (http://x264.fushizen.eu/files/1353_x64/x264.exe)

built on Nov 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-r1352-nal_hrd-pic_struct-v11.patch (http://techouse.pastebin.com/fe24657)


git log: clicky (http://x264.fushizen.eu/files/git_log.txt)

A real Avisynth interface, oh jolly god this makes me yarr. Too bad I still haven't installed the 64bit Avisynth as it has far too few filters

[juGGaKNot]

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


crashes on open

AVIsource("C:\x264\movie.avi")
Crop(0, height%2, -width%2, 0)
ConvertToYV12()

--preset veryslow --level 3.2 --ref 5 --min-keyint fps --keyint fpx10 --bframes 3 --merange 32 --aq-mode 2 --sar 1:1 --aud
works fine with 1152 from you.

[JEEB]

How does avs2yuv like that script?

The way of loading avs scripts has changed (to a way closer to what avs2yuv does) so it might just be crashing because of errors you didn't get earlier.

[JEEB]

x264 r1354 64bit unpatched:
download (http://x264.fushizen.eu/files/revision1354/x264.exe) ; hash (http://x264.fushizen.eu/files/revision1354/x264.md5)

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

________________________________________________________________________________

x264 r1354 32bit
download (http://x264.fushizen.eu/files/1354/x264.exe)

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


x264 r1354 64bit
download (http://x264.fushizen.eu/files/1354_x64/x264.exe)

built on Nov 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-r1352-nal_hrd-pic_struct-v11.patch (http://techouse.pastebin.com/fe24657)


git log: clicky (http://x264.fushizen.eu/files/git_log.txt)

And fixes a 10L in MP4 output.

[juGGaKNot]

How does avs2yuv like that script?

I'll have to download and test.

LE :

avs2yuv works fine ( avs2yuv video.avs -o out.y4m )

Your 1354 4.3.4 works fine
techouse 1353 4.4.2 crashes

[techouse]

x264_x64_r1354_unpatched (http://techouse.project357.com/builds/vanilla/x64/revision1354.7z)
GCC 4.4.2 20091019 (x86_64.core2.Komisar), unpatched, generic, fprofiled

________________________________________________________________________________

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

x264_x64_r1354_techouse (http://techouse.project357.com/builds/x64/x264_x64_r1354_techouse.7z) | INFO (http://techouse.project357.com/nfo/x64/x264_x64_r1354_techouse.txt)
GCC 4.4.2 20091019 (x86_64.core2.Komisar), fprofiled, -march=core2

Patches used:

x264_win_zone_parse_fix_06.diff (http://kemuri9.net/dev/x264/patches/x264_win_zone_parse_fix_06.diff)
x264-r1354-nal_hrd-pic_struct-v11.patch (http://techouse.pastebin.com/fe24657)

[[ReX]]

About XhmikosR's ICC project.

They removed input/avis.c and the new files are:
input/vfw.c [moved from input/avis.c with 80% similarity]
input/avs.c
extras/avisynth_c.h

So I obviously removed input/avis.c from Input in the x264 project.
I added extras/avisynth_c.h to the libx264 project in extras/extras_h.

Now, if I add only input/vfw.c or input/avs.c in Input in the x264 project, I can compile, but I don't get AVS input.
And if I add both of them, I can't compile (I get this: avs_input already defined).

What should I do to get it working?

[kemuri-_9]

$ ./configure --intel
Platform: X86/X86_64
System: WINDOWS
asm: yes
avs input: avs
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no

$ make fprofiled

$ ./x264.exe --version
x264 0.79.1354M 636f98f
built on Nov 30 2009, intel: 1110 (20091012)


x264_icl_x86.exe (http://kemuri9.net/dev/x264/x264_icl_x86.exe)
x264_icl_x86_64.exe (http://kemuri9.net/dev/x264/x264_icl_x86.exe)

patches used:
x264_intel_support (http://kemuri9.net/dev/x264/patches/x264_intel_support.diff)
(x264_win_zone_parse_fix_06 is unnecessary here)

[juGGaKNot]

Since techouse pm'ed me about the errors i have made a test and i decided to post it here, if anyone else can test with the same setting ...

1352 techouse all work
1353 techouse all fail ( withous avs script also )
1354 techouse all fail ( withous avs script also )

jeebs all work

AVIsource("C:\x264\movie.avi")
Crop(0, height%2, -width%2, 0)
ConvertToYV12()

@echo off
x264_52.exe --pass 1 --preset veryslow --level 4.0 --bitrate 2000 --frames 300 --ref 5 --bframes 3 --merange 32 --aq-mode 2 --sar 1:1 --aud --output NUL x.avs
x264_52.exe --pass 2 --preset veryslow --level 4.0 --bitrate 2000 --frames 300 --ref 5 --bframes 3 --merange 32 --aq-mode 2 --sar 1:1 --aud --output x264_52.264 x.avs
echo.
echo.
x264_53.exe --pass 1 --preset veryslow --level 4.0 --bitrate 2000 --frames 300 --ref 5 --bframes 3 --merange 32 --aq-mode 2 --sar 1:1 --aud --output NUL x.avs
x264_53.exe --pass 2 --preset veryslow --level 4.0 --bitrate 2000 --frames 300 --ref 5 --bframes 3 --merange 32 --aq-mode 2 --sar 1:1 --aud --output x264_53.264 x.avs
echo.
echo.
x264_54.exe --pass 1 --preset veryslow --level 4.0 --bitrate 2000 --frames 300 --ref 5 --bframes 3 --merange 32 --aq-mode 2 --sar 1:1 --aud --output NUL x.avs
x264_54.exe --pass 2 --preset veryslow --level 4.0 --bitrate 2000 --frames 300 --ref 5 --bframes 3 --merange 32 --aq-mode 2 --sar 1:1 --aud --output x264_54.264 x.avs
echo.
echo.
x264_52.exe --pass 1 --preset veryslow --level 4.0 --bitrate 2000 --frames 300 --ref 5 --bframes 3 --merange 32 --aq-mode 2 --sar 1:1 --aud --output NUL x.avs
x264_52.exe --pass 2 --preset veryslow --level 4.0 --bitrate 2000 --frames 300 --ref 5 --bframes 3 --merange 32 --aq-mode 2 --sar 1:1 --aud --output x264_52.mp4 x.avs
echo.
echo.
x264_53.exe --pass 1 --preset veryslow --level 4.0 --bitrate 2000 --frames 300 --ref 5 --bframes 3 --merange 32 --aq-mode 2 --sar 1:1 --aud --output NUL x.avs
x264_53.exe --pass 2 --preset veryslow --level 4.0 --bitrate 2000 --frames 300 --ref 5 --bframes 3 --merange 32 --aq-mode 2 --sar 1:1 --aud --output x264_53.mp4 x.avs
echo.
echo.
x264_54.exe --pass 1 --preset veryslow --level 4.0 --bitrate 2000 --frames 300 --ref 5 --bframes 3 --merange 32 --aq-mode 2 --sar 1:1 --aud --output NUL x.avs
x264_54.exe --pass 2 --preset veryslow --level 4.0 --bitrate 2000 --frames 300 --ref 5 --bframes 3 --merange 32 --aq-mode 2 --sar 1:1 --aud --output x264_54.mp4 x.avs
pause

avis [info]: 1280x540 @ 30.00 fps (1472 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Slow
x264 [info]: profile Main, level 4.0
x264 [info]: frame I:2 Avg QP:13.13 size:133654
x264 [info]: frame P:221 Avg QP:13.40 size: 11130
x264 [info]: frame B:77 Avg QP:19.00 size: 25881
x264 [info]: consecutive B-frames: 57.7% 16.8% 20.1% 5.4%
x264 [info]: mb I I16..4: 50.1% 0.0% 49.9%
x264 [info]: mb P I16..4: 12.6% 0.0% 0.0% P16..4: 15.1% 0.0% 0.0% 0.0% 0
.0% skip:72.4%
x264 [info]: mb B I16..4: 15.1% 0.0% 0.0% B16..8: 24.4% 0.0% 0.0% direct:
16.2% skip:44.3% L0:37.3% L1:36.8% BI:25.9%
x264 [info]: final ratefactor: 18.00
x264 [info]: direct mvs spatial:72.7% temporal:27.3%
x264 [info]: coded y,uvDC,uvAC intra: 51.5% 45.7% 25.5% inter: 12.6% 7.4% 2.2%
x264 [info]: i16 v,h,dc,p: 27% 26% 21% 25%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 15% 28% 7% 5% 7% 7% 12% 5% 13%
x264 [info]: Weighted P-Frames: Y:7.7%
x264 [info]: kb/s:3775.83

encoded 300 frames, 16.67 fps, 3775.83 kb/s
avis [info]: 1280x540 @ 30.00 fps (1472 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Slow
x264 [info]: profile High, level 4.0
x264 [info]: frame I:2 Avg QP:20.26 size: 65236
x264 [info]: frame P:221 Avg QP:23.71 size: 6298
x264 [info]: frame B:77 Avg QP:25.41 size: 13172
x264 [info]: consecutive B-frames: 57.7% 16.8% 20.1% 5.4%
x264 [info]: mb I I16..4: 50.0% 40.6% 9.4%
x264 [info]: mb P I16..4: 2.6% 8.2% 0.6% P16..4: 6.7% 2.2% 1.2% 0.0% 0
.0% skip:78.4%
x264 [info]: mb B I16..4: 1.9% 7.3% 0.9% B16..8: 26.2% 3.0% 2.4% direct:
8.2% skip:50.1% L0:47.5% L1:43.2% BI: 9.3%
x264 [info]: 8x8 transform intra:70.0% inter:86.2%
x264 [info]: direct mvs spatial:80.5% temporal:19.5%
x264 [info]: coded y,uvDC,uvAC intra: 64.8% 52.4% 11.5% inter: 10.9% 7.4% 0.3%
x264 [info]: i16 v,h,dc,p: 26% 14% 4% 56%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 12% 13% 4% 7% 11% 11% 18% 9% 16%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 10% 11% 3% 6% 14% 11% 21% 7% 16%
x264 [info]: Weighted P-Frames: Y:7.7%
x264 [info]: ref P L0: 50.0% 9.6% 27.1% 4.9% 5.8% 2.4% 0.4%
x264 [info]: ref B L0: 79.8% 10.4% 6.2% 3.5%
x264 [info]: kb/s:2029.29

encoded 300 frames, 3.10 fps, 2029.29 kb/s


avs [info]: 1280x540 @ 30.00 fps (1472 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Slow
x264 [info]: profile Main, level 4.0
avs [info]: 1280x540 @ 30.00 fps (1472 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Slow
x264 [info]: profile High, level 4.0


avs [info]: 1280x540 @ 30.00 fps (1472 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Slow
x264 [info]: profile Main, level 4.0
avs [info]: 1280x540 @ 30.00 fps (1472 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Slow
x264 [info]: profile High, level 4.0


avis [info]: 1280x540 @ 30.00 fps (1472 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Slow
x264 [info]: profile Main, level 4.0
x264 [info]: frame I:2 Avg QP:13.13 size:133654
x264 [info]: frame P:221 Avg QP:13.40 size: 11130
x264 [info]: frame B:77 Avg QP:19.00 size: 25881
x264 [info]: consecutive B-frames: 57.7% 16.8% 20.1% 5.4%
x264 [info]: mb I I16..4: 50.1% 0.0% 49.9%
x264 [info]: mb P I16..4: 12.6% 0.0% 0.0% P16..4: 15.1% 0.0% 0.0% 0.0% 0
.0% skip:72.4%
x264 [info]: mb B I16..4: 15.1% 0.0% 0.0% B16..8: 24.4% 0.0% 0.0% direct:
16.2% skip:44.3% L0:37.3% L1:36.8% BI:25.9%
x264 [info]: final ratefactor: 18.00
x264 [info]: direct mvs spatial:72.7% temporal:27.3%
x264 [info]: coded y,uvDC,uvAC intra: 51.5% 45.7% 25.5% inter: 12.6% 7.4% 2.2%
x264 [info]: i16 v,h,dc,p: 27% 26% 21% 25%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 15% 28% 7% 5% 7% 7% 12% 5% 13%
x264 [info]: Weighted P-Frames: Y:7.7%
x264 [info]: kb/s:3775.83

encoded 300 frames, 17.19 fps, 3775.83 kb/s
avis [info]: 1280x540 @ 30.00 fps (1472 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Slow
x264 [info]: profile High, level 4.0
mp4 [info]: initial delay 1 (scale 30)
x264 [info]: frame I:2 Avg QP:20.26 size: 65236
x264 [info]: frame P:221 Avg QP:23.71 size: 6298
x264 [info]: frame B:77 Avg QP:25.41 size: 13172
x264 [info]: consecutive B-frames: 57.7% 16.8% 20.1% 5.4%
x264 [info]: mb I I16..4: 50.0% 40.6% 9.4%
x264 [info]: mb P I16..4: 2.6% 8.2% 0.6% P16..4: 6.7% 2.2% 1.2% 0.0% 0
.0% skip:78.4%
x264 [info]: mb B I16..4: 1.9% 7.3% 0.9% B16..8: 26.2% 3.0% 2.4% direct:
8.2% skip:50.1% L0:47.5% L1:43.2% BI: 9.3%
x264 [info]: 8x8 transform intra:70.0% inter:86.2%
x264 [info]: direct mvs spatial:80.5% temporal:19.5%
x264 [info]: coded y,uvDC,uvAC intra: 64.8% 52.4% 11.5% inter: 10.9% 7.4% 0.3%
x264 [info]: i16 v,h,dc,p: 26% 14% 4% 56%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 12% 13% 4% 7% 11% 11% 18% 9% 16%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 10% 11% 3% 6% 14% 11% 21% 7% 16%
x264 [info]: Weighted P-Frames: Y:7.7%
x264 [info]: ref P L0: 50.0% 9.6% 27.1% 4.9% 5.8% 2.4% 0.4%
x264 [info]: ref B L0: 79.8% 10.4% 6.2% 3.5%
x264 [info]: kb/s:2029.29

encoded 300 frames, 3.29 fps, 2029.29 kb/s


avs [info]: 1280x540 @ 30.00 fps (1472 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Slow
x264 [info]: profile Main, level 4.0
avs [info]: 1280x540 @ 30.00 fps (1472 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Slow
x264 [info]: profile High, level 4.0


avs [info]: 1280x540 @ 30.00 fps (1472 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Slow
x264 [info]: profile Main, level 4.0
avs [info]: 1280x540 @ 30.00 fps (1472 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Slow
x264 [info]: profile High, level 4.0
mp4 [info]: initial delay 1 (scale 30)
Press any key to continue . . .

[techouse]

As I see you only tested the patched x86 builds. Could you please test the patched x64 and the unpatched x64?

[juGGaKNot]

windows xp x86, amd x2 4000+

I'll try unpatched, if that fails than maybe compiler problem, i'll try komisar's 4.4.2 also

LE : ahh its 64bit, i'll test komisar than k ?

[kemuri-_9]

windows xp x86, amd x2 4000+

I'll try unpatched, if that fails than maybe compiler problem, i'll try komisar's 4.4.2 also

LE : ahh its 64bit, i'll test komisar than k ?

the -march=core2 part is your enemy here.
it successfully prevented you from being able to use x264 for barely, if any speedup on ssse3 supported cpus.
as your cpu is does not have ssse3.

[juGGaKNot]

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


Works

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

Does not work, same for 1354.

[Brazil2]

x264_x86_r1354_techouse (http://techouse.project357.com/builds/x86/x264_x86_r1354_techouse.7z)
Works: x264 -o testAVS.mp4 alex.avi

Crashes: x264 --crf 22 -o testAVS.mp4 alex.avi

Looks like it crashes as soon as an additional parameter is used such as:
ref 4
subme 10
me umh

Windows XP 32 bits, Core2Duo.

[rack04]

x264_x86_r1354M

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

Patched with:

x264-r1352-nal_hrd-pic_struct-v11.patch (http://techouse.pastebin.com/fe24657)
x264_win_zone_parse_fix_06.diff (http://kemuri9.net/dev/x264/patches/x264_win_zone_parse_fix_06.diff)


EDIT: I get crashes with this build so I have removed the download link.

[alexins]

x264 1354 x86 Unpatched - Works fine
x264 1354M x86 with x264-r1352-nal_hrd-pic_struct-v11.patch - crashes (my build, JEEB, rack04)
x264 1354M x86 with x264_hrd_pd_interlace.16_r1301.diff - Works fine

[techouse]

Did you use interlaced or progressive stuff to encode, since x264-r1352-nal_hrd-pic_struct-v11.patch may be problematic with interlaced videos.

[rack04]

Did you use interlaced or progressive stuff to encode, since x264-r1352-nal_hrd-pic_struct-v11.patch may be problematic with interlaced videos.

Progressive

[alexins]

Did you use interlaced or progressive stuff to encode, since x264-r1352-nal_hrd-pic_struct-v11.patch may be problematic with interlaced videos.

Progressive

[rack04]

x264 1354 x86 Unpatched - Works fine
x264 1354M x86 with x264_hrd_pd_interlace.16_r1301.diff - Works fine

Confirmed!

[techouse]

x264_x86_r1354_vanilla_techouse (http://techouse.project357.com/builds/vanilla/x86/x264_x86_r1354_vanilla_techouse.7z)
GCC 4.4.2 20091019 (x86.generic.Komisar), unpatched, generic, fprofiled

x264_x64_r1354_vanilla_techouse (http://techouse.project357.com/builds/vanilla/x64/x264_x64_r1354_vanilla_techouse.7z)
GCC 4.4.2 20091019 (x86_64.generic.Komisar), unpatched, generic, fprofiled

________________________________________________________________________________

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

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

Patches used:

x264_win_zone_parse_fix_06.diff (http://kemuri9.net/dev/x264/patches/x264_win_zone_parse_fix_06.diff)
x264-r1352-nal_hrd-pic_struct-v11.patch (http://techouse.pastebin.com/fe24657)

[laserfan]

x264 1354 x86 Unpatched - Works fine
x264 1354M x86 with x264-r1352-nal_hrd-pic_struct-v11.patch - crashes (my build, JEEB, rack04)
x264 1354M x86 with x264_hrd_pd_interlace.16_r1301.diff - Works fine
JEEB's 1354M x86 crashes for me also. His version 1352M is running OK.

[XhmikosR]

x264 x86 r1354 ICC + x264 x86 r1354 GCC unpatched profiled

http://www.mediafire.com/?sharekey=3f33c77c2cf9ce25ab1eab3e9fa335cafbdae63b01ff035e

[juGGaKNot]

Bla bla bla and bla + bla

v2 crashes, unpatched works.
Try building only with x264_win_zone_parse_fix_06.diff

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

JEEB's 1354M x86 crashes for me also. His version 1352M is running OK.

x264-r1352-nal_hrd-pic_struct-v11.patch is the same as it was @ 1352 so the error is from x264 revision 1353, why would it work with 1352 and not with 1353.

[JEEB]

Anyone who has gdb can try and test it with this (http://x264.fushizen.eu/files/1354/x264_1354_nhrd11_debug.exe) debug build. Has win_zone_parse_fix for mingw GCC and the nal-hrd patch in it.


$ patch -p1 < ../x264_win_zone_parse_fix_06.diff
patching file `encoder/ratecontrol.c'
Hunk #1 succeeded at 837 (offset 111 lines).

$ patch -p1 < ../x264-r1352-nal_hrd-pic_struct-v11.patch
patching file `common/common.c'
patching file `common/common.h'
patching file `common/frame.c'
patching file `common/frame.h'
patching file `common/osdep.h'
patching file `common/set.h'
patching file `encoder/encoder.c'
Hunk #9 succeeded at 2044 with fuzz 1.
Hunk #10 succeeded at 2174 (offset 6 lines).
Hunk #12 succeeded at 2248 (offset 6 lines).
patching file `encoder/ratecontrol.c'
Hunk #1 succeeded at 1568 (offset 23 lines).
patching file `encoder/ratecontrol.h'
patching file `encoder/set.c'
patching file `encoder/set.h'
patching file `x264.c'
Hunk #1 succeeded at 362 (offset 2 lines).
Hunk #3 succeeded at 546 (offset 2 lines).
patching file `x264.h'
Hunk #6 succeeded at 478 (offset 2 lines).

It could be the fuzzy thing, or then again -- something else.

[VFR maniac]

x264_x86_r1354_with_Trahald's_nal-hrd_16_and_ts-ctrl.rar (http://www.mediafire.com/?zrmytmldwqj)

gcc: 4.4.2-dw2
-march=core2
patch:
x264_hrd_pd_interlace.16_r1330.diff
x264_ts_ctrl_17_r1352.diff
x264_fix_extended_zones_r1330.diff

[LoRd_MuldeR]

If patches apply with "fuzz" that's not good! Offsets usually are okay, but "fuzz" means that the lines around the place where the patch used to apply have been changed and problems are likely.

So if you see the "succeeded at X with fuzz" message, you should carefully check the resulting code and, after a manual correction (if necessary), make a new DIFF file...

[JEEB]

Yeah, it has mostly been a'okay, though -- so I didn't pay much attention to it. Esp. since I wasn't the first one to build 1353 with it.

But certainly, will need checking. Too bad I'll have to leave for Sweden in an hour or so, which limits my options to actually debug it myself.

[CpT]

x264 x86 r1354 ICC + x264 x86 r1354 GCC unpatched profiled

http://www.mediafire.com/?sharekey=3f33c77c2cf9ce25ab1eab3e9fa335cafbdae63b01ff035e

TY - :thanks:

[kemuri-_9]

Anyone who has gdb can try and test it with this (http://x264.fushizen.eu/files/1354/x264_1354_nhrd11_debug.exe) debug build. Has win_zone_parse_fix for mingw GCC and the nal-hrd patch in it.

./x264_1354_nhrd11_debug.exe...(no debugging symbols found)...done
you kind of missed the whole debug symbol part there JEEB ^^

and everyone: post command lines that you get crashes/issue with,
there's nothing more of a pain than to get vague bug reports to try to track down and fix because you can't reproduce it.

anyways, Alex already stated on the mailing list that the v11 patch was broken since
r1348 when x264-r1352-nal_hrd-pic_struct-v11.patch posted to the ML and you should wait for v12

[techouse]

The fuzz is due to this.

This is the hunk in question:

x264-r1352-nal_hrd-pic_struct-v11.patch, from line 445 to line 473

@@ -1933,6 +2044,28 @@ int x264_encoder_encode( x264_t *h,
x264_frame_expand_border_mod16( h, fenc );

fenc->i_frame = h->frames.i_input++;
+ // fenc->i_pic_struct = 0;
+
+ if ( h->param.vui.b_timing_info_present )
+ {
+ if ( fenc->i_pic_struct == 0 ) // don't override if an app has set it before
+ {
+
+ if ( h->param.i_pulldown != X264_PULLDOWN_NONE )
+ {
+ fenc->i_pic_struct = h->param.pulldown.pattern[ fenc->i_frame % h->param.pulldown.mod];
+ }
+ else
+ {
+ if ( h->param.b_interlaced ) fenc->i_pic_struct = ( fenc->b_top_field_first ) ? 3 : 4;
+ }
+ }
+ }
+
+ // add number of "displayed" fields
+ // fixme: case of field frames handled incorrectly
+ fenc->i_field_cnt = h->i_disp_fields;
+ h->i_disp_fields += DeltaTfiDivisor[fenc->i_pic_struct];

if( h->frames.b_have_lowres )
x264_frame_init_lowres( h, fenc );


Now in encoder.c the last 2 lines, that the hunk refferences to are different:

ORIGINAL ENCODER.C, from line 1937 to line 1942

if( h->frames.b_have_lowres )
{
if( h->param.analyse.i_weighted_pred )
x264_weight_plane_analyse( h, fenc );
x264_frame_init_lowres( h, fenc );
}


The fuzzy patched output then looks like this:

PATCHED ENCODER.C, from line 2044 to line 2075

x264_frame_expand_border_mod16( h, fenc );

fenc->i_frame = h->frames.i_input++;
// fenc->i_pic_struct = 0;

if ( h->param.vui.b_timing_info_present )
{
if ( fenc->i_pic_struct == 0 ) // don't override if an app has set it before
{

if ( h->param.i_pulldown != X264_PULLDOWN_NONE )
{
fenc->i_pic_struct = h->param.pulldown.pattern[ fenc->i_frame % h->param.pulldown.mod];
}
else
{
if ( h->param.b_interlaced ) fenc->i_pic_struct = ( fenc->b_top_field_first ) ? 3 : 4;
}
}
}

// add number of "displayed" fields
// fixme: case of field frames handled incorrectly
fenc->i_field_cnt = h->i_disp_fields;
h->i_disp_fields += DeltaTfiDivisor[fenc->i_pic_struct];

if( h->frames.b_have_lowres )
{
if( h->param.analyse.i_weighted_pred )
x264_weight_plane_analyse( h, fenc );
x264_frame_init_lowres( h, fenc );
}

[Trahald]

Ive had fuzz put code in not even remotely right place. and you miss it because it compiles. but very wrong. definitely stop if you see that.

[kemuri-_9]

i'm not touching the v11 patch again,
I already sent Alex a revision of it before to fix a majority of the cosmetic issues it has.

wait for v12 or don't use it at all. it's as simple as that.

[techouse]

Yep...

[laserfan]

Alex already stated on the mailing list that the v11 patch was broken since r1348 when x264-r1352-nal_hrd-pic_struct-v11.patch posted to the ML...Sorry to interrupt, but to those of us non-programmers, not on the ML, but use --nal-hrd in our command lines, should we revert to a pre-r1348 build? How might the "broken" patch manifest itself if the x264 command gets to a completed output file (which looks good & plays well)?

[techouse]

Sorry to interrupt, but to those of us non-programmers, not on the ML, but use --nal-hrd in our command lines, should we revert to a pre-r1348 build? How might the "broken" patch manifest itself if the x264 command gets to a completed output file (which looks good & plays well)?
In that case just use r1352 till it's fixed.

[laserfan]

In that case just use r1352 till it's fixed.
:thanks:

[techouse]

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

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

Patches used:

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

[shon3i]

Sounds to me we back to old good HRD 16 :)

[juGGaKNot]

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

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

[rack04]

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

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

Patched with:

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

[techouse]

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

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

Patches used:

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

[juGGaKNot]

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

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

[Zm_Gorynych]

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

[juGGaKNot]

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

[[ReX]]

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

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

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

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

[[ReX]]

My x264 r1360 builds.

GCC builds

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

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


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

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

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

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

[imk]

r1360M built with ICC.

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

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

[olapanekala]

;1349881']My x264 r1360 builds.

GCC builds

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

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


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

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

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

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

any QxSSSE3 ICC builds for r1360?

[imk]

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

[[ReX]]

any QxSSSE3 ICC builds for r1360?

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

[olapanekala]

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

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

[[ReX]]

My x264 r1361 builds.

GCC builds

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

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


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

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

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

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

[juGGaKNot]

;1350942']GCC builds

what GCC ?

[chornobyl]

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

[Audionut]

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

[cogman]

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

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

All C functions are eventually broken down to ASM instructions.

[kemuri-_9]

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

All C functions are eventually broken down to ASM instructions.

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

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

[[ReX]]

what GCC ?

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

[juGGaKNot]

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

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

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

[jpsdr]

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

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

[rack04]

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

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

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

[juGGaKNot]

Darn i have to install everything again.

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

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

[komisar]

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

[JEEB]

Who said anything about having a vacation ;)

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

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

edit:

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

[juGGaKNot]

Who said anything about having a vacation ;)

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

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

edit:

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

x86 has x264_win_zone_parse_fix_06.diff ? not hrd one.

[JEEB]

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

[juGGaKNot]

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

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

[poisondeathray]

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

What currently doesn't work with the patch?

the wiki says:

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


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

[kemuri-_9]

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

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

[poisondeathray]

^thanks kemuri!

[[ReX]]

My x264 r1369 builds.

GCC 4.5.0 (experimental) builds

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

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


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

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

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

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


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

[tormento]

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

[burfadel]

;1351210']My x264 r1369 builds.

GCC 4.5.0 (experimental) builds

Should I use 4.4.2 or 4.3.4 then?

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

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

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

[juGGaKNot]

Should I use 4.4.2 or 4.3.4 then?

Use what you want ofc

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

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

[rack04]

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

[XhmikosR]

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

[LoRd_MuldeR]

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

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

[XhmikosR]

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

[LoRd_MuldeR]

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

[XhmikosR]

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

[jpsdr]

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

[XhmikosR]

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

[olapanekala]

;1351210']My x264 r1369 builds.

GCC 4.5.0 (experimental) builds

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

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


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

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

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

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



Should I use 4.4.2 or 4.3.4 then?

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

[[ReX]]

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


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

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

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


Use what you want ofc

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

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


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

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

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

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

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

[XhmikosR]

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

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

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

[Dark Shikari]

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

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

[imk]

r1373M built with ICC.

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

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

[CpT]

Sweet!

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

[Dark Shikari]

Sweet!

Hey DS is re-registration required for the other forums? Or was the db imported?I'm not about to copy-paste the entirety of doom9, even if I had access to the db ;)

Anyways, ask questions about the site there, not here.

[CpT]

I only asked because smf has a slick importer.


Back to testing the new version :thanks:

[rack04]

Fix zone parsing on mingw

Due to MinGW evidently being in the hands of a pack of phenomenal idiots, MinGW does not have strtok_r, a basic string function.

As such, remove the dependency on strtok_r in zone parsing.

Previously, using zones for anything other than ratecontrol failed.

So does this mean that we don't need to compile x264 with win_zone_parse_fix_06.diff anymore?

[imk]

So does this mean that we don't need to compile x264 with win_zone_parse_fix_06.diff anymore?

It's no longer needed.

[XhmikosR]

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

x264.x86.r1373M.ICC11.O3.QxSSSE3
x264_hrd_pd_interlace.16_r1369.diff (http://komisar.gin.by/x.patch/last.used/x264_hrd_pd_interlace.16_r1369.diff)
x264_icc_r1373.diff

x264.x86.r1373M.ICC11.O3.QaxSSSE3
x264_hrd_pd_interlace.16_r1369.diff (http://komisar.gin.by/x.patch/last.used/x264_hrd_pd_interlace.16_r1369.diff)
x264_icc_r1373.diff

x264.x86.r1373M.core2 (gcc 4.4.2)
x264_hrd_pd_interlace.16_r1369.diff (http://komisar.gin.by/x.patch/last.used/x264_hrd_pd_interlace.16_r1369.diff)

x264.x86.r1373.core2 (gcc 4.4.2)
Unpatched

[ajp_anton]

How can i test a stream encoded by 1369 if it's OK? Started the encode before it started crashing on people, and it just finished without crashing.

[Dark Shikari]

How can i test a stream encoded by 1369 if it's OK? Started the encode before it started crashing on people, and it just finished without crashing.Grab JM.

ldecod -i input.h264

If it errors out before the end, the stream is corrupt.

[XhmikosR]

BTW, I forgot to thank Dark Shikari for the time he spent on fixing the bug caused by 1364. I wish I could have helped more, but my debug build didn't crash.

[ajp_anton]

Grab JM.

ldecod -i input.h264

If it errors out before the end, the stream is corrupt.Thanks.
287952 frames with no errors. How lucky was I? =)

[techouse]

x264_x86_r1373_vanilla_gcc_techouse (http://techouse.project357.com/builds/vanilla/x86/x264_x86_r1373_vanilla_gcc_techouse.7z)
GCC 4.4.2 20091019 (x86.generic.Komisar), unpatched, generic, fprofiled

x264_x64_r1373_vanilla_gcc_techouse (http://techouse.project357.com/builds/vanilla/x64/x264_x64_r1373_vanilla_gcc_techouse.7z)
GCC 4.4.2 20091019 (x86_64.generic.Komisar), unpatched, generic, fprofiled

---------------------------------------------------------

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

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

Patches used:

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

---------------------------------------------------------

x264_x86_r1373_vanilla_icc_techouse (http://techouse.project357.com/builds/vanilla/x86/x264_x86_r1373_vanilla_icc_techouse.7z)
Intel C++ Compiler 11.1.051, almost unpatched, -QxSSSE3 -O3, fprofiled

x264_x64_r1373_vanilla_icc_techouse (http://techouse.project357.com/builds/vanilla/x64/x264_x64_r1373_vanilla_icc_techouse.7z)
Intel C++ Compiler 11.1.051, almost unpatched, -QxSSSE3 -O3, fprofiled

Patches used:

x264_icc_13_win.diff (http://imk.cx/pc/x264/build-icc-win.7z)

---------------------------------------------------------

x264_x86_r1373_icc_techouse (http://techouse.project357.com/builds/x86/x264_x86_r1373_icc_techouse.7z) | INFO (http://techouse.project357.com/nfo/x86/x264_x86_r1373_icc_techouse.txt)
Intel C++ Compiler 11.1.051, -QxSSSE3 -O3, fprofiled

x264_x64_r1373_icc_techouse (http://techouse.project357.com/builds/x64/x264_x64_r1373_icc_techouse.7z) | INFO (http://techouse.project357.com/nfo/x64/x264_x64_r1373_icc_techouse.txt)
Intel C++ Compiler 11.1.051, -QxSSSE3 -O3, fprofiled

Patches used:

x264_icc_13_win.diff (http://imk.cx/pc/x264/build-icc-win.7z)
x264_hrd_pd_interlace.16_r1369.diff (http://komisar.gin.by/x.patch/last.used/x264_hrd_pd_interlace.16_r1369.diff)

[rack04]

x264_x86_r1373M (http://www.megaupload.com/?d=OT5LLP4R)

Toolchain:
mingwrt-3.16
w32api-3.13
binutils-2.20
gcc-core-4.4.2
zlib-1.2.3
yasm-0.8.0
Patch:
x264_hrd_pd_interlace.16_r1369.diff (http://komisar.gin.by/x.patch/last.used/x264_hrd_pd_interlace.16_r1369.diff)
Build:
./configure --extra-cflags="-march=core2"
make fprofiled VIDS="/c/x264/crew_4cif.y4m /c/x264/parkrun.1280x720.yuv"

[Brazil2]

Bug or feature ?

I encode using --psy-rd=1:0.15 but when it's done MediaInfo reports psy_rd=1.0:0.2

So what is wrong ? Is x264 rounding the input value or is MediaInfo showing a rounded value ?
I'm quite sure that the correct value of 0.15 was shown with older builds of x264 like six months ago, maybe more.

[LoRd_MuldeR]

I encode using --psy-rd=1:0.15 but when it's done MediaInfo reports psy_rd=1.0:0.2

if( p->analyse.b_psy )
s += sprintf( s, " psy_rd=%.1f:%.1f", p->analyse.f_psy_rd, p->analyse.f_psy_trellis );

:p

[nurbs]

x264 rounds the values that get written to the file to one decimal, but the value used during encoding is not changed. AFAIK it's always been that way.

[Brazil2]

OK thanks for clarification :)
Although I wonder why it's made like that.

[LoRd_MuldeR]

Although I wonder why it's made like that.

Probably because "psy_rd" was added to param2string() before the "film" tune started using Psy RDO 0.15 ^^

[qyot27]

']I don't know if it's possible to have two GCC versions at the the same time without screwing things up.
It's possible as long as you keep them separate. Two concurrent toolchains (MSys+MinGW+GCC 3.4.5 in C:\msys, and MSys+MinGW+GCC 4.4.2 in C:\WINDOWS\msys, for example) are fine, but two concurrent GCC versions on one MinGW install (MSys+MinGW+GCC 3.4.5+GCC 4.4.2 in C:\msys) is not, to my knowledge. I couldn't get it to work when I tried. It'd be handier if it could work, though.






For those that want to try it out, I've served up an MSys+MinGW package that uses GCC 3.4.5 instead of the 4.x branch. I've only tested it on my XP Home SP3 setup and my mom's Vista (pre-SP1) laptop, and it worked fine on both. There's a text file provided that lists the things it includes, and it should be fine for compiling x264 and ffmpeg, at the very least. You can download it here (it expects to be extracted to C:\):

http://www.mediafire.com/?zzjt3vlim2n

[kemuri-_9]

you can have as many versions installed as you want.

the tricky part is just calling the right gcc if you have a bunch around...
as you'll end up resorting to renaming executables or using full pathnames to get the right one.
(this is why linux distros generally use a version postfix to signify which version of gcc it is)

as for myself, i have 3 different mingws around.

[qyot27]

Is there any sort of tutorial on how to set up multiple versions of GCC correctly? I couldn't find any through Google when I looked. It's mindnumbingly simple on Linux, as calling CC= takes care of it, but how does that work out on Windows?

This is why I simply go for keeping them separate and not letting any of them interfere with each other.

[J_Darnley]

Is there any sort of tutorial on how to set up multiple versions of GCC correctly? I couldn't find any through Google when I looked. It's mindnumbingly simple on Linux, as calling CC= takes care of it, but how does that work out on Windows?

Well since cygwin and msys are unix-like, setting CC should work fine. Certainly using --cc when configuring ffmpeg gets it to use my gcc 4 which is installed in the same folder as 3.4.5

[qyot27]

Well since cygwin and msys are unix-like, setting CC should work fine. Certainly using --cc when configuring ffmpeg gets it to use my gcc 4 which is installed in the same folder as 3.4.5
Downloaded TDM SJLJ GCC 4.4.1 core and g++ packages.*
Extracted them, and appended -4.4.1 to the end of each.
Put them in /bin.

cd x264
CC=gcc4.4.1 ./configure (or CC=gcc4, doesn't matter)
No working C compiler found.

Neither does it work if I unpack them without renaming to /gcc4 and add an entry to fstab that points there. Still no working C compiler. Like kemuri-_9 said, you have to constantly rename the gcc bin files back and forth for which one you want to use at the time, or use full pathnames (and CC= and --cross-prefix are not the solutions to that). I knew that already, which is why I said separate installations are the easiest to deal with. Then no renaming is necessary - just fire up your GCC 4.4.x-enabled installation, or your GCC 3.4.5-enabled one, which don't talk to each other at all and have a complete MSys each that's are all their own.

Cygwin and MSys may both be Unix-like, but MSys =/= Cygwin. If you want to explain how you got multiple GCC versions working under a single install of MSys without having to rename anything and only calling CC= or --cc=, then I'd be more than happy to hear it. But from where I'm standing (including wasting all of this morning trying to no avail), it's not possible.




*I even grabbed komisar's GCC 4.4.2 build and extracted it out to the empty /mingw directory and pointed it there - still no dice.

[J_Darnley]

CC=gcc-sjlj ./configure works4me.
Is gcc actually called "gcc4.4.1.exe" or "gcc4.exe"?
I think I just extracted the 4.2.1 archives (from mingw) into the my mingw folder and they just worked. They already had the -sjlj suffix.

[kemuri-_9]

if you only download the different gcc and don't have the libs and include files in the new gcc's search path,
you can cheat by adding the library and include paths from your full installation to the commandline,

i.e.:
CC=gcc-blah ./configure --extra-cflags=-I/mingw/include --extra-ldflags=-L/mingw/lib

where there's a full installation at /mingw and the CC you give is only the compiler (no runtime and no headers in its search path)

you won't have to do this if you extract the gcc to the same prefix as your current installation (granted the executable names are different and won't overwrite anything)

[qyot27]

Ok, thanks. Everything's working now the way it should. Now I just have to get 4.4.2 in there instead of 4.4.1.

[techouse]

Another way to permanently change the default CC is via /etc/fstab

[[ReX]]

My x264 r1376 builds.

GCC 4.5.0 (experimental) builds

Generic (http://www.mediafire.com/?iqmwouzu5jm) (fprofiled)
Patch used: x264_hrd_pd_interlace.16_r1369.diff

-march=core2 (http://www.mediafire.com/?yk3vxi2nmqi) (fprofiled)
Patch used: x264_hrd_pd_interlace.16_r1369.diff


(NEW) GCC 3.4.6 build

Generic (http://www.mediafire.com/?djxzoxzcunm) (fprofiled)
Patch used: x264_hrd_pd_interlace.16_r1369.diff


ICC 11.1.051 builds
Thanks to MasterNobody and XhmikosR.

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

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

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

[techouse]

x264_x86_r1376_vanilla_gcc_techouse (http://techouse.project357.com/builds/vanilla/x86/x264_x86_r1376_vanilla_gcc_techouse.7z)
GCC 4.4.2 20091019 (x86.generic.Komisar), unpatched, generic, fprofiled

x264_x64_r1376_vanilla_gcc_techouse (http://techouse.project357.com/builds/vanilla/x64/x264_x64_r1376_vanilla_gcc_techouse.7z)
GCC 4.4.2 20091019 (x86_64.generic.Komisar), unpatched, generic, fprofiled

---------------------------------------------------------

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

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

Patches used:

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

---------------------------------------------------------

x264_x86_r1376_vanilla_icc_techouse (http://techouse.project357.com/builds/vanilla/x86/x264_x86_r1376_vanilla_icc_techouse.7z)
Intel C++ Compiler 11.1.051, almost unpatched, -QxSSSE3 -O3, fprofiled

x264_x64_r1376_vanilla_icc_techouse (http://techouse.project357.com/builds/vanilla/x64/x264_x64_r1376_vanilla_icc_techouse.7z)
Intel C++ Compiler 11.1.051, almost unpatched, -QxSSSE3 -O3, fprofiled

Patches used:

x264_icc_13_win.diff (http://imk.cx/pc/x264/build-icc-win.7z)

---------------------------------------------------------

x264_x86_r1376_icc_techouse (http://techouse.project357.com/builds/x86/x264_x86_r1376_icc_techouse.7z) | INFO (http://techouse.project357.com/nfo/x86/x264_x86_r1376_icc_techouse.txt)
Intel C++ Compiler 11.1.051, -QxSSSE3 -O3, fprofiled

x264_x64_r1376_icc_techouse (http://techouse.project357.com/builds/x64/x264_x64_r1376_icc_techouse.7z) | INFO (http://techouse.project357.com/nfo/x64/x264_x64_r1376_icc_techouse.txt)
Intel C++ Compiler 11.1.051, -QxSSSE3 -O3, fprofiled

Patches used:

x264_icc_13_win.diff (http://imk.cx/pc/x264/build-icc-win.7z)
x264_hrd_pd_interlace.16_r1369.diff (http://komisar.gin.by/x.patch/last.used/x264_hrd_pd_interlace.16_r1369.diff)

[techouse]

if you only download the different gcc and don't have the libs and include files in the new gcc's search path,
you can cheat by adding the library and include paths from your full installation to the commandline,

i.e.:
CC=gcc-blah ./configure --extra-cflags=-I/mingw/include --extra-ldflags=-L/mingw/lib

where there's a full installation at /mingw and the CC you give is only the compiler (no runtime and no headers in its search path)

you won't have to do this if you extract the gcc to the same prefix as your current installation (granted the executable names are different and won't overwrite anything)
If you're doing more than 1 build with the same CC it's probably a good idea to export it before running configure and then use it as default.

[olapanekala]

Happy Holidays to everyone

[aegisofrime]

My version of x264 (r1376) feels old :D Are the x264 developers planning a Christmas present for us? ;)

[Fr4nz]

Probably they're on vacation like us...

[Sharc]

My version of x264 (r1376) feels old :D Are the x264 developers planning a Christmas present for us? ;)
What improvements / features are you waiting for? :D

[Dark Shikari]

Download this clip, open it in VLC or MPC-HC, and seek anywhere in the video. (http://mirror05.x264.nl/Dark/PIRtest.mkv) Oh and it has no keyframes.

[LoRd_MuldeR]

Interesting. What does "PIR" stand for please? And is there any loss in compression efficiency?

[Dark Shikari]

Interesting. What does "PIR" stand for please? And is there any loss in compression efficiency?Periodic Intra Refresh. The loss exists, but it's not that large when compared to having a similar keyframe interval (e.g. keyint=35 for a PAL SD video.)

More importantly, combined with other changes, this allows:

1. Zero encoder, decoder, and buffer latency.
2. Error resilience up to 20-25% packet loss rates, using one-slice-per-packet.
3. No keyframes beyond the first, so constant or capped framesize are both possible.
4. Realtime HD encoding at zero latency.

In other words, x264 is now the greatest encoder in the world for realtime video applications, like videoconferencing, and anyone who uses anything else needs to have their head examined ;)

[LoRd_MuldeR]

I see. But I guess we won't use that for "movie" encodes with (almost) unrestricted key-frame interval and no "zero latency" requirement, right?

BTW: The DivX H.264 Decoder crashes when seeking in that stream ;)

[TEB]

Periodic Intra Refresh. The loss exists, but it's not that large when compared to having a similar keyframe interval (e.g. keyint=35 for a PAL SD video.)

More importantly, combined with other changes, this allows:

1. Zero encoder, decoder, and buffer latency.
2. Error resilience up to 20-25% packet loss rates, using one-slice-per-packet.
3. No keyframes beyond the first, so constant or capped framesize are both possible.
4. Realtime HD encoding at zero latency.

In other words, x264 is now the greatest encoder in the world for realtime video applications, like videoconferencing, and anyone who uses anything else needs to have their head examined ;)

Awesomely cewl, do u have any reccomendations for a HD-SDI input card that would work with x264 in a workflow that can spew out Multicast? I wanna show the guys at work how good quality X264 can do vs a HW encoder for RT HD coding ,;) Now we just need to make a good RT workflow that will mux audio and put it into a container ;)
TE

[Disabled]

That looks and sounds awesome. That feature is part of the extended profile, is it? Would it be possible to refresh in different patterns than from top to bottom? Like in an interlaced pattern?
And do you know of any software using x264 for streaming? Like a videoconference app?

[Dark Shikari]

That looks and sounds awesome. That feature is part of the extended profile, is it?No, it's an encoder-side feature unrelated to profile.Would it be possible to refresh in different patterns than from top to bottom? Like in an interlaced pattern?Only if we enabled constrained intra prediction. All patterns that don't use constrained intra prediction must work from the top left to the bottom right (in some variation).And do you know of any software using x264 for streaming? Like a videoconference app?There are at least three low-latency x264-using apps in development.

[Blue_MiSfit]

Nice :) Merry Christmas, DS - and all the trolls on doom9 :D

~MiSfit

[Sharc]

more importantly, combined with other changes, this allows:

1. Zero encoder, decoder, and buffer latency.
2. Error resilience up to 20-25% packet loss rates, using one-slice-per-packet.
3. No keyframes beyond the first, so constant or capped framesize are both possible.
4. Realtime hd encoding at zero latency.

wow! :)

[Emulgator]

While trying to find a x264 setting that would import into Sony DVD-A 5.0b Build 180 (and probably Encore CS3 / DVDDitProHD 6.4):
x264r1376M (Jeeb) run from MeGUI 0.3.1.1060 zathor patched. Commandline by hand:
program --profile high --level 4 --crf 18 --thread-input --keyint 25 --min-keyint 2 --b-adapt 0 --interlaced --ref 4 --weightp 0 --qpmax 45 --ipratio 1.2 --pbratio 1.2 --vbv-maxrate 24000 --no-mbtree --trellis 2 --psy-rd 1.0:0.20 --no-mixed-refs --no-dct-decimate --aud --nal-hrd --sar 1:1 --output "output" "input"
DVD-A imports as .avc, does not announce transcoding (yippie), but fails on muxing.
Sony DVD-A 5.0b Build180 Error Report:
Dateiname: STREAM/00000.m2ts Status: TSWrapper.dll::CTSWrapper::ProcThreadMain::This program has a bug. - m_ptsOfNextGOP is empty.

Encodes made with x264r1376MJeeb (nal_hrd patched16(?) (looks ok, but fails on muxing)
vs.Sony Vegas 9.0c Build 896 as SONY AVC(muxes in DVD-A without transcoding, but looks ugly)

While examining and comparing these .avc elementaries I found the following missing entries suggesting that nal-hrd might not be embedded properly:
Screenshot x264 .avc mediainfo
http://dvd-manufactur.de/files/20091226_Screenshot03_x264_mediainfo.png
Screenshot x264 .avc Stream Summary (my fault: no vbv) Screenshot Vegas 9 .avc Stream Summary Screenshot x264 .avc Stream Summary (now with vbv)
http://dvd-manufactur.de/files/20091226_Screenshot03_x264_Stream_Summary.pnghttp://dvd-manufactur.de/files/20091226_Screenshot04_V9_Stream_Summary.pnghttp://dvd-manufactur.de/files/20091226_Screenshot05_x264_Stream_Summary.png
Screenshot x264 .avc Header NAL (my fault: no vbv) Screenshot Vegas 9 .avc Header NAL Screenshot x264 .avc Header NAL (now with vbv)
http://dvd-manufactur.de/files/20091226_Screenshot03_x264_Header_NAL.pnghttp://dvd-manufactur.de/files/20091226_Screenshot04_V9_Header_NAL.pnghttp://dvd-manufactur.de/files/20091226_Screenshot05_x264_Header_NAL.png
Screenshot x264 .avc Header SPS (my fault: no vbv) Screenshot Vegas 9 .avc Header SPS top Screenshot x264 .avc Header SPS (now with vbv)
http://dvd-manufactur.de/files/20091226_Screenshot03_x264_Header_SPS.pnghttp://dvd-manufactur.de/files/20091226_Screenshot04_V9_Header_SPS_top.pnghttp://dvd-manufactur.de/files/20091226_Screenshot05_x264_Header_SPS.png
Screenshot Vegas 9 .avc Header SEI top Screenshot x264 .avc Header SEI top(now with vbv) Screenshot x264 .avc Header SEI bottom(now with vbv)
http://dvd-manufactur.de/files/20091226_Screenshot04_V9_Header_SEI_top.pnghttp://dvd-manufactur.de/files/20091226_Screenshot05_x264_Header_SEI_top.pnghttp://dvd-manufactur.de/files/20091226_Screenshot05_x264_Header_SEI_bottom.png
Screenshot Vegas 9 .avc Header SPS bottom
http://dvd-manufactur.de/files/20091226_Screenshot04_V9_Header_SPS_bottom.png

Could it be that other nal-hrd patched builds work somewhere else
or can I assume that the patch itself is broken
or is it driver error on my side?

[nurbs]

You haven't specified --vbv-bufsize which is needed if you want nal-hrd to work.

It is possible that blu-ray only allows for 3 reference frames, but I'm not sure about that since I never encode for blu-ray.

[shon3i]

It is possible that blu-ray only allows for 3 reference framesIt allow 4 for 1080 and 6 for 720/576/480 @ level 4.1 and 4.0

[Emulgator]

You haven't specified --vbv-bufsize which is needed if you want nal-hrd to work.

Oh shame, I forgot. Coming from the Blu-ray presets and dreaming all is fine...
I will repeat that with --vbv-bufsize = 30000.

--mvrange = 511 was missing too in CL, but is default anyway now, my luck.

In x264 output I am seeing log2_max_mv_length_horizontal coming out as 2^10 = 1024.
Not sure about the interpretation, but anyway, no showstopper.

Sony AVC is coming out of Vegas and passes muxing with a log2_max_mvrange_length_horizontal of 2^16...
_________________________________________________________________________________

P.S Yep, driver error on my side, nal_hrd is written now. Further testing for muxer acceptance...
_________________________________________________________________________________

Back from testing: The report is still there (Sony DVD-A 5.0b Build 180):
("Dateiname: STREAM/00000.m2ts Status: TSWrapper.dll::CTSWrapper::ProcThreadMain:
This program has a bug. - m_ptsOfNextGOP is empty")

[shon3i]

Try with keyint 50

[Emulgator]

encoding keyint 50 now...

BTW, DVD-A sees 4 refs as ok for not transcoding in L4.0 (slices=0)
and L4.1 (slices=4).

Seems that in L4.0 (slices=0) I just have to take care to take bitrates down, no further restrictions.
Right now using L4.0 with 12Mbps-16Mbit-18Mbps as in Vegas's max AVC preset
were not scheduled for trancoding, but failed on muxing.
____________________________________________________________________

Finished encoding, importing without transcoding attempt,
muxing fails, the error message stays as above.

More tomorrow.

[Lyris]

Emulgator, sorry I can't advise on your problem - but what program are you using to generate the "Stream Summary" and "Header Info" windows?

[ACrowley]

Is b-pyramid +mbtree stable (generally and for HW Players )with latest x264 rev 1376 ?

[Fr4nz]

Is b-pyramid +mbtree stable (generally and for HW Players )with latest x264 rev 1376 ?

Yes it is.

[Emulgator]

Lyris: h264visa. 30 days trial. (Thanks Lord Mulder !)

[rack04]

x264_x86_r1376M (http://www.mediafire.com/?nmznyjzngey)

Toolchain:
mingwrt-3.16
w32api-3.13
binutils-2.20
gcc-core-4.4.2
zlib-1.2.3
yasm-0.8.0
Patch:
x264_hrd_pd_interlace.16_r1369_fix.diff (http://komisar.gin.by/x.patch/last.used/x264_hrd_pd_interlace.16_r1369.diff)
Build:
./configure --extra-cflags="-march=core2"
make fprofiled VIDS="/c/x264/crew_4cif.y4m /c/x264/parkrun.1280x720.yuv"

[aegisofrime]

rack04, would you mind doing a build with ./configure --extra-cflags="-march=amdfam10"?

I tried building one myself with those flags, but it just won't reach the performance of yours of other builds. Perhaps I'm missing quite a few links in the toolchain.

[LoRd_MuldeR]

I tried building one myself with those flags, but it just won't reach the performance of yours of other builds. Perhaps I'm missing quite a few links in the toolchain.

You did have ASM (YAMS) and PThreads enabled in your build, did you?

[aegisofrime]

You did have ASM (YAMS) and PThreads enabled in your build, did you?

You query that using ./configure right? If so, yes.

Pardon me for the noob questions, as I'm still a noob compiler. I merely following the guide over at Doom10. But seeing as I'm using a Phenom II I thought of compiling a -march=amdfam10 version for myself, to see if there's any performance increase.

[LoRd_MuldeR]

You query that using ./configure right? If so, yes.

Nope. I ask if you have both, YASM and PThreads, installed in your build environment.

If those are missing, your build will have ASM and/or multi-threading disabled, no matter how ./configure is called :p

And it would explain why your build is noticeably slower than others!

Things like the "--march" switch and the GCC version you use only have a very minor influence on the encoding speed.

However ICL builds are known to be bit faster than GCC builds, at least on Intel CPU's.

[Dark Shikari]

Nope. I ask if you have both, YASM and PThreads, installed in your build environment.

If those are missing, your build will have ASM and/or multi-threading disabled, no matter how ./configure is called :pNo, x264 will outright refuse to build if you don't have yasm installed.

[aegisofrime]

I followed the guide here, http://doom10.org/index.php?topic=26.0, which didn't mention anything about Pthreads. Can I assume that it's not installed? Anyway, time to Google I guess!

EDIT: Was poking around in my MinGW\bin folder and found that it already has the pthreads dlls. :/

[rack04]

rack04, would you mind doing a build with ./configure --extra-cflags="-march=amdfam10"?

I tried building one myself with those flags, but it just won't reach the performance of yours of other builds. Perhaps I'm missing quite a few links in the toolchain.

x264_x86_r1376M (http://www.mediafire.com/?tet041nlyim)

Toolchain:
mingwrt-3.16
w32api-3.13
binutils-2.20
gcc-core-4.4.2
zlib-1.2.3
yasm-0.8.0
Patch:
x264_hrd_pd_interlace.16_r1369_fix.diff (http://komisar.gin.by/x.patch/last.used/x264_hrd_pd_interlace.16_r1369.diff)
Build:
./configure --extra-cflags="-march=amdfam10"
make fprofiled VIDS="/c/x264/parkrun.1280x720.yuv"

[aegisofrime]

Woot! Thanks Rack04! *downloads*

[LoRd_MuldeR]

I followed the guide here, http://doom10.org/index.php?topic=26.0, which didn't mention anything about Pthreads. Can I assume that it's not installed? Anyway, time to Google I guess!

Look what "./configure" says ;)

If you have ptheads installed in your build environment, it should look like this:

MuldeR@MULDER-PC /x264/x264-src
$ ./configure
Platform: X86
System: MINGW
asm: yes
avs input: avs
mp4 output: no
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no

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

Latest MinGW/GCC with pthreads included can be found here, for example:
http://www.xvidvideo.ru/2009-10-22-10-49-14/cat_view/28-cross-mingwgcc-x86x64/160-cross-mingwgcc-45-x86x64.html

(I guess you'd want that with "static" pthreads, so your x264.exe won't depends on the pthreads DLL)

[qyot27]

EDIT: Was poking around in my MinGW\bin folder and found that it already has the pthreads dlls. :/
The dlls aren't what you need, and that's the wrong directory. Go into /lib and find all the files with names starting with libpthread. Delete all of them except libpthreadGC2-static.a. Rename it to libpthreadGC2.a, and voila. You may need to adjust where it resides, though - depending on your MinGW environment, you could have several /lib directories (for instance, C:\msys\lib, C:\msys\local\lib, and C:\msys\mingw\lib; I install everything to root so I only have to deal with C:\msys\lib and C:\msys\local\lib, but other guides and packages have things set up differently).

The dlls in /bin are there for the .exe files that are dynamically linked to them, rather than statically linked. Without the dlls being there, those apps that need them wouldn't run. But they don't affect how things get compiled elsewise.

[roozhou]

My workaround:
1) Download pthreads-win32 source code. I got it from here (http://sources-redhat.mirrors.airband.net/pthreads-win32).
2) Create "pthreads" folder under x264 and copy all pthread source code files to it.
3) Add pthreads/pthreads.c to x264's Makefile.

This also applies to GPAC.

[kemuri-_9]

My workaround:
1) Download pthreads-win32 source code. I got it from here (http://sources-redhat.mirrors.airband.net/pthreads-win32).
2) Create "pthreads" folder under x264 and copy all pthread source code files to it.
3) Add pthreads/pthreads.c to x264's Makefile.

This also applies to GPAC.

that is the ugliest thing i have ever heard of.
i do hope you don't do that for when lavf/ffms support is added.

[roozhou]

that is the ugliest thing i have ever heard of.
Ugliest? It makes compilation much easier and allows better optimization from compilers. Look at mplayer's code. It has a lot of "internal" libraries including libmpeg2, liba52, libdvdread, libfaad2, etc.

Why should everyone search and download dependency libraries? Sometimes the official sites only provide source code and you have to configure && make && make install yourself. And you may have to download more tools to configure and compile these package. I hate that.
i do hope you don't do that for when lavf/ffms support is added.
Why? This will still work when lavf/ffms support is added.

[aegisofrime]

Look what "./configure" says ;)

If you have ptheads installed in your build environment, it should look like this:

MuldeR@MULDER-PC /x264/x264-src
$ ./configure
Platform: X86
System: MINGW
asm: yes
avs input: avs
mp4 output: no
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no

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

Latest MinGW/GCC with pthreads included can be found here, for example:
http://www.xvidvideo.ru/2009-10-22-10-49-14/cat_view/28-cross-mingwgcc-x86x64/160-cross-mingwgcc-45-x86x64.html

(I guess you'd want that with "static" pthreads, so your x264.exe won't depends on the pthreads DLL)

Yes, my screen looks like that, except that I have mp4 support with 'yes'. That shouldn't affect my speeds, or lack thereoff though, I guess.

[LoRd_MuldeR]

Yes, my screen looks like that

Then you are set up correctly :)

except that I have mp4 support with 'yes'. That shouldn't affect my speeds, or lack thereoff though, I guess.

It only means you have GPAC installed (which I did not have) and thus your build will have MP4 output enabled.

However to squish out the optimal speed with GCC, you should use ./configure --extra-cflags="-march=<cpu>" and make fprofiled VIDS=foobar.avs

[Brazil2]

Bug or feature ?

I encode using --psy-rd=1:0.15 but when it's done MediaInfo reports psy_rd=1.0:0.2

So what is wrong ? Is x264 rounding the input value or is MediaInfo showing a rounded value ?
I'm quite sure that the correct value of 0.15 was shown with older builds of x264 like six months ago, maybe more.
if( p->analyse.b_psy )
s += sprintf( s, " psy_rd=%.1f:%.1f", p->analyse.f_psy_rd, p->analyse.f_psy_trellis );

:p
x264 rounds the values that get written to the file to one decimal, but the value used during encoding is not changed. AFAIK it's always been that way.
Probably because "psy_rd" was added to param2string() before the "film" tune started using Psy RDO 0.15 ^^

Lord Mulder, in this video (http://mulder.brhack.net/temp/100_5084.mkv) you have posted on the Avidemux' forums (http://avidemux.org/admForum/viewtopic.php?pid=40731#p40731), MediaInfo reports a value of 0.15 for Psy Trellis:
Writing library : x264 core 80 r1376M 3feaec2
Encoding settings : cabac=1 / ref=8 / deblock=1:-1:-1 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=1.00:0.15 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-3 / threads=6 / sliced_threads=0 / nr=0 / decimate=1 / mbaff=0 / constrained_intra=0 / bframes=16 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / wpredb=1 / wpredp=2 / keyint=750 / keyint_min=25 / scenecut=40 / rc_lookahead=60 / rc=crf / mbtree=1 / crf=20.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
Same goes with Avinaptic:
[ About H.264 encoding ]

User data: x264
User data: core 80 r1376M 3feaec2
User data: H.264/MPEG-4 AVC codec
...
User data: psy=1
User data: psy_rd=1.00:0.15

I've also found a video that I've encoded myself in October from a DVB capture with an older version of Avidemux using your libx264 build for Core2 which also reports 0.15:
Writing library : x264 core 75 r1259M dd026f2
Encoding settings : cabac=1 / ref=4 / deblock=1:-1:-1 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=1.00:0.15 / mixed_ref=1 / me_range=24 / 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=250 / keyint_min=25 / scenecut=40 / rc_lookahead=60 / rc=crf / mbtree=1 / crf=22.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00

So I'm not sure about what is happening there. Maybe you have removed the rounding part of the code from your builds (which I personally find a good idea) ?
Anyway I would like to see the real value used for the encoding, I still don't understand the reason why this specific value is rounded.

[LoRd_MuldeR]

Brazil2, I think you are reading those information from a stream that was encoded with my build of libx264 for Avidemux ;)

My builds include the following patch:
http://pastie.org/763983

(And no, it does not "remove" the rounding, because that would make the length of the string unpredictable. I simply increased the number of digits to 2)

[Brazil2]

Brazil2, I think you are reading those information from a stream that was encoded with my build of libx264 for Avidemux ;)
My video was encoded with Avidemux and one of your 'special' builds as I said.
But your own video (http://mulder.brhack.net/temp/100_5084.mkv) was not encoded with Avidemux and reports 0.15 for Psy Trellis.

[LoRd_MuldeR]

But your own video (http://mulder.brhack.net/temp/100_5084.mkv) was not encoded with Avidemux and reports 0.15 for Psy Trellis.

It was. Who said it wasn't encoded with Avidemux?

I only muxed the H.264 stream and the audio with AVI-Mux GUI, as Avidemux' MKV muxing capabilities aren't that reliable yet ;)

[Brazil2]

It was. Who said it wasn't encoded with Avidemux?
I'm saying it because since r5341 the encoding informations are not available anymore in H264 streams encoded with Avidemux as already reported here:
http://forum.doom9.org/showthread.php?p=1350354#post1350354
http://forum.doom9.org/showthread.php?p=1351866#post1351866

[LoRd_MuldeR]

They are! But apparently not in MP4 output (see the quote in this (http://forum.doom9.org/showthread.php?p=1350419#post1350419) post for details). In AVI output they are present for sure ;)

Also I think this Avidemux-specific discussion is getting off-topic here...

[Brazil2]

They are! But apparently not in MP4 output (see the quote in this (http://forum.doom9.org/showthread.php?p=1350419#post1350419) post for details). In AVI output they are present for sure ;)
Same goes for both MP4 and MKV output, see this post (http://forum.doom9.org/showthread.php?p=1351866#post1351866) about this issue.


Also I think this Avidemux-specific discussion is getting off-topic here...
My point is not Avidemux, my point is the real Psy Trellis value which was used for the encoding and which is sometimes correctly reported and sometimes not, and I'm just trying to understand why. And now I know that with your builds the real value is shown :)
And I still don't understand why it's not the default in x264 :p

[LoRd_MuldeR]

And I still don't understand why it's not the default in x264 :p

Because the x264 developers obviously have decided that printing out the Psy RDO/Trellis with a precision of one digit is sufficient.

The only reason why I increased the precision in my builds is because I wanted to checked whether my attempts to tweak the x264 defaults were successful ;)

And I will remove those tweaks as soon as Avidemux adds a GUI option to configure the Psy-Trellis at runtime...

[Brazil2]

Because the x264 developers obviously have decided that printing out the Psy RDO/Trellis with a precision of one digit is sufficient.
The question remains: why ?
Why is a 2 digits input allowed but only 1 digit reported ? There must be a reason, we don't do things without a reason, do we ?


The only reason why I increased the precision in my builds is because I wanted to checked whether my attempts to tweak the x264 defaults were successful ;)
And I will remove those tweaks as soon as Avidemux adds a GUI option to configure the Psy-Trellis at runtime...
Please don't remove this so usefull tweak!

[LoRd_MuldeR]

Why is a 2 digits input allowed but only 1 digit reported ?

It's a float, so it can have more than 2 digits. Actually the smallest value could be ∓1.401 * 10^(-45) ;)

So at some point you must cut off when printing out a float value...

Please don't remove this so usefull tweak!

If Avidemux allows to set Psy-Trellis at runtime, then there's no need (and thus no reason) to tweak x264's default Psy-Trellis value.

[rack04]

Test version for AutoVAQ v4 patch.

x264_x86_r1376M (http://www.filedump.net/dumped/x264x86r1376m1263221344.zip)

Toolchain:
gcc-core-4.4.2 (x86.core2.Komisar)
Patch:
x264_hrd_pd_interlace.16_r1369_fix.diff (http://komisar.gin.by/x.patch/last.used/x264_hrd_pd_interlace.16_r1369.diff)
x264_AQ_experiments_v4.diff (http://stashbox.org/751926/x264_AQ_experiments_v4.diff)
Build:
./configure --extra-cflags="-march=core2"
make fprofiled VIDS="/c/x264/crew_4cif.y4m /c/x264/parkrun.1280x720.yuv"

[aegisofrime]

A new version is out! Could I request a "amdfam10" build for the 64-bit version for us AMD users? Thanks!

[kemuri-_9]

since Jeeb is afk for a bit, I've made a generic x86_64 build:


Platform: X86_64
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no

ffmpeg r21217
ffms2 r257

x264_r1391_x64 (http://kemuri9.net/dev/x264/x264_r1391_x64.exe)

[bob0r]

Can you make it as:
http://kemuri9.net/dev/x264/revisionXXXX/x264.exe
http://kemuri9.net/dev/x264/revisionXXXX/x264.md5
?

Make x264.md5 as:
md5sum x264.exe | awk '{print $1}' >x264.md5

Then i can mirror it on x264.nl

Also can you x264.exe --version on that file so i know what GCC is used?

[kemuri-_9]

where as my previous x86_64 build was with gcc 4.4.2, I did one now with ICL...
due to ffmpeg not supporting ICL, requires a bit of windows DLL magic to have working ffms/lavf support for ICL x86_64.
x264_r1391_icl_x64.zip (http://kemuri9.net/dev/x264/x264_r1391_icl_x64.zip)

[aegisofrime]

where as my previous x86_64 build was with gcc 4.4.2, I did one now with ICL...
due to ffmpeg not supporting ICL, requires a bit of windows DLL magic to have working ffms/lavf support for ICL x86_64.
x264_r1391_icl_x64.zip (http://kemuri9.net/dev/x264/x264_r1391_icl_x64.zip)

Thank you for that. Any chance of an AMD optimized 64-bit build as well?

[imk]

Updated build of mine, as well...

r1391 built with Intel C++ Compiler v11.1.054

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

Edit:
I updated the build with LAVF/FFMS2 support, thanks to kemuri9.
I also added x264_hrd_pd_interlace.16_r1391.diff.

[Selur]

generic x86_32 build with hrd would be nice :)

Cu Selur

[rack04]

generic x86_32 build with hrd would be nice :)

Cu Selur

hrd needs an update to patch the latest git.

[Selur]

thanks for the info :) (fragged my x264/ffmpeg/mencoder-build machine a month or so ago and so I'm not up-to-date which patches work and don'T work atm. ;))

[VFR maniac]

x264_rev1391M_release2.rar (http://www.megaupload.com/?d=5P8FHFF0)

gcc: 4.4.2-dw2
pthreads: 2.9.0.0 (autostatic)
ffmpeg: rev21259 (--enable-pthreads)
libswscale: rev30341
ffms2: rev260
gpac: 2010-01-15 UTC
patch:
x264_hrd_pd_interlace.20_r1391.diff (http://pastebin.com/m76f87038) <--- I updated nal-hrd patch. However, there are no guarantee, and VFR + NAL HRD is not implemented in this version.
x264_tcfile_io_v4_r1391.diff (http://pastebin.com/m2b81af43)
x264_thread_pool_v2.5.diff (http://stashbox.org/740452/x264_thread_pool_v2.5.diff)
x264_fgo_r1369.diff (http://www.esnips.com/doc/9f6713d7-8733-4d9b-9ec1-dc952dca893f/x264_fgo_r1369)
x264_AQ_experiments_v4.diff (http://komisar.gin.by/test/x264_AQ_experiments_v4.diff)
$ ./configure --extra-cflags="-I/usr/local/include -march=core2 -fno-strict-aliasing" --extra-ldflags="-L/usr/local/lib"
Platform: X86
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no

My compilation guide is here (http://forum.doom9.org/showpost.php?p=1363644&postcount=86).

[julius666]

x264_fgo_r1369.diff (http://www.esnips.com/doc/9f6713d7-8733-4d9b-9ec1-dc952dca893f/x264_fgo_r1369)


Whoa, is this the old Film Grain Optimization? :eek:
How does it work? Does it work with Psy-RD now?

[rack04]

x264_x64_r1391M (http://www.mediafire.com/?0qoygbyytad)

x264_x86_r1391M (http://www.mediafire.com/?mmym4zeuqkl)

Toolchain:
gcc-core-4.4.2 (x86_64.core2.Komisar) (http://komisar.gin.by/mingw/index.html)
Patch:
patch -p1 < /c/x264/nal_hrd_patch_v1.0.diff
x64 Build:
./configure --extra-cflags="-march=core2" --host="x86_64-pc-mingw32" --cross-prefix="x86_64-pc-mingw32-"
Platform: X86_64
System: MINGW
asm: yes
avs input: yes
lavf input: no
ffms input: no
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
x86 Build:
./configure --extra-cflags="-march=core2"
Platform: X86
System: MINGW
asm: yes
avs input: yes
lavf input: no
ffms input: no
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
fprofiled:
make fprofiled VIDS="/c/x264/parkrun.1280x720.yuv"

[schweinsz]

a problem about encoding with x264.
C:\Downloads>x264_lavfffms2.exe --fps 24 --level 41 --bitrate 6000 --pass 2 --quiet --keyint 100 -
-b-pyramid strict --ref 5 --direct auto --me umh --chroma-qp-offset 2 --partitions all --merange 12
8 --cqm jvt --profile high -o video1_6mbps.264 tractor.yuv 1920x1080 1>dflsa.log
x264 [error]: x264_encoder_open failed
the tractor.yuv is 1.9G big.

[[ReX]]

where as my previous x86_64 build was with gcc 4.4.2, I did one now with ICL...
due to ffmpeg not supporting ICL, requires a bit of windows DLL magic to have working ffms/lavf support for ICL x86_64.
x264_r1391_icl_x64.zip (http://kemuri9.net/dev/x264/x264_r1391_icl_x64.zip)

I need to set any environment variables to make your Intel patch work?
I always get: "No working C compiler found." :confused:

[komisar]

[ReX], i'm trying to adapt icl compiler in to pseudo mingw environment to work as gcc or as msvc. in short - you must set almost all env-variables from windows environment in to mingw (in mingw notation). e.g CPATH=${ICPP_COMPILER11}/ipp/em64t/include:${ICPP_COMPILER11}/mkl/include
sufficient to set: ICPP_COMPILER11;VSINSTALLDIR;WindowsSdkDir;INTEL_LICENSE_FILE;CPATH;FPATH;IPPROOT;LIBPATH;LIBRARY_PATH;INCLUDE;LIB;PATH variables.

[imk]

kemuri let me in on a trick that works with cygwin at least. Start the ICL IA-32/Intel64 command prompt first, and then launch cygwin from that prompt. It will automatically pass over all environment settings. This might work with mingw, too.

[komisar]

imk, sure... but main goal is trying to porting/replace gcc options to icl. maybe some projects will builds in this pseudo-gcc... also this allow to build/link staic dependence of x264 (maybe other too)

[kemuri-_9]

kemuri let me in on a trick that works with cygwin at least. Start the ICL IA-32/Intel64 command prompt first, and then launch cygwin from that prompt. It will automatically pass over all environment settings. This might work with mingw, too.

yes, i do this for msys, which is where i picked up the trick.

imk, sure... but main goal is trying to porting/replace gcc options to icl. maybe some projects will builds in this pseudo-gcc... also this allow to build/link staic dependence of x264 (maybe other too)

the patch allows for building x264 with icl/icc as both static and shared.
as x264 already heavily requires a posix (or at least posix-like, e.g. msys) environment for compilation,
i continued with that as allowing icl compilation outside of a posix environment would likely involve msvc solutions and those are a true waste of space imo.

[komisar]

kemuri-_9, maybe you have trick to build ffmpeg/ffms2 library with icl in the msys environment? :)

[kemuri-_9]

kemuri-_9, maybe you have trick to build ffmpeg/ffms2 library with icl in the msys environment? :)

lol.
ffmpeg does not support compilation with ICL, the last time i tried (just a couple weeks ago), it resulted in large numbers of compilation failures revolving around the inline assembly.
this is something I'd rather not go diving into when not even x264 officially supports ICL.

ffms2 officially supports compilation with MSVC, and thus ICL as well.
this is relying on the fact that msvc can read the mingw libraries (i.e. it can read mingw compiled ffmpeg).
this works fine for x86; but it is near, if not completely, impossible to have the same occur for x86_64 as there's a few places where large incompatibilities occur.

the above is the reason why i went the DLL route to have a ICL x86_64 build with ffms/lavf support.

[burfadel]

Anybody seen this patch? dated 14 Jan 2010:
http://akuvian.org/src/x264/x264_plane_copy.diff

It would be interesting to see what difference it would make speed wise, combined with aq4 patch of course :)

[kemuri-_9]

Anybody seen this patch? dated 14 Jan 2010:
http://akuvian.org/src/x264/x264_plane_copy.diff

It would be interesting to see what difference it would make speed wise, combined with aq4 patch of course :)

there are a number of patches that are under benchmark testing, i can't remember what the status on this specific one is though.

[[ReX]]

[ReX], i'm trying to adapt icl compiler in to pseudo mingw environment to work as gcc or as msvc. in short - you must set almost all env-variables from windows environment in to mingw (in mingw notation). e.g CPATH=${ICPP_COMPILER11}/ipp/em64t/include:${ICPP_COMPILER11}/mkl/include
sufficient to set: ICPP_COMPILER11;VSINSTALLDIR;WindowsSdkDir;INTEL_LICENSE_FILE;CPATH;FPATH;IPPROOT;LIBPATH;LIBRARY_PATH;INCLUDE;LIB;PATH variables.

I'm not familiar with variables in msys, where should I set them?

kemuri let me in on a trick that works with cygwin at least. Start the ICL IA-32/Intel64 command prompt first, and then launch cygwin from that prompt. It will automatically pass over all environment settings. This might work with mingw, too.

I launched the Intel command prompt and launched msys.bat from it, still getting the same error. I'm using Windows 7.

[kemuri-_9]

;1365622']I launched the Intel command prompt and launched msys.bat from it, still getting the same error. I'm using Windows 7.

in this situation as the path setup is msys then icl,
you'll need to rename msys's link.exe to something else as it'll interfere with msvc's link.exe
after that you should have minimal issues.

you can also do
start msys.bat
or
\msys\bin\bash --login -i

as other options to get the environment going.

also do note that i've been debating back and forth between being inconsistent or consistent with mingw here, and for the time being i've chosen to be consistent.
so if you are using icl x86_64, you'll need to do
./configure --intel --host=x86_64-pc-mingw32 ...
to get it to configure correctly.
(setting the host flag is also required for x86_64 mingw, thus it is consistent)

[[ReX]]

in this situation as the path setup is msys then icl,
you'll need to rename msys's link.exe to something else as it'll interfere with msvc's link.exe
after that you should have minimal issues.

you can also do
start msys.bat
or
\msys\bin\bash --login -i

as other options to get the environment going.

also do note that i've been debating back and forth between being inconsistent or consistent with mingw here, and for the time being i've chosen to be consistent.
so if you are using icl x86_64, you'll need to do
./configure --intel --host=x86_64-pc-mingw32 ...
to get it to configure correctly.
(setting the host flag is also required for x86_64 mingw, thus it is consistent)

Thanks, it worked with start.
One last question, how can I set additional command line parameters for ICC (like /QxSSE4.1 /O3)?

[komisar]

[ReX], --extra-cflags="-QxSSE4.1 -O3"

[kemuri-_9]

[ReX], --extra-cflags="-QxSSE4.1 -O3"

yes, don't use / but - instead for indicating flags.
msvc and icl both support using - or /,
but using / interferes with the file system lookup and you'll get errors in this scenario.

if you need to add flags to link/xilink, that's done via --extra-ldflags="<stuff>"

[schweinsz]

Anybody seen this patch? dated 14 Jan 2010:
http://akuvian.org/src/x264/x264_plane_copy.diff

It would be interesting to see what difference it would make speed wise, combined with aq4 patch of course :)
Don't expect more on this patch, these functions in the diff are not critical time-comsuming functions.
But you can expect that I will improve the x264 on speed greatly after this march.

[Dark Shikari]

Don't expect more on this patch, these functions in the diff are not critical time-comsuming functions.
But you can expect that I will improve the x264 on speed greatly after this march.The function is quite important at fast speeds; it can eat up 6-10% of total time on Ultrafast and seems to have some very bizarre effects on caching, especially with multithreading.

[burfadel]

DS I read your blog after I wrote that, some very interesting stuff coming this year by the sounds of things!

[rack04]

x264_x86_r1400M (http://www.mediafire.com/?q2urywnnzdi)

Toolchain:
gcc-core-4.4.2 (x86.core2.Komisar) (http://komisar.gin.by/mingw/index.html)
Patch:
patch -p1 < /c/x264/nal_hrd_patch_v1.0.diff
patch -p1 < /c/x264/x264_AQ_experiments_v4.diff
Build:
./configure --extra-cflags="-march=core2"
Platform: X86
System: MINGW
asm: yes
avs input: yes
lavf input: no
ffms input: no
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
fprofiled:
make fprofiled VIDS="/c/x264/parkrun.1280x720.yuv"

[juGGaKNot]

x264_x86_r1400M

x264 --fullhelp >> aa.txt crashes at : --rc-lookahead 60 --ref 16

Makes the text file, 4kb, crashes at that line.

From x264.nl works fine.

[kemuri-_9]

gcc 4.4.3 released, those using 4.4.2 should update (when able).

[VFR maniac]

x264_rev1400M_release2.rar (http://www.megaupload.com/?d=GJ8L8Z6J)

gcc: 4.4.3-dwarf2
pthreads: 2.9.0.0 (autostatic)
ffmpeg: rev21414 (--enable-pthreads)
libswscale: rev30417
ffms2: rev263
gpac: 2010-01-23 UTC
patch:
x264_hrd_pd_interlace.20_r1391.diff (http://pastebin.com/m76f87038)
x264_tcfile_io_v4_r1391.diff (http://pastebin.com/m2b81af43)
x264_thread_pool_v2.5.diff (http://stashbox.org/740452/x264_thread_pool_v2.5.diff)
x264_fgo_r1369.diff (http://www.esnips.com/doc/9f6713d7-8733-4d9b-9ec1-dc952dca893f/x264_fgo_r1369)
x264_AQ_experiments_v4.diff (http://komisar.gin.by/test/x264_AQ_experiments_v4.diff)
$ ./configure --extra-cflags="-I/usr/local/include -march=core2 -fno-strict-aliasing" --extra-ldflags="-L/usr/local/lib"
Platform: X86
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no

My lavf/ffms compilation guide on MSYS/MinGW32 is here (http://forum.doom9.org/showpost.php?p=1363644&postcount=86).

[bob0r]

pthreads: 2.9.0.0 (autostatic)
gpac: 2010-01-23 UTC

Where do you get those "versions" from?

[VFR maniac]

The latest CVS.
I don't pay attention to their accurate versions.

[burfadel]

ffms2: rev262

Is it possible to get that and later revisions when available from somewhere?

[bob0r]

ffms2: rev262

Is it possible to get that and later revisions when available from somewhere?


svn checkout svn://svn.ffmpeg.org/ffmpeg/trunk ffmpeg
configure --enable-gpl --enable-postproc --enable-memalign-hack --cpu=i686 --disable-devices --disable-filters --enable-runtime-cpudetect --disable-encoders --disable-muxers --disable-network --disable-decoder=aac,ac3,adpcm_*,alac,als,ape,atrac?,cook,dca,dsicinaudio,dxa,eac3,flac,interplay_dpcm,mlp,mp1,mp2,mp3,mp3*,mpc?,pcm_*,qcelp,ra_*,sipr,truehd,truespeech,tta,vorbis,wavpack,wma*,twinvq --disable-demuxer=aac,ac3,pcm_*,ape,amr,ass,au,avs,dts,eac3,flac,mp3,mpc,mpc8,truehd,tta,w64,wav,wv --disable-parser=aac,ac3,dca,mlp,mpegaudio
make
make install


ffmpegsource tested with revision: 21414


svn checkout http://ffmpegsource.googlecode.com/svn/trunk/ ffmpegsource
copy/overwrite: http://x264.nl/CMakeLists.txt to ffmpegsource/
cmake -G "MSYS Makefiles"
make
cp libFFMS2.a /usr/local/lib/
cp include/ffms.h /usr/local/include/


ffmpegsource tested with revision: 263

[VFR maniac]

ffms2: rev262

Is it possible to get that and later revisions when available from somewhere?

You cannot get the latest ffms2.dll somewhere at present.
You can get the latest ffms2.dll by making yourself it.

[techouse]

x264_x86_r1400_QxSSSE3_vanilla_icc_techouse (http://techouse.project357.com/builds/vanilla/x86/x264_x86_r1400_QxSSSE3_vanilla_icc_techouse.7z)
Intel C++ Compiler 11.1.054, almost unpatched, -QxSSSE3 -O3, fprofiled

x264_x86_r1400_generic_vanilla_icc_techouse (http://techouse.project357.com/builds/vanilla/x86/x264_x86_r1400_generic_vanilla_icc_techouse.7z)
Intel C++ Compiler 11.1.054, almost unpatched, -O3, fprofiled

x264_x64_r1400_QxSSSE3_vanilla_icc_techouse (http://techouse.project357.com/builds/vanilla/x64/x264_x64_r1400_QxSSSE3_vanilla_icc_techouse.7z)
Intel C++ Compiler 11.1.054, almost unpatched, -QxSSSE3 -O3, fprofiled

x264_x64_r1400_generic_vanilla_icc_techouse (http://techouse.project357.com/builds/vanilla/x64/x264_x64_r1400_generic_vanilla_icc_techouse.7z)
Intel C++ Compiler 11.1.054, almost unpatched, -O3, fprofiled

Patches used:

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

---------------------------------------------------------

x264_x86_r1400_QxSSSE3_icc_techouse (http://techouse.project357.com/builds/x86/x264_x86_r1400_QxSSSE3_icc_techouse.7z) | INFO (http://techouse.project357.com/nfo/x86/x264_x86_r1400_QxSSSE3_icc_techouse.txt)
Intel C++ Compiler 11.1.054, -QxSSSE3 -O3, fprofiled

x264_x86_r1400_generic_icc_techouse (http://techouse.project357.com/builds/x86/x264_x86_r1400_generic_icc_techouse.7z) | INFO (http://techouse.project357.com/nfo/x86/x264_x86_r1400_generic_icc_techouse.txt)
Intel C++ Compiler 11.1.054, -O3, fprofiled

x264_x64_r1400_QxSSSE3_icc_techouse (http://techouse.project357.com/builds/x64/x264_x64_r1400_QxSSSE3_icc_techouse.7z) | INFO (http://techouse.project357.com/nfo/x64/x264_x64_r1400_QxSSSE3_icc_techouse.txt)
Intel C++ Compiler 11.1.054, -QxSSSE3 -O3, fprofiled

x264_x64_r1400_generic_icc_techouse (http://techouse.project357.com/builds/x64/x264_x64_r1400_generic_icc_techouse.7z) | INFO (http://techouse.project357.com/nfo/x64/x264_x64_r1400_generic_icc_techouse.txt)
Intel C++ Compiler 11.1.054, -O3, fprofiled

Patches used:

x264_intel_support.diff (http://kemuri9.net/dev/x264/patches/x264_intel_support.diff)
x264_NAL_HRD.10b.diff (http://komisar.gin.by/x.patch/last.used/x264_NAL_HRD.10b.diff)





QxSSSE3 = for Intel Core 2 and newer Intel processor (http://en.wikipedia.org/wiki/SSSE3)
generic = for Intel Core, Intel Pentium 4, Intel Pentium III and AMD processors

[rack04]

x264_x86_r1400M (http://www.mediafire.com/?muuijufzjcv)

Toolchain:
gcc-core-4.4.3 (x86.core2.Komisar) (http://komisar.gin.by/mingw/index.html)
Patch:
x264_hrd_pd_interlace.20_r1391 (http://pastebin.com/m76f87038)
x264_AQ_experiments_v4 (http://komisar.gin.by/test/x264_AQ_experiments_v4.diff)
Build:
march=core2
Platform: X86
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
make fprofiled
LAVF/FFMS input:
ffmpeg (http://kemuri9.net/dev/x264/other/ffmpeg.zip)
ffms2 (http://kemuri9.net/dev/x264/other/ffms2.zip)

[kemuri-_9]

LAVF/FFMS input:
ffmpeg (http://kemuri9.net/dev/x264/other/ffmpeg.zip)
ffms2 (http://kemuri9.net/dev/x264/other/ffms2.zip)

woah, i had totally forgotten i had those there...
they're outdated now, so it would be better if you compiled your own versions and used that instead.

[rack04]

woah, i had totally forgotten i had those there...
they're outdated now, so it would be better if you compiled your own versions and used that instead.

Very well. Thanks.

EDIT: When I try to compile ffmpeg using the following:

cd /c/x264/
git clone git://git.ffmpeg.org/ffmpeg/ ffmpeg-src
cd /c/x264/ffmpeg-src/
./configure --enable-gpl --enable-postproc --enable-memalign-hack --enable-runtime-cpudetect --disable-devices --disable-filters --disable-encoders --disable-muxers --disable-network --disable-decoder=aac,ac3,adpcm_*,alac,als,ape,atrac?,cook,dca,dsicinaudio,dxa,eac3,flac,interplay_dpcm,mlp,mp1,mp2,mp3,mp3*,mpc?,pcm_*,qcelp,ra_*,sipr,truehd,truespeech,tta,vorbis,wavpack,wma*,twinvq --disable-demuxer=aac,ac3,pcm_*,ape,amr,ass,au,avs,dts,eac3,flac,mp3,mpc,mpc8,truehd,tta,w64,wav,wv --disable-parser=aac,ac3,dca,mlp,mpegaudio


I get numerous "line 250: pr: command not found" and "line 2791: pr: command not found". Am I missing something?

[kemuri-_9]

missing the pr command which ffmpeg configure uses.

it's part of the msys coreutils ext package: http://sourceforge.net/projects/mingw/files/MSYS%20coreutils/coreutils-5.97-2/coreutils-5.97-2-msys-1.0.11-ext.tar.lzma/download

[rack04]

x264_x86_r1400M (http://www.filedump.net/dumped/x264x86r1400m1264450195.zip)

Toolchain:
gcc-core-4.4.3 (x86.core2.Komisar) (http://komisar.gin.by/mingw/index.html)
Patch:
x264_hrd_pd_interlace.20_r1391 (http://pastebin.com/m76f87038)
x264_AQ_experiments_v4 (http://komisar.gin.by/test/x264_AQ_experiments_v4.diff)
Build:
march=core2
Platform: X86
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
make fprofiled
LAVF/FFMS input:
ffmpeg r21450 (http://www.mediafire.com/?0jlzyzy0yio)
ffms2 r263 (http://www.mediafire.com/?ywyjed1nfmm)

[rack04]

svn checkout http://ffmpegsource.googlecode.com/svn/trunk/ ffmpegsource-src

For some reason when I try to download the latest ffms source is doesn't contain CMakeLists.txt. Has anyone else noticed this?

[kemuri-_9]

svn checkout http://ffmpegsource.googlecode.com/svn/trunk/ ffmpegsource-src

For some reason when I try to download the latest ffms source is doesn't contain CMakeLists.txt. Has anyone else noticed this?

the build system just flipped from cmake to a configure-based system (e.g. ./configure [opts])

that would be why the cmake stuff no longer exists

[bob0r]

For mingw/msys:
http://ftp.gnome.org/pub/gnome/binaries/win32/dependencies/pkg-config_0.23-3_win32.zip
copied: bin/pkg-config.exe to /local/bin/
http://ftp.gnome.org/pub/gnome/binaries/win32/glib/2.22/glib_2.22.3-1_win32.zip
copied: bin/libgio-2.0-0.dll, libglib-2.0-0.dll, libgmodule-2.0-0.dll, libgobject-2.0-0.dll, libgthread-2.0-0.dll to /local/bin/
(probably only libglib-2.0-0.dll needed)

But i get this now:


$ make
Making all in src
Making all in core
CXX audiosource.o
CXX ffms.o
CXX haaliaudio.o
CXX haaliindexer.o
CXX haalivideo.o
CXX indexing.o
CXX lavfaudio.o
CXX lavfindexer.o
CXX lavfvideo.o
CXX matroskaaudio.o
CXX matroskaindexer.o
CC matroskaparser.o
CXX matroskavideo.o
CC stdiostream.o
CXX utils.o
CXX videosource.o
CXX wave64writer.o
LINK libffms2.la
libtool: link: warning: undefined symbols not allowed in i686-pc-mingw32 shared libraries
Making all in index
CXX ffmsindex.o
LINK ffmsindex.exe
ffmsindex.o: In function `main':
F:\msys\1.0\home\xuser\ffmpegsource\src\index/ffmsindex.cpp:244: undefined reference to `CoInitializeEx@8'
F:\msys\1.0\home\xuser\ffmpegsource\src\index/ffmsindex.cpp:278: undefined reference to `CoUninitialize@0'
collect2: ld returned 1 exit status
make[2]: *** [ffmsindex.exe] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1


With cmade it did work, any idea?

Edit: It now works, just:

svn checkout http://ffmpegsource.googlecode.com/svn/trunk/ ffmpegsource
configure
make
make install

Note:
My previous cmake libFFMS2.a: 762 KB (781,302 bytes)
My make libffms2.a: 1.90 MB (2,001,826 bytes)

[Kovensky]

Note:
My previous cmake libFFMS2.a: 762 KB (781,302 bytes)
My make libffms2.a: 1.90 MB (2,001,826 bytes)
configure it with CFLAGS=-O2 CXXFLAGS=-O2 ./configure, or just svn up since they no longer have -g by default.

[rack04]

Nevermind. I got it to work.

[roozhou]

Could someone provide a compiled libffms2.a?

[kemuri-_9]

Could someone provide a compiled libffms2.a?

here's the ffms2 portion of what i use for compiling x264 in both mingw and icl with ffms2 support
ffms2_x86+x64.zip (http://kemuri9.net/dev/avs/ffms2/ffms2_x86+x64.zip)

[rack04]

here's the ffms2 portion of what i use for compiling x264 in both mingw and icl with ffms2 support
ffms2_x86+x64.zip (http://kemuri9.net/dev/avs/ffms2/ffms2_x86+x64.zip)

How did you build x64 using mingw?

[kemuri-_9]

How did you build x64 using mingw?

the same way i did the x86 mingw version except using the x64 compiler?
not really seeing what you're asking...

[rack04]

the same way i did the x86 mingw version except using the x64 compiler?
not really seeing what you're asking...

Sorry. What I meant was what ./configure [opts] to enable x64.

[burfadel]

Kemuri, that ffms2 doesn't want to work in Staxrip... With the version that came with Staxrip works fine, replace the ffms2.dll and ffmsindex.exe, and it says there's no function named ''FFVideoSource".

I tried the filed from the x86 and x64 folder, in case they were around the wrong way (which I highly doubted), no luck.

[rack04]

x264_x86_r1400M (http://www.mediafire.com/?tlentmcfyj2)

Toolchain:
gcc-core-4.4.3 (x86.core2.Komisar) (http://komisar.gin.by/mingw/index.html)
Patch:
nal_hrd_patch_v1.1 (http://pastebin.com/d51413f02)
x264_AQ_experiments_v4 (http://komisar.gin.by/test/x264_AQ_experiments_v4.diff)
Build:
--extra-cflags="-march=core2"
Platform: X86
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
make fprofiled
LAVF/FFMS input (http://www.mediafire.com/?citmegimzxa)
ffmpeg rev21463
libswscale r30437
ffms2 r269

[burfadel]

Is ffms2.dll needed for x264.exe? Just asking as its missing from that LAVF/FFMS input archive, and Kemuri's link earlier had a ffms2.dll that didn't work with avisynth.

Also, why is the ffmsindex.exe 17MB?! especially since ffmpeg.exe is smaller than others (4mb vs ~10mb)

[LoRd_MuldeR]

Is ffms2.dll needed for x264.exe? Just asking as its missing from that LAVF/FFMS input archive, and Kemuri's link earlier had a ffms2.dll that didn't work with avisynth...

Depends. If x264 was linked against the static lib, then you don't need the DLL. If it was linked against the dynamic lib, then the DLL is needed at runtime.

If in doubt, you can always check the dependencies of an executable with the good old Dependency Walker (http://dependencywalker.com/) utility ;)

[kemuri-_9]

Kemuri, that ffms2 doesn't want to work in Staxrip... With the version that came with Staxrip works fine, replace the ffms2.dll and ffmsindex.exe, and it says there's no function named ''FFVideoSource".

I tried the filed from the x86 and x64 folder, in case they were around the wrong way (which I highly doubted), no luck.

my dlls are avisynth plugins and they are "not" at the same time.
they use the avisynth C interface as this is required by plugins compiled within MinGW as they cannot use the C++ interface due to some incompatibility issues with avisynth being compiled in MSVC.
the C interface is rather non-standard (afaik yadif is the only other plugin that uses the C interface)
i've programmed them to where LoadPlugin("ffms2.dll") returns "use LoadCPlugin", allowing

( LoadPlugin("ffms2.dll") == "Use LoadCPlugin" ) ? LoadCPlugin("ffms2.dll") : NOP()

to load the dlls without interfering with the official builds which are compiled with MSVC and use the C++ interface.

Is ffms2.dll needed for x264.exe? Just asking as its missing from that LAVF/FFMS input archive, and Kemuri's link earlier had a ffms2.dll that didn't work with avisynth.

referring to my own goods,
A) if you used libffms2.a: no
B) if you used libffms2.dll.a: yes
C) if you created a MSVC/ICL import lib using the .def and linked against that: yes

Sorry. What I meant was what ./configure [opts] to enable x64.
sorry, not using the official build system, so couldn't tell you how to do it in it.

[burfadel]

I tried the Loadcplugin method and it didn't work! oh well, just hope the time between easy to work with ffms.dll's isn't too long! (as I'm sure others would agree).

Automated builds like available here for ffmpeg:
http://ffmpeg.arrozcru.org/autobuilds/

Would be very handy! :) but I realise thats just wishful thinking :D

[kemuri-_9]

I tried the Loadcplugin method and it didn't work! oh well, just hope the time between easy to work with ffms.dll's isn't too long! (as I'm sure others would agree).

it would help if you actually stated HOW it didn't work. it seems like people think i have telepathy :/

[burfadel]

I found out why it wasn't working! The problem lies with how staxrip loads the filters. Staxrip automatically adds the loadplugin line above the avisynth script, it doesn't actually show in the programme. When adding Loadcplugin inside the programme itself, it is after the loadplugin command is given. Loadcplugin doesn't work after the plugin is already loaded with loadplugin.

I don't know how to rectify that with Staxrip, using v1.1.4.3

[magnatique]

I am having a strange bug. I used to encode with an older build I had taken with nal-hrd to have Blu-ray compliant files without problem... But I seem to not be able to encode source files larger than 40GB or more right now. I downloaded a few different latest builds without luck.

it goes and starts, but crashes after 20-70 frames. I get similar probs on qtinput of large 40gb prores sources... I just launched from same source avs a encode from megui with default crf16 ultra-fast +fastdecode settings and it seems to be going good...

anyone got some input on how to modify my command to stop crashes while preserving fast fast decoding, bluray compliant?

"C:\Program Files\megui\tools\x264\x264-new.exe" --profile high --level 4.1 --preset fast --tune fastdecode --crf 16.0 --thread-input --deblock -1:-1 --keyint 30 --min-keyint 2 --b-adapt 2 --direct auto --ipratio 1.1 --pbratio 1.1 --vbv-bufsize 30000 --vbv-maxrate 40000 --no-mbtree --merange 12 --subme 2 --partitions all --trellis 0 --mvrange 511 --nal-hrd --sar 1:1 --aud --slices 4 --output "v:\encoded\tt030_jeremysommers_patrickkennedy.mp4" "c:\users\encode\Desktop\mp4-run\lagatomp4\tt030_jeremysommers_patrickkennedy.avs"

[roozhou]

@kemuri-_9
Help! How can I link to your libffms2.a using MSVC?

I added libffms2.a to additional dependencies and the linker complains:
unresolved external symbol _FFMS_GetVideoProperties@4 (and more)

Then I changed the line in ffms.h
# define FFMS_CC __stdcall -> # define FFMS_CC __cdecl
This time the linker complains:
module machine type 'x64' conflicts with target machine type 'X86'

[kemuri-_9]

@kemuri-_9
Help! How can I link to your libffms2.a using MSVC?

I added libffms2.a to additional dependencies and the linker complains:
unresolved external symbol _FFMS_GetVideoProperties@4 (and more)

you are using the x86 library with trying to compile a x86 version of x264 with msvc right?

and shouldn't you just compile a static lib version with msvc as ffms already has some slns for msvc?
think you'd only need to change the project type to static lib and drop all the linker comments in libs.cpp...
wrapping the linker statements in

#ifdef _DLL
....
#endif

should work fine for doing that.


Then I changed the line in ffms.h
# define FFMS_CC __stdcall -> # define FFMS_CC __cdecl
This time the linker complains:
module machine type 'x64' conflicts with target machine type 'X86'

do not do this, simply changing the calling convention in the header declaration without recompiling will cause the program to seg fault on using any of the functions due to corrupting the stack.

[roozhou]

you are using the x86 library with trying to compile a x86 version of x264 with msvc right?

Yes, it links OK using GCC.


and shouldn't you just compile a static lib version with msvc as ffms already has some slns for msvc?
think you'd only need to change the project type to static lib and drop all the linker comments in libs.cpp...
wrapping the linker statements in

#ifdef _DLL
....
#endif

should work fine for doing that.

No, it didn't compile.

I changed project type to .lib and added ffmpeg's folder to the include directories. The compiler complained about inttypes.h and stdint.h, so i copied them from x264. Unfortunately the compiler still failed in ffms.h.

Since MSVC can link to libav*.a and libx264.a compiled by gcc, I wonder why it fails with libffms2.a compiled by g++.


do not do this, simply changing the calling convention in the header declaration without recompiling will cause the program to seg fault on using any of the functions due to corrupting the stack.
Does g++ and MSVC use different name mangling?

[kemuri-_9]

Yes, it links OK using GCC.
No, it didn't compile.
I changed project type to .lib and added ffmpeg's folder to the include directories. The compiler complained about inttypes.h and stdint.h, so i copied them from x264. Unfortunately the compiler still failed in ffms.h.

whine at the FFmpegSource thread to get them to add a static solution that'll work then, since only TheFluff and Myrsloik deal with the msvc stuff.

oh right ffms.h automatically adds declspec decorations to the API when compiled within msvc...

you'll need to change line 39 in ffms.h from

# ifdef _MSC_VER

to
something else that would allow static linking... like

# if defined(_MSC_VER) && !defined(FFMS_STATIC_LIB)

defining FFMS_STATIC_LIB in the project settings and also when including ffms.h within x264
or something along these lines


Since MSVC can link to libav*.a and libx264.a compiled by gcc, I wonder why it fails with libffms2.a compiled by g++.

Does g++ and MSVC use different name mangling?

yes they do have different name mangling for C++ functions,
but those functions are included too so they should resolve ok....

for C functions they are the same only for x86.

[rack04]

x264_x86_r1400M (http://www.mediafire.com/?oymawijmjij)

Toolchain:
gcc-core-4.4.3 (x86.core2.Komisar) (http://komisar.gin.by/mingw/index.html)
Patch:
nal_hrd_patch_v1.1 (http://pastebin.com/d51413f02)
x264_AQ_experiments_v4 (http://komisar.gin.by/test/x264_AQ_experiments_v4.diff)
Build:
march=core2
Platform: X86
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
make fprofiled
LAVF/FFMS input:
ffmpeg rev21518 (http://www.mediafire.com/?x33amjmz3wi)
ffms2 r272 (http://www.mediafire.com/?m0nljd1j1nz)

[burfadel]

Rack04, any chance of ffms2 builds that include ffms2.dll that can be used with Staxrip/Avisynth? :)

[rack04]

Rack04, any chance of ffms2 builds that include ffms2.dll that can be used with Staxrip/Avisynth? :)

Nope.

[Boulder]

Is it possible to get any extra information from x264 crashing? I've been getting very random unhandled win32 exception crashes with techouse's unpatched x264 ICC build r1400 (QxSSSE3 used).

[LoRd_MuldeR]

Is it possible to get any extra information from x264 crashing? I've been getting very random unhandled win32 exception crashes with techouse's unpatched x264 ICC build r1400 (QxSSSE3 used).

Use a debug build, run it inside a debugger (most likely GDB) and make a backtrace as soon as it crashes...

[kemuri-_9]

Use a debug build, run it inside a debugger (most likely GDB) and make a backtrace as soon as it crashes...

the ICL builds use the MSVC debug format which is a different debug format from that of MinGW's that can not be used within GDB.
you'll need MSVC to work with debug MSVC builds.

[Boulder]

I just had a crash encoding Shrek..I wrote the last frame number down and now I'll see whether the crash occurs at the same point. If that happens, I guess I'll have to start working on the problem. I do not know how to create a debug build (or any build to be exact) so I'll have to ask techouse then. I take that the free version of MSVC is enough?

[kemuri-_9]

I just had a crash encoding Shrek..I wrote the last frame number down and now I'll see whether the crash occurs at the same point. If that happens, I guess I'll have to start working on the problem. I do not know how to create a debug build (or any build to be exact) so I'll have to ask techouse then. I take that the free version of MSVC is enough?

not familiar enough with the various feature sets m$ likes to fling around with the free versions so i imagine it would be enough, but only using it will tell.

[masterkivat]

Sorry for being annoying, but could someone patch the newest build (r1416*) with the new AQ Experimental? I don't care being x86 or x64 :)

[julius666]

Sorry for being annoying, but could someone patch the newest build (r1416*) with the new AQ Experimental? I don't care being x86 or x64 :)

http://forum.doom9.org/showpost.php?p=1369594&postcount=153

[masterkivat]

http://forum.doom9.org/showpost.php?p=1369594&postcount=153

:thanks:
*Gonna pay more atention at the main thread of the AQ* :p

[VFR maniac]

x264_rev1416M_release1.rar (http://www.megaupload.com/?d=HI7K4F4H)

gcc: 4.4.3-dwarf2
pthreads: 2.9.0.0 (autostatic)
ffmpeg: rev21565 (--enable-pthreads)
libswscale: rev30472
ffms2: rev275
gpac: 2010-01-23 UTC
patch:
x264_hrd_pd_interlace.21_r1416.diff (http://www.esnips.com/doc/a4a9a4d4-d189-4f7c-85a2-a6fa3c27065e/x264_hrd_pd_interlace.21_r1416)
x264_tcfile_io_v5_r1416.diff (http://www.esnips.com/doc/ddbe32d3-0f20-4a00-aaa9-9294e19fd6af/x264_tcfile_io_v5_r1416)
x264_thread_pool_v2.6_r1416.diff (http://www.esnips.com/doc/1942dbf8-1de3-423e-9fcd-fae570b92e70/x264_thread_pool_v2.6_r1416)
x264_fgo_r1416.diff (http://www.esnips.com/doc/e7194de8-1303-47de-8eb1-d83905b41148/x264_fgo_r1416)
x264_AQ_experiments_v4.diff (http://komisar.gin.by/test/x264_AQ_experiments_v4.diff)
$ ./configure --extra-cflags="-I/usr/local/include -march=core2 -fno-strict-aliasing" --extra-ldflags="-L/usr/local/lib"
Platform: X86
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no

[bob0r]

On my Intel Q6600 -march=core2 is slower than now using it.
Tested with GCC 4.4.3 32bit.

[Boulder]

not familiar enough with the various feature sets m$ likes to fling around with the free versions so i imagine it would be enough, but only using it will tell.I got a crash once again, not at the same frame though. The pop-up window told me that I could try debugging it via Visual Studio's just-in-time debugger so I'm going to download the Express Edition of MSVC++ 2008 and see if I can make it work.

[Dark Shikari]

I got a crash once again, not at the same frame though. The pop-up window told me that I could try debugging it via Visual Studio's just-in-time debugger so I'm going to download the Express Edition of MSVC++ 2008 and see if I can make it work.That's rather useless without debug symbols, and even more useless given that MSVC doesn't use the same debug symbol format as GCC...

[kemuri-_9]

That's rather useless without debug symbols, and even more useless given that MSVC doesn't use the same debug symbol format as GCC...

yes, it's a pita world and even more pita since people are all 'oh compiling with SSSE3 will make it go light-speed'
when all it does is prevent me and my AMD brethren from being able to use the build for negligible speedup. (huzzah placebo effect?)

either way here's an ICL -QxSSSE3 build of r1416 with the PDB (http://kemuri9.net/dev/x264/x264_r1416_icl_ssse3_debug.zip) so you can get debug info out of it with msvc.
skipped out on the ffms/lavf input so i wouldn't have to include ffms2.dll.
do note: i can't run this thing, so i will not be able to help you use it.

[Boulder]

yes, it's a pita world and even more pita since people are all 'oh compiling with SSSE3 will make it go light-speed'
when all it does is prevent me and my AMD brethren from being able to use the build for negligible speedup. (huzzah placebo effect?)

either way here's an ICL -QxSSSE3 build of r1416 with the PDB (http://kemuri9.net/dev/x264/x264_r1416_icl_ssse3_debug.zip) so you can get debug info out of it with msvc.
skipped out on the ffms/lavf input so i wouldn't have to include ffms2.dll.
do note: i can't run this thing, so i will not be able to help you use it.I don't know about a placebo effect, I did some testing recently and found out that the ICL builds were 2-3% faster compared to the vanilla build from x264.nl. It's not a lot but still ;)

Thank you, I'll try your build and see what happens. I'll be on a working trip next week so it might take a while.

[kemuri-_9]

I don't know about a placebo effect, I did some testing recently and found out that the ICL builds were 2-3% faster compared to the vanilla build from x264.nl. It's not a lot but still ;)

yes, the ICL builds are faster, but that's because it's ICL instead of GCC.
ICL w/ QxSSSE3 over ICL w/ SSE default is placebo effect.
it's the same situation for GCC w/ -march=core2 over GCC w/ march=i686.

[Boulder]

I wonder why practically no one uses the Qax then, isn't that supposed to create a multi-platform compatible build?

[tormento]

A 1416_x64 ICL build, please ;)

[burfadel]

Intel compiler made programmes are made specfically to run slower on AMD. It was taken to court and AMD I won recently I believe.

[kemuri-_9]

A 1416_x64 ICL build, please ;)

x264_r1416_set.zip (http://kemuri9.net/dev/x264/x264_r1416_set.zip)

Intel compiler made programmes are made specfically to run slower on AMD. It was taken to court and AMD I won recently I believe.

from my AMD laptop (single core):

>x264_gcc --preset ultrafast -o NUL "E:\random\op.mpg" --frames 1000
encoded 1000 frames, 40.30 fps, 3253.98 kb/s

>x264_icl --preset ultrafast -o NUL "E:\random\op.mpg" --frames 1000
encoded 1000 frames, 41.40 fps, 3253.98 kb/s

so even if the intel compiler still biases against AMD, it's still faster than GCC.

[aegisofrime]

Funny, I did a test myself of ICL vs GCC and GCC came out 2 or 3 FPS faster. Then again my preset was "Slower" Maybe I will try it again with "Ultrafast".

I heard about the ICL being biased against AMD, and in fact it's one of the things the FCC (or some other American government agency) is forcing Intel to clean up its act on.

[rack04]

x264_x86_r1416M (http://www.mediafire.com/?ng0wfohnzjd)

Toolchain:
gcc-core-4.4.3 (x86.core2.Komisar) (http://komisar.gin.by/mingw/index.html)
Patch:
x264_AQ_experiments_v4 (http://komisar.gin.by/test/x264_AQ_experiments_v4.diff)
Build:
./configure --extra-cflags="-march=core2"
Platform: X86
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
make fprofiled VIDS="/c/x264/parkrun.1280x720.yuv"
LAVF/FFMS input:
ffmpeg rev21593 and libswscale rev30480 (http://www.mediafire.com/?hm4zf0jymmd)
ffms2 r275 (http://www.mediafire.com/?uhdmzvt3wry)

[outlaw.78]

Here is a AMD optimized 64bit version

http://www.mediafire.com/file/dmwgwotg04n/x264-0.84.1416-amdfam10-x86_64.7z

gcc 4.5.0 20100129 (experimental)
ffmpeg svn 21594
ffms2 svn 275
pthreads 2.9.0.0 shared
x264 0.84.1416 x86_64,amdfam10,fprofiled

[tormento]

x264_r1416_set.zip (http://kemuri9.net/dev/x264/x264_r1416_set.zip)
Strange enough, your version works perfectly when muxing the video to mkv but fails when tsmuxing to m2ts. The player sees the audio track only. Other x64 compiles (komisar) work ok.

[rack04]

x264_x86__core2_r1416M (http://www.mediafire.com/?rzgn3uelmzh)
x264_x86_generic_r1416M (http://www.mediafire.com/?k34zytnonjz)

Toolchain:
gcc-core-4.4.3 (x86.core2.Komisar) (http://komisar.gin.by/mingw/index.html)
Patch:
nal_hrd_patch_v1.22_fix (http://www.mediafire.com/file/imdmvtyngyz/nal-hrd1.22_fix.diff)
x264_AQ_experiments_v4 (http://komisar.gin.by/test/x264_AQ_experiments_v4.diff)
Build:
./configure --extra-cflags="-march=core2" (core2)
./configure --extra-cflags="-march=i686" (generic)
Platform: X86
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
make fprofiled
LAVF/FFMS input:
ffmpeg rev21634 and libswscale rev30501 (http://www.mediafire.com/?4ut2m1zzzzz)
ffms2 r278 (http://www.mediafire.com/?m2zjzywmzmd)

[Boulder]

either way here's an ICL -QxSSSE3 build of r1416 with the PDB (http://kemuri9.net/dev/x264/x264_r1416_icl_ssse3_debug.zip) so you can get debug info out of it with msvc.
skipped out on the ffms/lavf input so i wouldn't have to include ffms2.dll.
do note: i can't run this thing, so i will not be able to help you use it.

I got this one to crash and caught the exception in MSVC2008. It shows "stack frame" as avisynth.dll, is it possible that the crash is actually due to Avisynth? How should I proceed next, I saved a minidump but is there more to do? The address at breakpoint is 00AD2BE0 and the command shown on the line is "mov ax,word ptr [ecx]". In the output it says "0xC0000005 : Access violation reading location 0x000677c0."

[rabbitiswise]

Intel compiler made programmes are made specfically to run slower on AMD. It was taken to court and AMD I won recently I believe.
Of course Intel's compiler will schedule instructions for Intel CPUs, but the specific complaint has to do with auto CPU dispatch (eg. Qax) and library functions, such as standard math functions like pow(), sin(), etc. The generated code and library functions check flags to see if it's an SSE, SSE2, etc. capable CPU, and will use specific routines depending on those flags. However, when SSE/SSE2 is determined for the flags var, it only looks for "GenuineIntel" CPUs, which means it rejects "AuthenticAMD".

But you can hack it by doing something early in startup like:

#ifdef __INTEL_COMPILER
extern "C" void __intel_cpu_indicator_init(void);
extern "C" unsigned long __intel_cpu_indicator;

{
__intel_cpu_indicator_init();
if (__intel_cpu_indicator < 0x80)
__intel_cpu_indicator = IsSSE2 ? 0x200 : (IsSSE ? 0x80 : __intel_cpu_indicator);
}
#endif

That will fool the Intel Compiler's auto CPU dispatch and replacement math libs into thinking an appropriate non-Intel/AMD CPU is SSE/SSE2 capable. I'm not sure what bit is set for SSE3, SSSE3, SSE4.1 or SSE4.2, if flags are set for them at all (I guess they are used for auto CPU dispatch, but I haven't seen math lib functions that check for them).

--
Stubie

[kemuri-_9]

I got this one to crash and caught the exception in MSVC2008. It shows "stack frame" as avisynth.dll, is it possible that the crash is actually due to Avisynth? How should I proceed next, I saved a minidump but is there more to do? The address at breakpoint is 00AD2BE0 and the command shown on the line is "mov ax,word ptr [ecx]". In the output it says "0xC0000005 : Access violation reading location 0x000677c0."

according to that, it does sound seem like avisynth is what is crashing.
you would need an avisynth with debug symbols and get the crash to occur again to get a backtrace into avisynth....
but chances are likely its due to a certain plugin in particular or a general ENOMEM case.
so debugging this issue just jumped up in difficulty.

[aegisofrime]

Of course Intel's compiler will schedule instructions for Intel CPUs, but the specific complaint has to do with auto CPU dispatch (eg. Qax) and library functions, such as standard math functions like pow(), sin(), etc. The generated code and library functions check flags to see if it's an SSE, SSE2, etc. capable CPU, and will use specific routines depending on those flags. However, when SSE/SSE2 is determined for the flags var, it only looks for "GenuineIntel" CPUs, which means it rejects "AuthenticAMD".

But you can hack it by doing something early in startup like:

#ifdef __INTEL_COMPILER
extern "C" void __intel_cpu_indicator_init(void);
extern "C" unsigned long __intel_cpu_indicator;

{
__intel_cpu_indicator_init();
if (__intel_cpu_indicator < 0x80)
__intel_cpu_indicator = IsSSE2 ? 0x200 : (IsSSE ? 0x80 : __intel_cpu_indicator);
}
#endif

That will fool the Intel Compiler's auto CPU dispatch and replacement math libs into thinking an appropriate non-Intel/AMD CPU is SSE/SSE2 capable. I'm not sure what bit is set for SSE3, SSSE3, SSE4.1 or SSE4.2, if flags are set for them at all (I guess they are used for auto CPU dispatch, but I haven't seen math lib functions that check for them).

--
Stubie

Interesting. I assume that this code should in inserted into the x264 source before compiling? It will be interesting to test a vanilla ICL version and one with this hack :)

[Boulder]

according to that, it does sound seem like avisynth is what is crashing.
you would need an avisynth with debug symbols and get the crash to occur again to get a backtrace into avisynth....
but chances are likely its due to a certain plugin in particular or a general ENOMEM case.
so debugging this issue just jumped up in difficulty.

OK, I think I need to start thinking about what I've changed recently regarding plugins and functions. Fortunately there have been quite few changes. Thanks for your help :)

[rabbitiswise]

Interesting. I assume that this code should in inserted into the x264 source before compiling? It will be interesting to test a vanilla ICL version and one with this hack :)
The code should be inserted into early startup code, eg. in main(). For a dll, somewhere in DllMain() would work. Since math libs are statically linked (usually), each module/exe/dll will have its own __intel_cpu_indicator, and so each one needs the hack applied.

If /Qax (auto CPU dispatch) is not used, then this hack will make no performance difference for compiler generated code. If library functions like sin(), cos(), pow(), log(), etc. are rarely used, then this hack will make little difference for that.

The other thing that the Intel Compiler does, is that for some values of /Qx (not all, but some), code will be generated in the same obj file as main() that also checks for appropriate CPU level support, and will abort/exit if a GenuineIntel CPU is not found. The way around that is to have main() in a source file of its own, that just calls another main type function in a different source file. The source file with main() can be compiled with no /Qx option at all, so no CPU level/capabilities are checked there at all, while all the other source files can be compiled with an appropriate /Qx option.

--
Stubie

[Fr4nz]

Hello,

I want to report a problem with x264 v1416 which affects some users when using "patched" MeGUI.

The problem is described here:
http://forum.doom9.org/showpost.php?p=1371283&postcount=757

The author of the patched MeGUI, Zathor, says that MeGUI is not the culprit, so probably we have a bug inside 1416. In fact, reverting back to v1400 solves the problem. Note also that ALL x264 1416 builds (Rack's, Jeeb's, etc.) give the problem.

[Dark Shikari]

Hello,

I want to report a problem with x264 v1416 which affects some users when using "patched" MeGUI.

The problem is described here:
http://forum.doom9.org/showpost.php?p=1371283&postcount=757

The author of the patched MeGUI, Zathor, says that MeGUI is not the culprit, so probably we have a bug inside 1416. In fact, reverting back to v1400 solves the problem. Note also that ALL x264 1416 builds (Rack's, Jeeb's, etc.) give the problem.I can't debug with no information.

I must have either:

1) Enough information to replicate the problem (exact source and settings).

2) A backtrace from GDB.

If I can't get either, I can't do anything.

[Fr4nz]

I can't debug with no information.

I must have either:

1) Enough information to replicate the problem (exact source and settings).

2) A backtrace from GDB.

If I can't get either, I can't do anything.

1) ANY source; settings are reported in the previous post;

2) What I'd need in order to do it?

[outlaw.78]

Here is a AMD optimized 64bit version

x264 x64 AMD (http://www.mediafire.com/?2kwmmorhgyn)

gcc 4.5.0 20100206 (experimental)
ffmpeg svn 21678
ffms2 svn 281
pthreads 2.9.0.0 shared
x264 0.84.1416 x86_64,amdfam10,fprofiled

[RainyDog]

Here is a AMD optimized 64bit version

x264 x64 AMD (http://www.mediafire.com/?2kwmmorhgyn)

gcc 4.5.0 20100206 (experimental)
ffmpeg svn 21678
ffms2 svn 281
pthreads 2.9.0.0 shared
x264 0.84.1416 x86_64,amdfam10,fprofiled

Thanks very much for this Outlaw, much appreciated.

[outlaw.78]

Thanks very much for this Outlaw, much appreciated.

np anytime :)

[Fr4nz]

I've an update about the problem reported here (http://forum.doom9.org/showpost.php?p=1372206&postcount=2980)some days ago: official unpatched x264 1416 builds from x264.nl seem to work flawlessly. On the contrary, Komisar NAL-HRD patched 1416 builds still freezes, as I've reported in an update here (http://forum.doom9.org/showpost.php?p=1374109&postcount=794) today, so it seems that his builds are bugged or have problems with MeGUI.

Komisar, please, if you're watching this forum could you check what is wrong with your build?

[komisar]

Fr4nz, I use NAL-HRD patch from this post (VFR maniac): http://forum.doom9.org/showthread.php?p=1366965#post1366965
But i dont use vbv-restrictions and i can not check this freezes. Do the VFR-maniac build freezes?

[Fr4nz]

Fr4nz, I use NAL-HRD patch from this post (VFR maniac): http://forum.doom9.org/showthread.php?p=1366965#post1366965
But i dont use vbv-restrictions and i can not check this freezes. Do the VFR-maniac build freezes?

Hi Komisar, maybe this can help: from avs2yuv log, this is the error that is causing the freeze:


This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
Assertation failed!
Program: E:\dvd\avs2yuv\x264_x64.exe
File: encoder/set.c, Line 679
Expression: dpb_output_delay < pow( 2, sps->vui.nal_hrd_parameters.i_dpb_output_delay_length )
E:\work\Up.2009.1080p.avs:
1920x1080, 2500000/104271 fps, 138282 frames
Output error: wrote only 2676405 of 3110400 bytes

Fatal Error: The encoder has encountered an unexpected error!

So, it seems that something is broken in the NAL-HRD patch...

[komisar]

Fr4nz, yes... This is because HAL-HRD patch... My next build will be with another patch (http://forum.doom9.org/showthread.php?t=152127) (if by then it will not apply officially)

P.S. Does the VFR-maniac build with this error too?

[Fr4nz]

Fr4nz, yes... This is because HAL-HRD patch... My next build will be with another patch (http://forum.doom9.org/showthread.php?t=152127) (if by then it will not apply officially)

P.S. Does the VFR-maniac build with this error too?

Yes it does.

So, do you plan to wait for incoming revisions in order to release a new build? :-\

[komisar]

heh, time to port patches for the new x264 revision... :)

new revision incomming....

[jpsdr]

Hello.
Can someone please make a version with new x264 and autoVAQ4 and nal_hrd patch ?

Thanks.

[nurbs]

komisar already did. Follow the link in his signature.

[rack04]

Toolchain:
cross-mingw.gcc443.core2.20100124
gpac-cvs-20090805.core2
coreutils-5.97-2-msys-1.0.11-ext
pkg-config_0.23-3
glib_2.22.3-1
yasm-0.8.0.2289
msys-1.0.11
Patch:
x264_NAL-HRD.1.22.r1442 (http://komisar.gin.by/x.patch/last.used/x264_NAL-HRD.1.22.r1442.diff)
x264_AQ_experiments_v4 (http://komisar.gin.by/test/x264_AQ_experiments_v4.diff)
x86 Build:

x264_x86_r1442M (http://www.multiupload.com/FLJ09RG0TD)

./configure --extra-cflags="-march=core2"
Platform: X86
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
make fprofiled VIDS=parkrun.1280x720.yuv
LAVF/FFMS:
ffmpeg r21847 and libswscale r30592 (http://www.multiupload.com/FUTBXNU986)
ffms2 r290 (http://www.multiupload.com/2HJ04UIN40)

[outlaw.78]

x264 64bit (http://www.mediafire.com/?znmmnkiohic)

gcc 4.5.0 20100211 (experimental)
ffmpeg svn 21850
ffms2 svn 290
pthreads 2.9.0.0 shared
x264 0.85.1442 x86_64,amdfam10,fprofiled

[RainyDog]

x264 64bit (http://www.mediafire.com/?znmmnkiohic)

gcc 4.5.0 20100211 (experimental)
ffmpeg svn 21850
ffms2 svn 290
pthreads 2.9.0.0 shared
x264 0.85.1442 x86_64,amdfam10,fprofiled

Cheers again Outlaw :) These builds are perfect for my Phenom II.

[aegisofrime]

x264 64bit (http://www.mediafire.com/?znmmnkiohic)

gcc 4.5.0 20100211 (experimental)
ffmpeg svn 21850
ffms2 svn 290
pthreads 2.9.0.0 shared
x264 0.85.1442 x86_64,amdfam10,fprofiled

Thanks again for the AMD builds. I hope I'm not asking too much, could you do a AQ patched version as well? :thanks:

[outlaw.78]

http://komisar.gin.by/test/x264_AQ_experiments_v4.diff

this patch by komisar you want?

[aegisofrime]

http://komisar.gin.by/test/x264_AQ_experiments_v4.diff

this patch by komisar you want?

Yes that's the one. If it's not too much trouble for you :D

[outlaw.78]

hmmmm i am getting an error trying to apply this patch to latest source code, using git it says patch does not apply...

any help?