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

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