Worse Quality in Dissolve() Fades With Weightp Than Without

[Conquerist]

My avisynth script consists of this line repeated and concatenated for each image in the source folder.

Dissolve(ImageSource("IMG_2040.jpg",end=5).Spline36Resize(1024,768),BlankClip(6,1024,768,"RGB24").KillAudio(),5)

As I understand it, these linear fades should benefit the most from weightp. Here's my script:

for %%A in (0 1 2) DO (
..\x264.weightp --weightp %%A --bitrate 1500 --pass 1 --preset slow --bframes 8 --ref 8 --tune ssim --ssim "fades.avs" --output NUL
..\x264.weightp --weightp %%A --bitrate 1500 --pass 2 --preset slow --bframes 8 --ref 8 --tune ssim --ssim "fades.avs" --output "weightp.%%A.264"
)

And the results:

WEIGHTP 0
avis [info]: 1024x768 @ 24.00 fps (273 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile Main, level 3.1
x264 [info]: frame I:2 Avg QP:27.48 size: 66136
x264 [info]: frame P:80 Avg QP:30.22 size: 22919
x264 [info]: frame B:191 Avg QP:31.43 size: 76
x264 [info]: consecutive B-frames: 14.4% 1.5% 1.1% 1.5% 1.8% 79.7% 0.0% 0.
0% 0.0%
x264 [info]: mb I I16..4: 49.6% 0.0% 50.4%
x264 [info]: mb P I16..4: 96.2% 0.0% 0.0% P16..4: 0.2% 0.0% 0.0% 0.0% 0
.0% skip: 3.6%
x264 [info]: mb B I16..4: 0.4% 0.0% 0.0% B16..8: 0.0% 0.0% 0.0% direct:
0.2% skip:99.3% L0: 8.9% L1:81.3% BI: 9.8%
x264 [info]: final ratefactor: 26.00
x264 [info]: direct mvs spatial:52.4% temporal:47.6%
x264 [info]: coded y,uvDC,uvAC intra: 35.6% 27.2% 13.4% inter: 0.1% 0.1% 0.0%
x264 [info]: i16 v,h,dc,p: 61% 14% 14% 10%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 12% 29% 15% 6% 7% 7% 10% 5% 9%
x264 [info]: SSIM Mean Y:0.9611572
x264 [info]: kb/s:1392.76

encoded 273 frames, 2.08 fps, 1392.76 kb/s
avis [info]: 1024x768 @ 24.00 fps (273 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile High, level 4.0
x264 [info]: frame I:2 Avg QP:30.05 size: 52183
x264 [info]: frame P:80 Avg QP:28.61 size: 24588
x264 [info]: frame B:191 Avg QP:28.58 size: 286
x264 [info]: consecutive B-frames: 14.4% 1.5% 1.1% 1.5% 1.8% 79.7% 0.0% 0.
0% 0.0%
x264 [info]: mb I I16..4: 38.8% 37.8% 23.5%
x264 [info]: mb P I16..4: 55.6% 27.5% 11.0% P16..4: 2.1% 0.3% 0.1% 0.0% 0
.0% skip: 3.5%
x264 [info]: mb B I16..4: 0.8% 0.5% 0.1% B16..8: 0.2% 0.0% 0.0% direct:
0.1% skip:98.2% L0:43.9% L1:21.9% BI:34.2%
x264 [info]: 8x8 transform intra:29.6% inter:72.1%
x264 [info]: direct mvs spatial:55.0% temporal:45.0%
x264 [info]: coded y,uvDC,uvAC intra: 36.2% 31.6% 15.9% inter: 0.5% 0.4% 0.0%
x264 [info]: i16 v,h,dc,p: 81% 5% 7% 7%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 15% 22% 26% 5% 6% 6% 6% 6% 8%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 23% 26% 12% 5% 7% 7% 6% 6% 8%
x264 [info]: ref P L0: 1.3% 67.8% 5.8% 5.4% 0.8% 8.7% 2.6% 7.6%
x264 [info]: ref B L0: 48.0% 34.5% 6.4% 3.7% 5.0% 0.2% 2.3%
x264 [info]: SSIM Mean Y:0.9711909
x264 [info]: kb/s:1495.20

encoded 273 frames, 1.88 fps, 1495.20 kb/s

WEIGHTP 1

avis [info]: 1024x768 @ 24.00 fps (273 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile Main, level 3.1
x264 [info]: frame I:2 Avg QP:27.48 size: 66136
x264 [info]: frame P:80 Avg QP:30.22 size: 22919
x264 [info]: frame B:191 Avg QP:31.43 size: 76
x264 [info]: consecutive B-frames: 14.4% 1.5% 1.1% 1.5% 1.8% 79.7% 0.0% 0.
0% 0.0%
x264 [info]: mb I I16..4: 49.6% 0.0% 50.4%
x264 [info]: mb P I16..4: 96.2% 0.0% 0.0% P16..4: 0.2% 0.0% 0.0% 0.0% 0
.0% skip: 3.6%
x264 [info]: mb B I16..4: 0.4% 0.0% 0.0% B16..8: 0.0% 0.0% 0.0% direct:
0.2% skip:99.3% L0: 8.9% L1:81.3% BI: 9.8%
x264 [info]: final ratefactor: 26.00
x264 [info]: direct mvs spatial:52.4% temporal:47.6%
x264 [info]: coded y,uvDC,uvAC intra: 35.6% 27.2% 13.4% inter: 0.1% 0.1% 0.0%
x264 [info]: i16 v,h,dc,p: 61% 14% 14% 10%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 12% 29% 15% 6% 7% 7% 10% 5% 9%
x264 [info]: SSIM Mean Y:0.9611572
x264 [info]: kb/s:1392.76

encoded 273 frames, 1.89 fps, 1392.76 kb/s
avis [info]: 1024x768 @ 24.00 fps (273 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile High, level 4.0
x264 [info]: frame I:2 Avg QP:30.05 size: 52183
x264 [info]: frame P:80 Avg QP:28.60 size: 24588
x264 [info]: frame B:191 Avg QP:28.59 size: 286
x264 [info]: consecutive B-frames: 14.4% 1.5% 1.1% 1.5% 1.8% 79.7% 0.0% 0.
0% 0.0%
x264 [info]: mb I I16..4: 38.8% 37.8% 23.5%
x264 [info]: mb P I16..4: 55.7% 27.5% 10.9% P16..4: 2.0% 0.2% 0.1% 0.0% 0
.0% skip: 3.5%
x264 [info]: mb B I16..4: 0.8% 0.5% 0.1% B16..8: 0.3% 0.0% 0.0% direct:
0.1% skip:98.2% L0:45.3% L1:22.3% BI:32.4%
x264 [info]: 8x8 transform intra:29.7% inter:73.7%
x264 [info]: direct mvs spatial:55.0% temporal:45.0%
x264 [info]: coded y,uvDC,uvAC intra: 36.2% 31.6% 15.9% inter: 0.5% 0.4% 0.0%
x264 [info]: i16 v,h,dc,p: 80% 5% 7% 7%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 15% 22% 26% 5% 6% 6% 6% 6% 9%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 22% 26% 12% 5% 7% 7% 6% 6% 8%
x264 [info]: ref P L0: 0.6% 71.6% 0.8% 2.1% 5.0% 0.5% 9.2% 2.5% 7.7%
x264 [info]: ref B L0: 45.6% 36.4% 6.9% 4.3% 4.5% 0.2% 2.1%
x264 [info]: SSIM Mean Y:0.9711826
x264 [info]: kb/s:1495.24

encoded 273 frames, 1.59 fps, 1495.24 kb/s

WEIGHTP 2

avis [info]: 1024x768 @ 24.00 fps (273 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile Main, level 3.1
x264 [info]: frame I:2 Avg QP:26.77 size: 81072
x264 [info]: frame P:96 Avg QP:34.31 size: 16358
x264 [info]: frame B:175 Avg QP:36.94 size: 1000
x264 [info]: consecutive B-frames: 8.1% 25.1% 14.4% 17.7% 0.0% 24.4% 10.3% 0.
0% 0.0%
x264 [info]: mb I I16..4: 33.8% 0.0% 66.2%
x264 [info]: mb P I16..4: 91.1% 0.0% 0.0% P16..4: 4.3% 0.0% 0.0% 0.0% 0
.0% skip: 4.6%
x264 [info]: mb B I16..4: 22.2% 0.0% 0.0% B16..8: 1.0% 0.0% 0.0% direct:
0.5% skip:76.3% L0:64.1% L1:31.9% BI: 4.0%
x264 [info]: final ratefactor: 30.23
x264 [info]: direct mvs spatial:98.9% temporal:1.1%
x264 [info]: coded y,uvDC,uvAC intra: 22.3% 19.8% 6.1% inter: 2.0% 2.0% 0.1%
x264 [info]: i16 v,h,dc,p: 54% 22% 14% 10%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 14% 28% 14% 7% 7% 7% 9% 6% 9%
x264 [info]: Weighted P-Frames: Y:0.0%
x264 [info]: SSIM Mean Y:0.9169969
x264 [info]: kb/s:1341.53

encoded 273 frames, 2.00 fps, 1341.53 kb/s
avis [info]: 1024x768 @ 24.00 fps (273 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile High, level 4.0
x264 [info]: frame I:2 Avg QP:30.95 size: 46367
x264 [info]: frame P:96 Avg QP:32.87 size: 17927
x264 [info]: frame B:175 Avg QP:34.44 size: 1686
x264 [info]: consecutive B-frames: 8.1% 25.1% 14.4% 17.7% 0.0% 24.4% 10.3% 0.
0% 0.0%
x264 [info]: mb I I16..4: 24.6% 55.1% 20.3%
x264 [info]: mb P I16..4: 26.4% 56.0% 9.4% P16..4: 2.9% 0.6% 0.1% 0.0% 0
.0% skip: 4.6%
x264 [info]: mb B I16..4: 10.0% 5.6% 0.4% B16..8: 1.6% 0.0% 0.0% direct:
2.7% skip:79.6% L0:77.8% L1:20.4% BI: 1.8%
x264 [info]: 8x8 transform intra:54.7% inter:90.0%
x264 [info]: direct mvs spatial:98.3% temporal:1.7%
x264 [info]: coded y,uvDC,uvAC intra: 31.1% 27.2% 8.3% inter: 4.7% 2.3% 0.0%
x264 [info]: i16 v,h,dc,p: 38% 26% 16% 20%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 12% 16% 51% 3% 3% 4% 3% 3% 4%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 25% 27% 16% 5% 6% 6% 5% 5% 6%
x264 [info]: Weighted P-Frames: Y:0.0%
x264 [info]: ref P L0: 15.6% 26.2% 32.9% 9.9% 2.7% 3.2% 3.3% 4.0% 2.1%
x264 [info]: ref B L0: 26.4% 3.3% 8.2% 6.4% 9.3% 4.3% 42.1%
x264 [info]: SSIM Mean Y:0.9459391
x264 [info]: kb/s:1483.12

encoded 273 frames, 1.64 fps, 1483.12 kb/s

Surprisingly the quality was worse, and 0.0% weighted p-frames were used! I know that metrics aren't always a good indication of quality, but the SSIM dropped from 0.9711909 to 0.9459391, and visual quality decreased accordingly.

Dropping --tune ssim from the command line resulted in nearly identical results with and without weightp.

[Dark Shikari]

Weighted P-Frames: Y:0.0% in a fadeYour copy of x264 is miscompiled. Stop using GCCs that suck, that is, every single GCC version whose version number starts with a "4".

And on a hunch, changestatic void weights_plane_analyse(tostatic void NOINLINE weights_plane_analyse(

in encoder/slicetype.c and see if that fixes the miscompilation in crappy compilers.

[drmpeg]

Your copy of x264 is miscompiled. Stop using GCCs that suck, that is, every single GCC version after 3.4.5.
Just curious, but why does every version of gcc suck after 3.4.5? Is that for x86, or gcc in general? The reason I ask, is that I just went through a ginormous port from gcc 2.7.2 to gcc 4.1.2 (on SPARC of all CPU's). Aside from the super annoying requirement to have a newline at the end of each file and no text after #else or #endif, it went pretty smoothly. Performance wise, it seemed to be a wash.

Ron

[Dark Shikari]

Just curious, but why does every version of gcc suck after 3.4.5? Is that for x86, or gcc in general? The reason I ask, is that I just went through a ginormous port from gcc 2.7.2 to gcc 4.1.2 (on SPARC of all CPU's). Aside from the super annoying requirement to have a newline at the end of each file and no text after #else or #endif, it went pretty smoothly. Performance wise, it seemed to be a wash.

RonEvery single GCC version starting at 4.0 has had a catastrophic number of bugs and miscompilation issues. Furthermore, it took until gcc 4.3 to even tie the performance of 3.4. mplayer still won't compile correctly with 4.4.

More specifically, I have never had a miscompilation issue with gcc 3.4 that wasn't also in 4.X, but I've constantly had issues with miscompilation in 4.X that weren't in 3.4.

[Conquerist]

Thanks for the quick reply.

NOINLINE weights_plane_analyse didn't fix it for TDM GCC 4.4.1 I'm afraid.

bob0r's build with gcc 3.4.5 used Weighted P-Frames 36.5% of the time, but still with --tune ssim the SSIM dropped from 0.9711910 to 0.9604006.

[Sagekilla]

Conquerist, I think the real question should be: Am I seeing a noticeable difference in visual quality when I view the Weight P vs non-weight P?

Any change in PSNR or SSIM doesn't always correlate with a corresponding change in actual visual quality. Take Psy-RDO and AQ for example. Both are known to decrease metrics but vastly improve quality.

[Astrophizz]

Well that would only be the case if weight-p is a psychovisual optimization. Otherwise it should increase PSNR and SSIM.

[nurbs]

I only did one test run (2 pass; --tune ssim), but for me ssim was higher with weighted p-frames.

[juGGaKNot]

I just encoded a clip, simple fade, i can confirm, its much worst with weightp.

[Dark Shikari]

Are you insane or do you have a miscompiled build?

Smart weighting (203.99 kb/s):
http://i37.tinypic.com/111ijah.png

No smart weighting (281.83 kb/s):
http://i36.tinypic.com/289wwts.png

[juGGaKNot]

jeebs 4.3.4, 2 seconds, now encoding 6 minutes and posting screens

--preset veryslow --level 3.2 --bitrate 4300 --ref 5 --min-keyint 30 --keyint 300 --bframes 3 --ratetol 2.0 --merange 32 --direct temporal --aq-mode 2 --no-fast-pskip --no-dct-decimate --sar 1:1 --weightp 2 --aud

avis [info]: 1184x666 @ 30.00 fps (60 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Slow
x264 [info]: profile Main, level 3.2
x264 [info]: frame I:1 Avg QP:19.00 size: 837
x264 [info]: frame P:27 Avg QP:16.57 size: 25239
x264 [info]: frame B:32 Avg QP:17.53 size: 15440
x264 [info]: consecutive B-frames: 6.8% 47.5% 45.8% 0.0%
x264 [info]: mb I I16..4: 100.0% 0.0% 0.0%
x264 [info]: mb P I16..4: 51.7% 0.0% 0.0% P16..4: 37.5% 0.0% 0.0% 0.0% 0
.0% skip:10.8%
x264 [info]: mb B I16..4: 26.0% 0.0% 0.0% B16..8: 31.0% 0.0% 0.0% direct:
15.6% skip:27.3% L0:22.7% L1:25.1% BI:52.2%
x264 [info]: final ratefactor: 11.82
x264 [info]: coded y,uvDC,uvAC intra: 46.3% 32.4% 12.7% inter: 35.7% 27.6% 6.6%
x264 [info]: i16 v,h,dc,p: 42% 33% 17% 8%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 0% 0% 100% 0% 0% 0% 0% 0% 0%
x264 [info]: Weighted P-Frames: Y:88.9%
x264 [info]: kb/s:4705.40

encoded 60 frames, 7.92 fps, 4705.40 kb/s
avis [info]: 1184x666 @ 30.00 fps (60 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Slow
x264 [info]: profile High, level 3.2
x264 [info]: frame I:1 Avg QP:16.00 size: 871
x264 [info]: frame P:27 Avg QP:16.37 size: 23208
x264 [info]: frame B:32 Avg QP:17.68 size: 15064
x264 [info]: consecutive B-frames: 6.8% 47.5% 45.8% 0.0%
x264 [info]: mb I I16..4: 100.0% 0.0% 0.0%
x264 [info]: mb P I16..4: 13.1% 20.3% 2.4% P16..4: 30.9% 14.7% 6.3% 0.3% 0
.2% skip:11.8%
x264 [info]: mb B I16..4: 3.0% 5.9% 0.4% B16..8: 37.5% 3.5% 3.7% direct:
16.5% skip:29.4% L0:32.0% L1:35.8% BI:32.2%
x264 [info]: 8x8 transform intra:54.0% inter:66.5%
x264 [info]: coded y,uvDC,uvAC intra: 41.9% 27.4% 9.1% inter: 41.4% 24.7% 5.9%
x264 [info]: i16 v,h,dc,p: 66% 20% 6% 8%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 11% 17% 15% 5% 9% 7% 16% 6% 14%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 12% 19% 9% 5% 15% 8% 17% 5% 9%
x264 [info]: Weighted P-Frames: Y:88.9%
x264 [info]: ref P L0: 64.9% 1.1% 8.5% 0.6% 24.3% 0.3% 0.2%
x264 [info]: ref B L0: 93.6% 4.5% 1.1% 0.8%
x264 [info]: kb/s:4438.10

[poisondeathray]

^Do you think 60frames is enough? or an accurate or valid representation? It might be 1 GOP. Perhaps try on a decent sample length?

[juGGaKNot]

i saw good results on large clip than i encoded 6 minutes and i opened it, first fade was bad

so i tried a small sample, now encoding a large one and making a 60 seconds sample, fades only

[ajp_anton]

Are you insane or do you have a miscompiled build?

Smart weighting (203.99 kb/s):
http://i37.tinypic.com/111ijah.png

No smart weighting (281.83 kb/s):
http://i36.tinypic.com/289wwts.pngWhy does the left roof destroy the otherwise much better first picture? Or is that actually how the source looks like?

[Dark Shikari]

Why does the left roof destroy the otherwise much better first picture? Or is that actually how the source looks like?I'm pretty sure it's how the source looks. Check LosslessMaikaze.mkv on mirror05.

[juGGaKNot]

--preset veryslow --level 3.2 --bitrate 4300 --ref 5 --min-keyint 30 --keyint 300 --bframes 3 --ratetol 2.0 --merange 32 --direct temporal --aq-mode 2 --no-fast-pskip --no-dct-decimate --sar 1:1 --aud

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 / wpredp=2
/ 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
/ ip_ratio=1.40 / aq=2:1.00

Encoding X264 :

avis [info]: 1184x666 @ 30.00 fps (10800 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Slow
x264 [info]: profile Main, level 3.2
x264 [info]: frame I:116 Avg QP:21.45 size: 61227
x264 [info]: frame P:4608 Avg QP:24.67 size: 25584
x264 [info]: frame B:6076 Avg QP:27.46 size: 11411
x264 [info]: consecutive B-frames: 10.0% 29.7% 38.3% 22.0%
x264 [info]: mb I I16..4: 33.2% 0.0% 66.8%
x264 [info]: mb P I16..4: 38.7% 0.0% 0.0% P16..4: 49.8% 0.0% 0.0% 0.0% 0
.0% skip:11.6%
x264 [info]: mb B I16..4: 10.3% 0.0% 0.0% B16..8: 53.6% 0.0% 0.0% direct:
2.6% skip:33.5% L0:36.7% L1:43.9% BI:19.5%
x264 [info]: final ratefactor: 21.38
x264 [info]: coded y,uvDC,uvAC intra: 47.1% 32.3% 8.2% inter: 28.7% 11.1% 3.2%
x264 [info]: i16 v,h,dc,p: 33% 26% 21% 19%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 19% 25% 13% 6% 8% 6% 10% 6% 8%
x264 [info]: Weighted P-Frames: Y:11.3%
x264 [info]: kb/s:4318.31

encoded 10800 frames, 12.39 fps, 4318.31 kb/s
avis [info]: 1184x666 @ 30.00 fps (10800 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Slow
x264 [info]: profile High, level 3.2
x264 [info]: frame I:116 Avg QP:22.63 size: 59549
x264 [info]: frame P:4608 Avg QP:25.73 size: 23512
x264 [info]: frame B:6076 Avg QP:28.36 size: 12892
x264 [info]: consecutive B-frames: 10.0% 29.7% 38.3% 22.0%
x264 [info]: mb I I16..4: 14.9% 75.2% 9.9%
x264 [info]: mb P I16..4: 7.8% 17.7% 1.6% P16..4: 37.3% 11.1% 8.8% 0.3% 0
.2% skip:15.2%
x264 [info]: mb B I16..4: 1.1% 4.3% 0.5% B16..8: 64.8% 2.8% 3.9% direct:
2.0% skip:20.6% L0:47.2% L1:42.6% BI:10.2%
x264 [info]: 8x8 transform intra:67.4% inter:81.8%
x264 [info]: coded y,uvDC,uvAC intra: 59.0% 45.1% 12.7% inter: 28.8% 13.2% 3.4%
x264 [info]: i16 v,h,dc,p: 36% 23% 7% 34%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 11% 11% 5% 8% 13% 11% 17% 10% 15%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 11% 10% 4% 7% 16% 12% 19% 8% 13%
x264 [info]: Weighted P-Frames: Y:11.0%
x264 [info]: ref P L0: 52.6% 12.9% 18.0% 6.5% 5.5% 4.2% 0.4%
x264 [info]: ref B L0: 75.5% 12.0% 7.8% 4.7%
x264 [info]: kb/s:4301.88

encoded 10800 frames, 1.30 fps, 4301.88 kb/s
AVC-H264 import - frame size 1184 x 666 at 30.000 FPS
Import results: 10800 samples - Slices: 116 I 4608 P 6076 B - 1 SEI - 108 IDR
IsoMedia import - track ID 1 - Audio (SR 44100 - 2 channels)
Saving C:\x264\Movie_2D\1.Movie_X264_2D.mp4: 0.500 secs Interleaving

X264 Encoding started at 07:57 PM and finished at 10:31 PM

Overall Encoding started at 07:57 PM and finished at 10:31 PM

AVIsource("C:\x264\movie.avi")
Crop(0, height%2, -width%2, 0)
ConvertToYV12(matrix="PC.601")

http://i286.photobucket.com/albums/ll105/juGGaKNot4cs/fade1.jpg
http://i286.photobucket.com/albums/ll105/juGGaKNot4cs/fade2.jpg

[thewebchat]

Is that a levels bork or are those successive frames?

[juGGaKNot]

Seems to be levels bork, hmm since i changed the 9800gt to 8600gt i'm not recording fullrange, weird

k, no fullrange in avs :

http://i286.photobucket.com/albums/ll105/juGGaKNot4cs/fade1.jpg
http://i286.photobucket.com/albums/ll105/juGGaKNot4cs/fade3.jpg

[Daemon404]

From my personal tests I have concluded that weightp (2) improves ssim at the same bitrate, but makes it worse at the same crf, compared to no weightp. What you see visually follows this.

May not be true in all cases I guess, but at least in everything I tested.

P.S. Tested with --no-psy.

[Sagekilla]

@Daemon404: At the same crf, does the bitrate decrease on the weightp encoded sample? If so, that explains the decrease in SSIM. 2-pass with fixed bitrate is the only way you can really show whether a setting improves quality, as in CRF mode there is a change in bitrate with different options.

[Daemon404]

It decreases obviously. All this means is that weightp redefines crf AGAIN.

[dstln]

Poor crf

[Dark Shikari]

All this means is that weightp redefines crf AGAIN.So let me get this straight. Weightp improves quality and decreases bitrate in a small proportion of frames in a video... so it redefines CRF?

What kind of insane logic is that?

[BoNz1]

Seems to be levels bork, hmm since i changed the 9800gt to 8600gt i'm not recording fullrange, weird

k, no fullrange in avs :


Hey,

It looks like you video is being decoded by two different decoders. The one ontop does not have the DivX logo while the one on the bottom does...

[pelle412]

I'm seeing something I can't explain with weightp = 2. The snapshot below is from a movie intro for rogue pictures. I use x264 build 1332 from www.x264.nl using --preset slower --tune grain with the 3 different weightp options.

http://img687.imageshack.us/img687/1263/snap.png

[Daemon404]

So let me get this straight. Weightp improves quality and decreases bitrate in a small proportion of frames in a video... so it redefines CRF?

What kind of insane logic is that?

No I'm saying it DECREASES quality at the same CRF (at least on thing with lots of fades). Thus using say CRF 18 with and without weightp will yield different perceived qualities.

Edit: Maybe redefined is not the right word here. Maybe "alters the definition of slightly" works better.

[LoRd_MuldeR]

pelle412, look like you either found a bug -or- you got one of those miscompiled builds :rolleyes:

You should provide the shortest possible unprocessed(!) source sample that can be used to re-produce the issue...

[nurbs]

No issues here with that build, but I use different options. Maybe it's the decoder.

[LoRd_MuldeR]

No issues here with that build, but I use different options. Maybe it's the decoder.

CoreAVC 1.x is known to broken with weightp=2, indeed. Did you use CoreAVC, pelle412 ???

If so, please try some libavcodec-based H.264 decoder, such as ffdshow. Or use MPlayer/VLC.

[pelle412]

You should provide the shortest possible unprocessed(!) source sample that can be used to re-produce the issue...

Here's a 100 frame clip encoded with lagarith lossless.

http://www.mediafire.com/?mdnen2hhqq4

[pelle412]

CoreAVC 1.x is known to broken with weightp=2, indeed. Did you use CoreAVC, pelle412 ???

If so, please try some libavcodec-based H.264 decoder, such as ffdshow. Or use MPlayer/VLC.

Ah yes I did use CoreAVC 1.x. Ok that answers that. Thanks!

I tried VLC and it played fine.

[LoRd_MuldeR]

Ah yes I did use CoreAVC 1.x. Ok that answers that. Thanks!

I tried VLC and it played fine.

Note: If your hardware supports it, you can also use CoreAVC in CUDA mode ;)

This way the GPU's built-in decoder chip will do the H.264 decoding, which seems to cope with x264's wheightp=2 setting just fine!

[plonk420]

i'm getting the same with x264.nl's 1332 32bit build with weight-p 2. decoder is coreavc 1.7.0. uploading sample now. it's basically the first 4 seconds of Planet Earth DVD (the PE Diaries). also some panning shots are having issues.

edit: plays ok (at least the intro) with MPC HC's ffmpeg plugin.

edit2: also affects 1.9.5 (cuda-able, but not enabled)

edit3: plays ok with MPC HC DXVA on a 9400GT (once muxed)

i guess i'll check the CoreAVC thread to see if there's a mention of the issue...

[Conquerist]

I looked into this a little more. It seems that the benefit of weightp depends on the number of b-frames used.

The avs script is still the same as before, a slideshow of 39 images with fades that follow the pattern: ORIG, FADE_1, ..., FADE_5, BLACK.
Dissolve(ImageSource("IMG_2040.jpg",end=5).Spline36Resize(1024,768),BlankClip(6,1024,768,"RGB24").KillAudio(),5)

The batch script is now:
for /L %%I in (0,1,8) DO (
for %%J in (0 2) DO (
..\x264.1336 --weightp %%J --bframes %%I --bitrate 1500 --pass 1 --preset slow --ssim --tune ssim "weightp.y4m" --output NUL
..\x264.1336 --weightp %%J --bframes %%I --bitrate 1500 --pass 2 --preset slow --ssim --tune ssim "weightp.y4m" --output "bframes.%%I.weightp.%%J.mp4"
)
))

This is what I observed:
http://i38.tinypic.com/2mph8xj.png
It seems that weight-p becomes detrimental as soon as the number of b-frames is greater than or equal to the number of frames in each fade.

I ran the same script with 3 frames in each fade, and got this:
http://i37.tinypic.com/r8b8np.png
And a chart
http://i33.tinypic.com/14c43sj.png

I got similar results when I used different images in the slide-show avisynth script, so I don't think it's specific to the source. The x264 build used is techouse's r1336 x86.

[RichardA]

Might I ask... are the problems with GCC fixed in the latest x264 sources?

I'm using gcc-4.1.2 on a CentOS 5.2 box and I'm seeing terrible blocking in fades with recent versions of x264 (since weightp was added).

Just wondering if I should look into my settings or upgrade my GCC to resolve this issue.

...Richard.

[Dark Shikari]

Might I ask... are the problems with GCC fixed in the latest x264 sources?

I'm using gcc-4.1.2 on a CentOS 5.2 box and I'm seeing terrible blocking in fades with recent versions of x264 (since weightp was added).Are you using the latest revision (r1342) of x264? If so, what decoder?

[RichardA]

I use the nightly snapshots and x264-snapshot-20091119-2245.tar seems to have all the latest patches in it.

I use a Mac with Perian installed... which might be the problem. I will try some other decoders.

[Mr VacBob]

Perian uses libavcodec, which is fine. Though of course you could compare it to some other libavcodec player to check.

If you're using QuickTime 10, it does a color-corrected playback - this is actually bad for most people since the gamma correction makes blocking more obvious in certain luma ranges. QT 7 doesn't do this.

[benwaggoner]

Note: If your hardware supports it, you can also use CoreAVC in CUDA mode ;)

This way the GPU's built-in decoder chip will do the H.264 decoding, which seems to cope with x264's wheightp=2 setting just fine!
That doesn't make sense. CUDA<>PureVideo, and I'd think for power consumption reasons you'd always want to use PureVideo over CUDA if available.

Or is that just a naming confusion on CoreCodec's part.

[nm]

That doesn't make sense. CUDA<>PureVideo, and I'd think for power consumption reasons you'd always want to use PureVideo over CUDA if available.

Or is that just a naming confusion on CoreCodec's part.

They're using nvcuvid.dll, which is a Windows-only CUDA extension for accessing the hardware video decoder.

[CruNcher]

@ benwaggoner
It's a simple Marketing trick by Nvidia letting it look like the DSP is a CUDA Api feature, and so automatically it gets into the Brain as CUDA Powerfull Video Playback ;)
So always if some 3rd Party ISV says CUDA Video Playback you say ahh the great low power Video Decoding ;)
Pretty Simple CUDA gets associated with Powerfull, hey Microsoft's Marketing has also a lot experience in this type of brainwashing you should know that ;)

[LoRd_MuldeR]

That doesn't make sense. CUDA<>PureVideo, and I'd think for power consumption reasons you'd always want to use PureVideo over CUDA if available.

It does! And I'm very well aware that CUDA isn't PureVideo, I did quite a few projects with CUDA ;)

PureVideo is a "hard wired" decoder hardware for H.264, VC-1 and MPEG-2. At the same time CUDA allows you to run your own custom programs ("Kernels") on the GPU.

Still, as far as I know, CoreAVC did not write their own custom H.264 decoder as CUDA kernels.

Instead they simply call the PureVideo decoder through the CUDA Video API (nvcuvid.dll). So what works (or not works) is primarily defined by NVIDIA's hardwired PureVideo decoder.

And of course you prefer PureVideo over a "real" CUDA implementation, because nothing can beat a dedicated decoder chip, performance- or efficiency-wise.

Well, unless there were some limitations in the PureVideo decoder, which you'd have to circumvent with your own decoder kernels...

[Caroliano]

I looked into this a little more. It seems that the benefit of weightp depends on the number of b-frames used.

Was this problem solved with the following commit?
commit 626affea98f4db9208cbf0e3db78f23804defd0c r1350
Author: Jason Garrett-Glaser <darkshikari@gmail.com>
Date: Tue Nov 24 22:37:02 2009 -0800

Fix bug in weightp analysis
Weights weren't reset upon early terminations, so old (wrong) weights could stick around.
Small compression improvement.
Or it persists? It worries me because I use lots of b-frames (5 or more) for anime.

[Conquerist]

Was this problem solved with the following commit?
commit 626affea98f4db9208cbf0e3db78f23804defd0c r1350
Author: Jason Garrett-Glaser <darkshikari@gmail.com>
Date: Tue Nov 24 22:37:02 2009 -0800

Fix bug in weightp analysis
Weights weren't reset upon early terminations, so old (wrong) weights could stick around.
Small compression improvement.
Or it persists? It worries me because I use lots of b-frames (5 or more) for anime. I just ran the script again, this time with r1360, and got nearly identical results.

[Daemon404]

I just ran the script again, this time with r1360, and got nearly identical results.

Your test clip is too short. Did you even check to see what the bitrate was for each encode (i.e. how it fluctuated?).

I used your own script (only I increased the length of the fade/clip to 82 frames), plus the latest x264 and got this:


bframes | Weightp 0 | Weightp 2 | Improvement
0 | 0.9226378 | 0.9580334 | 84.3423%
1 | 0.9163671 | 0.9677243 | 159.1203%
2 | 0.9332965 | 0.9705456 | 126.4636%
3 | 0.9410543 | 0.9711962 | 104.6456%
4 | 0.9441484 | 0.9733042 | 109.2149%
5 | 0.9485085 | 0.9738196 | 96.6796%
6 | 0.9509609 | 0.9747484 | 94.2020%
7 | 0.9524281 | 0.9747484 | 88.3916%
8 | 0.9582237 | 0.9756665 | 71.6822%
9 | 0.9590654 | 0.9756169 | 67.8810%
10 | 0.9614348 | 0.9758100 | 59.4262%
11 | 0.9574511 | 0.9752792 | 72.1178%
12 | 0.9633627 | 0.9763607 | 54.9847%
13 | 0.9641163 | 0.9763860 | 51.9594%
14 | 0.9647650 | 0.9764071 | 49.3458%
15 | 0.9652498 | 0.9768788 | 50.2958%
16 | 0.9656754 | 0.9767110 | 47.3855%


It shows a clear improvement with any number of bframes.

[Conquerist]

Your test clip is too short. Did you even check to see what the bitrate was for each encode (i.e. how it fluctuated?).

I used your own script (only I increased the length of the fade/clip to 82 frames), plus the latest x264 and got this:

Each fade is 5 frames in length, the first is the original picture, the next 3 are progressively darker, the final image is black. 38 of those clips are concatenated to produce a clip that's 190 frames long. The filesize fluctuated between 1457 kB and 1480 kB.

So I rerun it again, this time with r1373, --b-pyramid none and --b-pyramid normal. The results:

http://img20.imageshack.us/img20/6356/tableab.png
http://img20.imageshack.us/img20/3267/chartl.png