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

[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