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

[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 ;)