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

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