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

[rack04]

x264 r1247M x86

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

[techouse]

x264_x64_r1247_unpatched | MD5
GCC 4.4.1 20090803 (x64.core2.Komisar), unpatched, generic, fprofiled

________________________________________________________________________________

x264_x86_r1247_techouse | INFO
GCC 4.4.1 20090803 (x86.core2.Komisar), fprofiled, -march=core2

x264_x64_r1247_techouse | INFO
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]

Originally Posted by Trahald

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]

Originally Posted by 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.

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

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

[JEEB]

x264 r1251 64bit unpatched:
download ; hash

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

________________________________________________________________________________

x264 r1251 32bit
download ; release notes

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

x264 r1251 64bit
download ; 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
• 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
win_build_info.txt

OS X:
x264-r1251M-imk-osx.7z
osx_build_info.txt

[techouse]

x264_x64_r1251_unpatched | MD5
GCC 4.4.1 20090803 (x64.core2.Komisar), unpatched, generic, fprofiled

________________________________________________________________________________

x264_x86_r1251_techouse | INFO
GCC 4.4.1 20090803 (x86.core2.Komisar), fprofiled, -march=core2

x264_x64_r1251_techouse | INFO
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.ph...62#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.