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

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

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

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

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 | MD5
GCC 4.4.2 20091019 (x86_64.core2.Komisar), unpatched, generic, fprofiled

________________________________________________________________________________

x264_x86_r1342_NAL-HRD-ALEX_techouse | INFO
GCC 4.4.2 20091019 (x86.core2.Komisar), fprofiled, -march=core2

x264_x64_r1342_NAL-HRD-ALEX_techouse | INFO
GCC 4.4.2 20091019 (x86_64.core2.Komisar), fprofiled, -march=core2

Patches used:

x264_win_zone_parse_fix_06.diff
x264-r1342-nal_hrd-pic_struct-v10a.patch

________________________________________________________________________________

x264_x86_r1342_NAL-HRD-16-1301_techouse | INFO
GCC 4.4.2 20091019 (x86.core2.Komisar), fprofiled, -march=core2

x264_x64_r1342_NAL-HRD-16-1301_techouse | INFO
GCC 4.4.2 20091019 (x86_64.core2.Komisar), fprofiled, -march=core2

Patches used:

x264_win_zone_parse_fix_06.diff
x264_hrd_pd_interlace.16_r1301.diff

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

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

No, because I won't commit any patch that makes such a distinction.

[Brazil2]

Originally Posted by techouse

x264_x86_r1342_NAL-HRD-ALEX_techouse | INFO
GCC 4.4.2 20091019 (x86.core2.Komisar), fprofiled, -march=core2


x264_x86_r1342_NAL-HRD-16-1301_techouse | INFO
GCC 4.4.2 20091019 (x86.core2.Komisar), fprofiled, -march=core2

404 Not Found for both.
Only the unpatched version is available.

[Fr4nz]

Originally Posted by Brazil2

404 Not Found for both.
Only the unpatched version is available.

Go here: http://techouse.project357.com/

[Trahald]

@Selur

Originally Posted by Zm_Gorynych

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]

Originally Posted by Fr4nz

Go here: http://techouse.project357.com/

Thanks

[XhmikosR]

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

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

gcc: 4.4.2-dw2
-march=core2
patch: http://mailman.videolan.org/pipermai...er/006563.html

[Boolsheet]

Originally Posted by XhmikosR

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

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]

Originally Posted by kemuri-_9

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.