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

[kemuri-_9]

Is there a special Reason why i get his Warning with the fixed rev1281 Techhouse Build ?
x264 [warning]: NAL HRD parameters require VBV max bitrate and buffer size to be specified

I never got this Warning before. My cmd is without nal hrd Parameter.

the patch used by techouse does

if( h->param.rc.i_vbv_max_bitrate == 0 || h->param.rc.i_vbv_buffer_size == 0 )
{
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;
}

so it always throws a warning if you're not using vbv-bufsize and/or vbv-maxrate.

the if condition should be more like

if( h->param.vui.b_nal_hrd_parameters_present && (!h->param.rc.i_vbv_max_bitrate || !h->param.rc.i_vbv_buffer_size) )

so it properly only warns if you are actually requesting nal-hrd

[techouse]

Yep, x264-r1281-nal_hrd-pic_struct-v8.diff has that fault but x264_hrd_pd_interlace.16_r1281.diff hasn't, so this error is irrelevant in my latest build. Thanx for pointing it out, kemuri-_9 :)

[techouse]

x264_x64_r1286_unpatched (http://techouse.project357.com/builds/revision1286/x264.exe) | MD5 (http://techouse.project357.com/builds/revision1286/x264.md5)
GCC 4.4.1 20090803 (x64.core2.Komisar), unpatched, generic, fprofiled

Patches used:

the quick GCC 4.4.x workaround (http://pastebin.ca/1612400)

________________________________________________________________________________

x264_x86_r1286_techouse (http://techouse.project357.com/builds/x264_x86_r1286_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x86_r1286_techouse.txt)
GCC 4.4.1 20090803 (x86.core2.Komisar), fprofiled, -march=core2

x264_x64_r1286_techouse (http://techouse.project357.com/builds/x264_x64_r1286_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x64_r1286_techouse.txt)
GCC 4.4.1 20090803 (x86_64.core2.Komisar), fprofiled, -march=core2

Patches used:

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_r1281.diff (http://jeeb.pastebin.ca/1601582)
the quick GCC 4.4.x workaround (http://pastebin.ca/1612400)

[juGGaKNot]

x264_r1286_juGGaKNot (http://www.mediafire.com/download.php?dzqgzmwnnmy), GCC 4.4.1, generic, fprofiled, patched
Source: GIT

Applied patches :

x264_win_zone_parse_fix_06.diff (http://www.mediafire.com/download.php?citmmz1jmcq)
x264_hrd_pd_interlace.16_r1281.diff (http://www.mediafire.com/download.php?mu4ydt3zwjz)
Quick_GCC_4.4.x_Workaround.diff (http://www.mediafire.com/download.php?u12telnj0jn)

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

[Dark Shikari]

People should probably stop compiling GCC 4.4 bugs until we fix the miscompilation issues...

[LoRd_MuldeR]

People should probably stop compiling GCC 4.4 bugs until we fix the miscompilation issues...

So is the "workaround" patch not fixing the miscompilation? :confused:

http://pastebin.ca/1612400

[techouse]

:confused:

[Dark Shikari]

So is the "workaround" patch not fixing the miscompilation? :confused:

http://pastebin.ca/1612400Until we eliminate all such uses of 2D arrays, I don't trust GCC 4.4 to produce valid output.

[LoRd_MuldeR]

Until we eliminate all such uses of 2D arrays, I don't trust GCC 4.4 to produce valid output.

I see. Thanks for info. Awaiting official commit :)

[rack04]

Until we eliminate all such uses of 2D arrays, I don't trust GCC 4.4 to produce valid output.

How about GCC 4.3.4?

[Dark Shikari]

How about GCC 4.3.4?Fix has already been committed, so... :p

[techouse]

One patch a day keeps the encoder away. :P

[shroomM]

Just a quick noob question...

The 1286 build on x264.nl (compiled with "32bit: gcc 3.4.6 make fprofiled") should be OK, yes?

The reason for asking is that I get some corrupted video with it and would just like to know if I should wait for 1287 or report the bug. :p

Thanks, A

[MythCreator]

Try it,if it still incorrect then report it.

Besides:GCC 4.4.2 is coming soon

[techouse]

x264_x64_r1287_unpatched (http://techouse.project357.com/builds/revision1287/x264.exe) | MD5 (http://techouse.project357.com/builds/revision1287/x264.md5)
GCC 4.4.1 20090803 (x64.core2.Komisar), unpatched, generic, fprofiled

________________________________________________________________________________

x264_x86_r1287_techouse (http://techouse.project357.com/builds/x264_x86_r1287_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x86_r1287_techouse.txt)
GCC 4.4.1 20090803 (x86.core2.Komisar), fprofiled, -march=core2

x264_x64_r1287_techouse (http://techouse.project357.com/builds/x264_x64_r1287_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x64_r1287_techouse.txt)
GCC 4.4.1 20090803 (x86_64.core2.Komisar), fprofiled, -march=core2

Patches used:

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_r1281.diff (http://jeeb.pastebin.ca/1601582)

[rack04]

Using r1287 I get a crash using the following command line:

--profile baseline --preset slower --tune animation --crf 18 --level 3 --vbv-bufsize 10000 --vbv-maxrate 10000 --aud --sar 1:1 --output "C:\Personal\Videos\94518080-output.264" "C:\Personal\Videos\94518080.avs"

94518080.avs
LoadPlugin("C:\Program Files\DGAVCIndex\DGAVCDecode.dll")
AVCSource("C:\Personal\Videos\94518080.dga")
Spline64Resize(480,256)

Sample (http://www.megaupload.com/?d=HHTTTJ1H)

The video encodes normally using the following command line:

--preset slower --tune animation --crf 18 --aud --sar 1:1 --output "C:\Personal\Videos\94518080-output.264" "C:\Personal\Videos\94518080.avs"

[shroomM]

Tried using techouse's 1287 and unpatched 1286 from x264.nl, both had corrupted video...

Here's the generated stream (1286 x264.nl) ... http://www.mediafire.com/download.php?lzjzwmfdj4z

and here's the Techouse's... http://www.mediafire.com/download.php?njwl2yogmzz

The source was the 2012 trailer from Apple (http://www.apple.com/trailers/sony_pictures/2012/ - Trailer 2, 1080p).

Source file:
File : 2012-tlr2_h1080p.mov
Size : 225.797.353 bytes
SHA-1: 693d9f752be7fafe375426e26fd02fb426172d17

Demuxed video:
File : 2012-tlr2_h1080p_track1.h264
Size : 215.677.417 bytes
SHA-1: 974bba87c3f9103d09229a33d67e90757d0ea9a0

Indexed using DGAVCDec, log file:
Stream Type: AVC Elementary
Profile: Main
Level: 4.1
Frame Size: 1920x800
SAR: Unspecified
Display Size:
Frame Rate: 25.000000 fps
Colorimetry: BT.709 [1]
Frame Structure: Frame
Frame Type: not yet
Coded Number: 4033
Playback Number: 4033
Frame Repeats: 0
Field Repeats: 0
Bitrate: 1.575
Bitrate (Avg): 10.471
Bitrate (Max): 53.588
Elapsed: 0:00:11
Remain: 0:00:00
FPS:
Info: Finished!

My AVS script:
LoadPlugin("c:\Programs\DGAVCDec\DGAVCDecode.dll")
avcsource("2012-tlr2_h1080p_track1.dga")
ConvertToYV12()
AddBorders(0,140,0,140)
Spline36Resize(1280,720)
Trim(0,750)

The 1287 has Trim(500,750) to reduce the size of the stream.

The AVS script plays fine, without glitches.

x264 output (1286):
c:\work\2012>x264.exe --preset medium --tune film --pass 1 --bitrate 7000 --stats 2012.stats --level 4.1 --keyint 25 --bframes 3 --vbv-bufsize 30000 --vbv-maxrate 7000 --rc-lookahead 25 --output NUL 2012_software.avs
avis [info]: 1280x720 @ 25.00 fps (751 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [info]: profile Main, level 4.1
x264 [info]: frame I:46 Avg QP:15.87 size: 66662
x264 [info]: frame P:426 Avg QP:15.12 size: 39939
x264 [info]: frame B:279 Avg QP:15.02 size: 15979
x264 [info]: consecutive B-frames: 33.3% 40.3% 4.3% 22.1%
x264 [info]: mb I I16..4: 57.2% 0.0% 42.8%
x264 [info]: mb P I16..4: 36.2% 0.0% 0.0% P16..4: 27.4% 0.0% 0.0% 0.0% 0.0% skip:36.4%
x264 [info]: mb B I16..4: 4.3% 0.0% 0.0% B16..8: 17.2% 0.0% 0.0% direct:17.3% skip:61.2% L0:32.3% L1:41.1% BI:26.7%
x264 [info]: coded y,uvDC,uvAC intra: 54.0% 53.4% 39.4% inter: 23.6% 25.8% 11.5%

x264 [info]: i16 v,h,dc,p: 44% 28% 15% 13%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 22% 31% 13% 5% 6% 5% 7% 5% 6%
x264 [info]: kb/s:6534.93

encoded 751 frames, 31.26 fps, 6534.93 kb/s

c:\work\2012>x264.exe --preset medium --tune film --pass 2 --bitrate 7000 --stats 2012.stats --level 4.1 --keyint 25 --ref 3 --bframes 3 --vbv-bufsize 30000 --vbv-maxrate 7000 --rc-lookahead 25 --aud --output 2012.mp4 2012_software.avs
avis [info]: 1280x720 @ 25.00 fps (751 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [info]: profile High, level 4.1
mp4 [info]: initial delay 1 (scale 25)
x264 [info]: frame I:46 Avg QP:15.97 size: 70757
x264 [info]: frame P:426 Avg QP:15.06 size: 43238
x264 [info]: frame B:279 Avg QP:20.88 size: 4620
x264 [info]: consecutive B-frames: 33.3% 40.3% 4.3% 22.1%
x264 [info]: mb I I16..4: 38.1% 46.6% 15.3%
x264 [info]: mb P I16..4: 7.7% 20.2% 5.7% P16..4: 14.6% 9.1% 5.0% 0.0% 0.0% skip:37.7%
x264 [info]: mb B I16..4: 0.5% 0.8% 0.1% B16..8: 12.1% 0.6% 1.0% direct: 4.6% skip:80.3% L0:42.4% L1:48.3% BI: 9.3%
x264 [info]: 8x8 transform intra:56.9% inter:67.7%
x264 [info]: coded y,uvDC,uvAC intra: 61.2% 64.0% 58.6% inter: 17.0% 20.0% 11.6%

x264 [info]: i16 v,h,dc,p: 64% 18% 4% 14%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 17% 29% 25% 4% 5% 4% 5% 4% 6%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 19% 39% 17% 3% 5% 4% 5% 3% 4%
x264 [info]: ref P L0: 82.5% 11.9% 5.6%
x264 [info]: ref B L0: 88.9% 11.1%
x264 [info]: kb/s:6115.35

encoded 751 frames, 25.12 fps, 6115.35 kb/s

x264 output (1287):
c:\work\2012>x264_1287_techouse.exe --preset medium --tune film --pass 1 --bitrate 7000 --stats c:\work\2012\2012.stats --level 4.1 --keyint 25 --bframes 3 --vbv-bufsize 30000 --vbv-maxrate 7000 --rc-lookahead 25 --output NUL c:\work\2012\2012_software.avs
avis [info]: 1280x720 @ 25.00 fps (251 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [info]: profile Main, level 4.1
x264 [info]: frame I:26 Avg QP:20.17 size: 93538
x264 [info]: frame P:130 Avg QP:26.33 size: 40665
x264 [info]: frame B:95 Avg QP:26.37 size: 15812
x264 [info]: consecutive B-frames: 24.0% 57.8% 4.0% 14.2%
x264 [info]: mb I I16..4: 41.3% 0.0% 58.7%
x264 [info]: mb P I16..4: 29.4% 0.0% 0.0% P16..4: 39.9% 0.0% 0.0% 0.0% 0
.0% skip:30.7%
x264 [info]: mb B I16..4: 4.4% 0.0% 0.0% B16..8: 22.8% 0.0% 0.0% direct:
16.8% skip:56.1% L0:28.3% L1:36.1% BI:35.6%
x264 [info]: coded y,uvDC,uvAC intra: 68.2% 69.2% 56.5% inter: 27.8% 34.0% 13.4%

x264 [info]: i16 v,h,dc,p: 35% 36% 19% 10%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 23% 36% 10% 4% 5% 4% 7% 5% 6%
x264 [info]: kb/s:7347.11

encoded 251 frames, 21.55 fps, 7347.11 kb/s

c:\work\2012>x264_1287_techouse.exe --preset medium --tune film --pass 2 --bitrate 7000 --stats c:\work\2012\2012.stats --level 4.1 --keyint 25 --ref 3 --bframes 3 --vbv-bufsize 30000 --vbv-maxrate 7000 --rc-lookahead 25 --aud --output c:\work\2012\2012_1287.mp4 c:\work\2012\2012_software.avs
avis [info]: 1280x720 @ 25.00 fps (251 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [info]: profile High, level 4.1
mp4 [info]: initial delay 1 (scale 25)
x264 [info]: frame I:26 Avg QP:20.44 size: 97332
x264 [info]: frame P:130 Avg QP:26.02 size: 45084
x264 [info]: frame B:95 Avg QP:37.30 size: 3068
x264 [info]: consecutive B-frames: 24.0% 57.8% 4.0% 14.2%
x264 [info]: mb I I16..4: 25.3% 55.7% 19.0%
x264 [info]: mb P I16..4: 2.7% 13.2% 4.8% P16..4: 26.4% 15.0% 7.7% 0.0% 0
.0% skip:30.2%
x264 [info]: mb B I16..4: 0.1% 0.1% 0.0% B16..8: 18.4% 0.2% 0.3% direct:
5.5% skip:75.3% L0:43.5% L1:49.6% BI: 6.9%
x264 [info]: 8x8 transform intra:59.8% inter:77.0%
x264 [info]: coded y,uvDC,uvAC intra: 71.5% 73.3% 62.8% inter: 23.3% 31.3% 16.6%

x264 [info]: i16 v,h,dc,p: 62% 25% 8% 5%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 16% 40% 12% 4% 5% 5% 6% 5% 7%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 25% 40% 11% 3% 4% 4% 5% 3% 5%
x264 [info]: ref P L0: 79.9% 13.2% 6.9%
x264 [info]: ref B L0: 90.2% 9.8%
x264 [info]: kb/s:6918.80

encoded 251 frames, 19.28 fps, 6918.80 kb/s

Tried playing the MP4 in MPC using ffmpeg-mt, libavcodec and DivX H.264 decoder. All have the same problem.

The most obvious error shows at about 00:24 in the video (where the statue falls).

My specifications...
Intel Core i7 920
6GB RAM
Vista Business x64

The same glitches appeared when encoding on my second PC..
Core2 Quad Q9300
4GB RAM
Windows 7 Professional x64

Regards,
A

[LoRd_MuldeR]

Just a quick noob question...

The 1286 build on x264.nl (compiled with "32bit: gcc 3.4.6 make fprofiled") should be OK, yes?

The reason for asking is that I get some corrupted video with it and would just like to know if I should wait for 1287 or report the bug. :p

Thanks, A

The issue fixed in r1287 didn't cause any obvious artifacts and it's not for GCC 3.x.x compiler (as used for the x264.nl builds) anyway.

So if you get "corrupted video", then the problem must be elsewhere. But before blaming x264, you should first carefully check your source script as well as your hardware, if not already done so...

[techouse]

LOL, I don't know if I could handle another patch/commit today :P

[shroomM]

Yeah, it's been crazy today. Kudos to everyone :)

Just retried with r1287 on x264.nl, the same error occurs (both PCs). Same source.

Regards,
A

[Dark Shikari]

It's not a glitch, it's row-based VBV in B-frames acting up. Screw this shit, I add it to fix one issue and it causes another...

[techouse]

Here we go again....

[juGGaKNot]

but fixed (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=a65d36142b765516dd80a6bed5bff7444b24f4aa) so ... haha

[Dark Shikari]

Also, seriously, linking me to an Apple Trailers page is useless. I am not going to spend three hours trying to get my damned user-agent spoofing working just so I can download a movie to test a user-reported bug.

If you want me to fix your bugs, upload your movies in a place that it is actually possible for me to download them. If wget doesn't work I won't fix your bug.

[techouse]

If wget doesn't work I won't fix your bug.
Hahahahahahahahaha! That quote made my day :D :D :D

[shroomM]

Yeah, you are right, sorry about that, was a bit in a hurry when reporting it.

Will try to do better next time, I promise :)

[dragonkeeper]

For the last week I've been toying Encore trying to make it mux a blu-ray disk whereas i've used the x264 codec to encode the video. So far i have had no luck. As Encore will tell me I don't have the necessary codecs to render the video, or it wants to transcode the video (painfully slow process with their built in encoder), or it chokes on muxing the disk and has issues with buffer underflows. Can some one point me to a x264 build that produces Scenarist compliant streams?

[techouse]

x264_x64_r1288_unpatched (http://techouse.project357.com/builds/revision1288/x264.exe) | MD5 (http://techouse.project357.com/builds/revision1288/x264.md5)
GCC 4.4.1 20090803 (x64.core2.Komisar), unpatched, generic, fprofiled

________________________________________________________________________________

x264_x86_r1288_techouse (http://techouse.project357.com/builds/x264_x86_r1288_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x86_r1288_techouse.txt)
GCC 4.4.1 20090803 (x86.core2.Komisar), fprofiled, -march=core2

x264_x64_r1288_techouse (http://techouse.project357.com/builds/x264_x64_r1288_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x64_r1288_techouse.txt)
GCC 4.4.1 20090803 (x86_64.core2.Komisar), fprofiled, -march=core2

Patches used:

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_r1281.diff (http://jeeb.pastebin.ca/1601582)

[shroomM]

In case you still need it, here's the file, shortened and still produces artifacts...

http://www.filedropper.com/trl

Didn't really know in which format to put it, so I used Y4M (640x352), I hope that's OK...

The command line ...

x264_1288_techouse.exe --preset medium --tune film --pass 1 --bitrate 7000 --stats c:\work\2012\2012.stats --level 4.1 --keyint 25 --bframes 3 --vbv-bufsize 30000 --vbv-maxrate 7000 --rc-lookahead 25 --output NUL trl.y4m 640x352
x264_1288_techouse.exe --preset medium --tune film --pass 2 --bitrate 7000 --stats c:\work\2012\2012.stats --level 4.1 --keyint 25 --ref 3 --bframes 3 --vbv-bufsize 30000 --vbv-maxrate 7000 --rc-lookahead 25 --aud --output c:\work\2012\2012_1288_th.mp4 trl.y4m 640x352

Edit: saw in the other post that it's fixed already. Damn, you're quick! :)

[rack04]

x264_x86_r1289M (http://www.megaupload.com/?d=K0S3MUES)

Built by rack04 on October 12, 2009, 3:49:58 PM CST
gcc.exe (GCC) 4.4.1 (x86.core2.Komisar)
--extra-cflags="-march=core2"
make fprofiled

Patched with:

x264_hrd_pd_interlace.16_r1281.diff (http://jeeb.pastebin.ca/1601582)
x264_win_zone_parse_fix_06.diff (http://kemuri9.net/dev/x264/patches/x264_win_zone_parse_fix_06.diff)

[techouse]

Damn, this will be the 4th build today... This is worse than running a marathon :P

[techouse]

x264_x64_r1289_unpatched (http://techouse.project357.com/builds/revision1289/x264.exe) | MD5 (http://techouse.project357.com/builds/revision1289/x264.md5)
GCC 4.4.1 20090803 (x64.core2.Komisar), unpatched, generic, fprofiled

________________________________________________________________________________

x264_x86_r1289_techouse (http://techouse.project357.com/builds/x264_x86_r1289_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x86_r1289_techouse.txt)
GCC 4.4.1 20090803 (x86.core2.Komisar), fprofiled, -march=core2

x264_x64_r1289_techouse (http://techouse.project357.com/builds/x264_x64_r1289_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x64_r1289_techouse.txt)
GCC 4.4.1 20090803 (x86_64.core2.Komisar), fprofiled, -march=core2

Patches used:

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_r1281.diff (http://jeeb.pastebin.ca/1601582)

[Blue_MiSfit]

Get ready for another one if Dark_Shikari fixes the bug I just found... :P

~MiSfit

[techouse]

I have unending love for the project so you can rest assured that I will build wahatever you throw at me in the shortest amount of time. :)

[kemuri-_9]

[18:39] <Dark_Shikari> blue_misfit: committed locally
[18:39] <Dark_Shikari> since it's an old/rare bug, I won't push it right now


so you can rest easy at the compiling trigger..... for now :devil:

[techouse]

x264_x64_r1292_unpatched (http://techouse.project357.com/builds/revision1292/x264.exe) | MD5 (http://techouse.project357.com/builds/revision1292/x264.md5)
GCC 4.4.1 20090803 (x64.core2.Komisar), unpatched, generic, fprofiled

________________________________________________________________________________

x264_x86_r1292_techouse (http://techouse.project357.com/builds/x264_x86_r1292_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x86_r1292_techouse.txt)
GCC 4.4.1 20090803 (x86.core2.Komisar), fprofiled, -march=core2

x264_x64_r1292_techouse (http://techouse.project357.com/builds/x264_x64_r1292_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x64_r1292_techouse.txt)
GCC 4.4.1 20090803 (x86_64.core2.Komisar), fprofiled, -march=core2

Patches used:

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_r1281.diff (http://jeeb.pastebin.ca/1601582)

[elguaxo]

What kind of glitches were addressed here (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=e381f6d0093504a545fe4d90e3a6f178c6877cc7)? I did some encodes with 1281 using that options (slow-firstpass + weightb + multiref + 2pass) and I wonder if I should do them again.

[kemuri-_9]

What kind of glitches were addressed here (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=e381f6d0093504a545fe4d90e3a6f178c6877cc7)? I did some encodes with 1281 using that options (slow-firstpass + weightb + multiref + 2pass) and I wonder if I should do them again.

i saw someone's generated video stream that was affected by this specific bug,
it had a stutter-like effect visible in numerous macroblocks when progressing in a smoothly panning scene.

[elguaxo]

it had a stutter-like effect visible in numerous macroblocks when progressing in a smoothly panning scene.

Thanks, I'll check for that.

[juGGaKNot]

Writing library : x264 core 77 r1292M e381f6d
Encoding settings : 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 / constrained_intra=0 / bframes=3 / b_pyramid=0 / b_adapt=2 / b_bias=0 / direct=2 / wpredb=1 / keyint=300 / keyint_min=30 / scenecut=40 / rc_lookahead=60 / rc=2pass / mbtree=1 / bitrate=4300 / 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

I do not see nal-hrd in mediainfo with the latest builds, is this normal ?

start "encode" /b /low /wait "%mypath%\bin\x264.exe" --pass 1 --preset veryslow --level %mylevel% --bitrate %btrate_x264% --stats "%mypath%\%mpath%\T1\movie.stats" --ref %myrefs% --min-keyint %mint% --keyint %kint% --bframes 3 --ratetol 2.0 --merange 32 --direct temporal --aq-mode 2 --no-fast-pskip --no-dct-decimate --sar 1:1 --vbv-maxrate 20000 --vbv-bufsize 20000 --nal-hrd --aud --output NUL %myavs%

[VFR maniac]

Trahald's nal-hrd patch doesn't write parameter string in User Data Unregistered SEI, while Alex's does.

[ACrowley]

Ive one last Question about VBV.

So far i know VBV is recommend in with 2 pass and not in 1 pass.

But the VBV Algorythm was updated a few Times.
Is VBV recommend in 1 pass CRF ? Or should i better use 2 pass with VBV?
X264 Wiki :
"It is highly recommended, though not required, to use 2pass bitrate mode with VBV"

I need VBV to handle high Peaks because i use Standalones for Playback.

[LoRd_MuldeR]

Ive one last Question about VBV.

So far i know VBV is recommend in with 2 pass and not in 1 pass.

But the VBV Algorythm was updated a few Times.
Is VBV recommend in 1 pass CRF ? Or should i better use 2 pass with VBV?
X264 Wiki :
"It is highly recommended, though not required, to use 2pass bitrate mode with VBV"

I need VBV to handle high Peaks because i use Standalones for Playback.

That information is outdated. In up-to-date x264 the 1-Pass VBV (CRF mode) should work perfectly fine. I think the Lookahead VBV, introduced in r1213, fixed it :)

You should decided 2-Pass -vs- CRF depending on whether you want to hit a specific level of quality or you want to hit a specific file size...

[shon3i]

Dark Shikari last time very clear say that 1pass VBV algo is more stable and recommended than 2pass algo. I personaly newer have issues with 2pass VBV, little in early days (which is fixed) and with your killer sample.

[ACrowley]

Dark Shikari last time very clear say that 1pass VBV algo is more stable and recommended than 2pass algo. I personaly newer have issues with 2pass VBV, little in early days (which is fixed) and with your killer sample.

So VBV ist Ok and safe in both modes today...THX

[Blue_MiSfit]

Yeah. 1 pass VBV is actually pretty awesome :) 2 passes is basically no longer necessary for CBR anyway :D

[iko417]

I was wondering where i can download compiled up-to-date x264.exe with mixaq patch integrated?
The last version i have is "x264.1240.mixaq32.exe".

Forgot to mention in that file i have it has enabled
aq-mode 2
mb-tree

Thanks,
Ivan

[Rodger]

Hi guys!
Since it seems again there is a problem with the update servers,

which is the the current realease advised to use with Megui?

[Astrophizz]

That request should be posted in the MeGUI thread. I don't think MeGUI has been updated in a while but look on the thread to see if a new update server has been posted (last I checked kurtnoise was hosting it).

[LoRd_MuldeR]

I was wondering where i can download compiled up-to-date x264.exe with mixaq patch integrated?
The last version i have is "x264.1240.mixaq32.exe".

Forgot to mention in that file i have it has enabled
aq-mode 2
mb-tree

Thanks,
Ivan

AQ Mode 2 is committed, any up-to date x264 build does have it. The same applies to MB Tree.