Psy RDO: Official testing thread (version 0.6 out!)

[Dark Shikari]

Well, IMO, a great psychovisual algo would remove all details in areas the human eye can't see at the input brightness, and spend those bits elsewhere ;)I'm not about to start changing x264 to optimize for people with crap quality monitors ;)

On the topic of "300" I've actually found that psy-trellis and even psy-rd help there less than one would think, for some weird reason.

[Sagekilla]

That's one way of interpreting it, psychovisual could remove details we can't perceive -- just like how we remove sounds that are too faint to hear that occur at the same time as very loud sounds in audio compression. Otoh, you got the kinds that try to replicate the original signal using trickery, like SBR in AAC.

Might be a bit of a poor analogy, but that's how I see it. In any case, excellent work Dark Shikari!


Edit: In regards to the latest post DS just made, is there any chance you might of accidentally optimized your algos for that clip?

[Avenger007]

On the topic of "300" I've actually found that psy-trellis and even psy-rd help there less than one would think, for some weird reason.
On a clip I've tested with psy-trellis + psy-rd, it seems to "amplify" the detail to some extent, so some parts look a little more detailed than the original. That's not bad because the detail still looks legit.
Maybe it also amplifies noise, so-much-so that it becomes unstable and is noticeable.

[Dark Shikari]

Edit: In regards to the latest post DS just made, is there any chance you might of accidentally optimized your algos for that clip?The reason psy-trellis doesn't seem to be as good in "300" is that it seems to give best results when you have a balance of fine and coarse detail that need to be retained. 300 has no fine detail; all the grain is pretty large-scale, I think, and quite heavy, so the encoder ends up pressed to do something with it regardless. OK, so just a guess.

I don't think I optimized them specifically for that clip--I find that psy-trellis helps in general with subtle grain and detail, and sharpens non-grainy stuff. It should (ideally, at least) effectively eliminate all cases where deadzones beat trellis visually.

[cogman]

So, is there any estimation when this will be included in the stream. I would love to be able to compile x264 without applying these patches (Im lazy).

Good work over all, it's great to see x264 improve by such leaps and bounds. (and frustrating to have to re-encode my stuff because of it :P)

[Sagekilla]

I wonder how well it would work when you remove most of the grain from 300 then, considering I almost always remove grain now since I prefer the cleaner look and MUCH smaller file sizes..

[ToS_Maverick]

well I think it will be like encoding black pearl denoised... cleaner look and with the psy patches the dither is kept (if ditherd with gradfun)!

[Ranguvar]

Yeah, I always do an FFT3DGPU with different settings for each source to do some light degraining. I err on the side of caution, and only do a little degraining, but it helps a ton. Also, de-haloing can help a lot too :) Lots of DVDs (The Mummy) have it in spades. Psy improvements just change how x264 seems to deal with grain. Before, it smoothed it out, now it preserves most of it, which means you should remove a good bit or pay :p

[Blue_MiSfit]

Man...

I'm really impressed.

http://www.funnyforumpics.com/forums/This-Thread-Delivers/1/deliverslm9.jpg (http://www.funnyforumpics.com)

..sorry, I had to do it ;)

Keep up the awesome work, DS!

~miSfit

[Terranigma]

Someone wants to post a compile?

[Dark Shikari]

Someone wants to post a compile?See the current patches thread...

[LoRd_MuldeR]

Someone wants to post a compile?

In case you missed it, it's here:
http://forum.doom9.org/showpost.php?p=1167186&postcount=647 ;)

[foxyshadis]

Well, IMO, a great psychovisual algo would remove all details in areas the human eye can't see at the input brightness, and spend those bits elsewhere ;) But that's debatable (as all psy algos are). Point is, psy-trellis r0x0rz.

This is what you have avisynth for: Optimizing to your environment. x264 already somewhat optimizes for the case of imperfect eyes on a high quality screen, that's the whole point of this patch, just like lame optimizes for imperfect (but 'golden') ears through high quality headphones. If you somehow can't hear 11200-11400Hz but can hear the rest, or more to the point, if your lousy speakers & acoustics can't reproduce sound in that range, you have to use pre-filtering with an audio editor to remove them if you want to save that bandwidth. Same here, use avisynth to remove what you can't see on your screen.

[Ranguvar]

True.

[Dr.D]

The power of psy-trellis + psy-RD:

http://i35.tinypic.com/rk33wx.png







The above P-frame is from the first 500 frames of BlackPearl... encoded at 400kbps.

Here's the same frame from a certain widely-renowned commercial encoder (http://i34.tinypic.com/qp53s0.png).
Could you please post the parameters? If not, what crf did you use? Thanks.

[gigah72]

i made some test encodes (movie: 300, Hero) with CRF and i get a massive increase in filesize when i add --trellis 1 to --b-adapt 2 (with latest patches).
is this normal to happen or what is the reason?

[Sharktooth]

both patches are experimental so... yes weird things may happen.

[Dark Shikari]

Could you please post the parameters? If not, what crf did you use? Thanks.
$ ./x264.exe --deblock -3:-3 input.avs --frames 500 -o test_new.h264 --ref 16 --mixed-refs --weightb --partitions all --subme 7 --8x8dct --trellis 2 --b-rdo --bframes 3 --b-pyramid --progress --pass 2 --pre-scenecut --bitrate 400 --psy-rd 1.0 --bime --direct auto --no-fast-pskip --me tesa --merange 32
both patches are experimental so... yes weird things may happen.Psy RDO and Psy Trellis both raise quants at a given bitrate, or raise bitrate at given quants.

[Sharktooth]

rise quants? it should result in a lower filesize then...

[Dark Shikari]

rise quants? it should result in a lower filesize then...No... at the same bitrate, you need higher quants to keep the same bitrate. Therefore, at the same quants, you'll get higher bitrate.

[Sharktooth]

ok, got it.
at this point CQMs are completely useless.

[Adub]

Thank God!! I have always felt that "maybe...if I just try this...tweak a few coefficients...blah blah" about CQM's, so knowing that they wont really help me anymore is a good thing.

[smok3]

so it is either : defined borders or better complexity approximation? Can we have both?

[poisondeathray]

While the detail preservation are just amazing (especially at 400kbps), there is more ringing/artifacting visible - note especially around the fire.

Now the other images were of a different frame - so can't come to any conclusions - and Dark S. used -3,-3 for this encode (not sure what deblock settings were used for the earlier frame caps)

[Dark Shikari]

While the detail preservation are just amazing (especially at 400kbps), there is more ringing/artifacting visible - note especially around the fire. This is partially why it gets better detail preservation; in the other frame from a Competing Encoder (TM) I showed for comparison, a large percentage of bits in the entire frame were devoted just to the fire, hurting quality everywhere else.

If you think the ringing was a bit overboard, that's the fault of AQ, which might have been a bit too strong at 1.0.

[poisondeathray]

Actually I was comparing to the frame shots posted a few pages back as well, especially the one of the "source"; like i said, it was a different frame and different settings (I think).

When comparing to the competing encoder, you can also see the ringing/artifacting, BUT there is much less detail preservation with the rest of the frame - at least in my eyes

Just curious, what is the Competing Encoder (TM) ?:)

[Sagekilla]

Wow. I barely even saw the artifacts in the fire, even when I looked closely at the fire. Might have to do with the fact that my eyes were focused on Jack though. In any case, the fire looks hardly bad.

[Dark Shikari]

Just curious, what is the Competing Encoder (TM) ?:)Ateme Digital Series ;)

[Quark.Fusion]

ok, got it.
at this point CQMs are completely useless.

Did it means that you test it or just an assumption? What was result — it's same quality or worse versus flat matrix? (I'm talking about your AVC CQM HR (http://www.webalice.it/f.corriga/x264/eqm_avc_hr.cfg))

[Shinigami-Sama]

Did it means that you test it or just an assumption? What was result — it's same quality or worse versus flat matrix? (I'm talking about your AVC CQM HR (http://www.webalice.it/f.corriga/x264/eqm_avc_hr.cfg))

it just means that CQMs are no longer of any benefit because their use has been superceded by psy-rdo/psy-trellis

[TheRyuu]

So is it better to use psyTrellis and get higher quants with it? or not use it and get lower quants with regular trellis...

Or would this depend on the source...?

[DarkZell666]

So is it better to use psyTrellis and get higher quants with it? or not use it and get lower quants with regular trellis...

Or would this depend on the source...?

What do your eyes have to say on the matter ? There is no "better" from a theoretical standpoint. It's like asking if someone prefers Coca-Cola or Pepsi. One could argue either of them has more sugar, more taste, more bubbles, etc., but what matters is that the effect of psyTrellis gives improved subjective quality for YOU ("better" taste). Some people prefer the bubbles, others prefer the sugar !

Several people have reported x264 tasting better with psyTrellis enabled, as you might have read earlier in the thread. The question is : do you ? ;)

[Caroliano]

[url=So is it better to use psyTrellis and get higher quants with it? or not use it and get lower quants with regular trellis...[/url]
You should compara wich gives better quality for you in an given bitrate. So use 2-pass for the tests (then after you can use CRF for regular encodes).

There is any build with psyrdo 0.5 and --fgo? I wanted to compare both in anime with gradfunkmirror(). FGO already gave very good results, but I'm afraid of comparing encodes from two very distant revisions.

[fachman]

I have tested two non official builds.
First it is from komisar666.gin.by which is Psyrd0.5+normal trellis+VAQ2 and gave me the following results:

--[NoImage] Job commandline: "C:\Program Files (x86)\megui\tools\x264\x264.exe" --pass 2 --bitrate 650 --stats "05.stats" --level 3.1 --keyint 99999 --ref 4 --mixed-refs --no-fast-pskip --bframes 16 --b-rdo --bime --weightb --direct auto --subme 7 --trellis 2 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --qpmin 24 --qpmax 35 --qpstep 13 --pbratio 2.1 --ratetol 100 --qcomp 0 --cplxblur 2 --scenecut 100 --me umh --merange 64 --threads auto --thread-input --progress --[Information] [2008-08-09 05:42:52] Encoding started
--[NoImage] Standard output stream:
--[NoImage] Standard error stream
---[NoImage] avis [info]: 1280x720 @ 25.00 fps (183160 frames)
---[NoImage] x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
---[NoImage] x264 [info]: cabac=1 ref=4 deblock=1:0:0 analyse=0x3:0x113 me=umh subme=7 psy_rd=1.000000 brdo=1 mixed_ref=1 me_range=64 chroma_me=1 trellis=2 8x8dct=1 cqm=0 deadzone=21,11 chroma_qp_offset=0 threads=6 nr=0 decimate=1 mbaff=0 bframes=16 b_pyramid=0 b_adapt=1 b_bias=0 direct=3 wpredb=1 bime=1 keyint=99999 keyint_min=25 scenecut=100(pre) rc=2pass bitrate=650 ratetol=100.0 rceq='blurCplx^(1-qComp)' qcomp=0.00 qpmin=24 qpmax=35 qpstep=13 cplxblur=2.0 qblur=0.5 ip_ratio=1.40 pb_ratio=2.10 aq=3:11:1.00
---[NoImage] mp4 [info]: initial delay 1 (scale 25)
---[NoImage]
---[NoImage] x264 [info]: slice I:319 Avg QP:26.21 size: 13552 PSNR Mean Y:46.06 U:49.60 V:50.00 Avg:46.92 Global:45.74
---[NoImage] x264 [info]: slice P:82918 Avg QP:28.27 size: 5621 PSNR Mean Y:43.88 U:47.64 V:48.00 Avg:44.76 Global:43.48
---[NoImage] x264 [info]: slice B:99923 Avg QP:32.97 size: 1199 PSNR Mean Y:42.60 U:47.12 V:47.46 Avg:43.59 Global:42.57
---[NoImage] x264 [info]: consecutive B-frames: 19.4% 25.2% 12.9% 17.5% 18.4% 5.4% 0.4% 0.0% 0.1% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.6%
---[NoImage] x264 [info]: mb I I16..4: 52.9% 44.8% 2.3%
---[NoImage] x264 [info]: mb P I16..4: 8.7% 5.0% 0.1% P16..4: 39.2% 3.0% 3.2% 0.0% 0.0% skip:40.7%
---[NoImage] x264 [info]: mb B I16..4: 0.1% 0.1% 0.0% B16..8: 20.9% 0.2% 0.2% direct: 0.3% skip:78.2% L0:32.1% L1:66.6% BI: 1.3%
---[NoImage] x264 [info]: final AQ sensitivity: 8.0000
---[NoImage] x264 [info]: 8x8 transform intra:36.7% inter:90.5%
---[NoImage] x264 [info]: direct mvs spatial:95.6% temporal:4.4%
---[NoImage] x264 [info]: ref P L0 70.4% 16.2% 9.8% 3.6%
---[NoImage] x264 [info]: ref B L0 91.1% 5.5% 3.4%
---[NoImage] x264 [info]: SSIM Mean Y:0.9802356
---[NoImage] x264 [info]: PSNR Mean Y:43.183 U:47.360 V:47.709 Avg:44.128 Global:42.962 kb/s:644.48
---[NoImage] encoded 183160 frames, 12.17 fps, 644.50 kb/s


The second one is PSYRD05+PSYTRELLIS and gave me the following results:

--[NoImage] Job commandline: "C:\Program Files (x86)\megui\tools\x264\x264.exe" --pass 2 --bitrate 650 --stats 05.stats" --level 3.1 --keyint 99999 --ref 4 --mixed-refs --no-fast-pskip --bframes 16 --b-rdo --bime --weightb --direct auto --subme 7 --trellis 2 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --qpmin 24 --qpmax 35 --qpstep 13 --pbratio 2.1 --ratetol 100 --qcomp 0 --cplxblur 2 --scenecut 100 --me umh --merange 64 --threads auto --thread-input --progress ----[Information] [2008-08-08 09:45:04] Encoding started
--[NoImage] Standard output stream:
--[NoImage] Standard error stream
---[NoImage] avis [info]: 1280x720 @ 25.00 fps (183160 frames)
---[NoImage] x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
---[NoImage] mp4 [info]: initial delay 1 (scale 25)
---[NoImage] x264 [info]: slice I:319 Avg QP:25.89 size: 15960 PSNR Mean Y:46.26 U:51.33 V:51.77 Avg:47.37 Global:46.43
---[NoImage] x264 [info]: slice P:82918 Avg QP:28.59 size: 5800 PSNR Mean Y:43.27 U:48.90 V:49.31 Avg:44.44 Global:43.36
---[NoImage] x264 [info]: slice B:99923 Avg QP:35.47 size: 1093 PSNR Mean Y:41.36 U:47.78 V:48.17 Avg:42.61 Global:41.86
---[NoImage] x264 [info]: consecutive B-frames: 19.4% 25.2% 12.9% 17.5% 18.4% 5.4% 0.4% 0.0% 0.1% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.6%
---[NoImage] x264 [info]: mb I I16..4: 45.3% 52.9% 1.8%
---[NoImage] x264 [info]: mb P I16..4: 8.4% 5.9% 0.1% P16..4: 39.1% 2.4% 3.2% 0.0% 0.0% skip:40.8%
---[NoImage] x264 [info]: mb B I16..4: 0.1% 0.1% 0.0% B16..8: 17.5% 0.1% 0.2% direct: 0.3% skip:81.7% L0:33.8% L1:64.7% BI: 1.4%
---[NoImage] x264 [info]: 8x8 transform intra:41.6% inter:89.4%
---[NoImage] x264 [info]: direct mvs spatial:96.1% temporal:3.9%
---[NoImage] x264 [info]: ref P L0 71.3% 15.8% 9.4% 3.4%
---[NoImage] x264 [info]: ref B L0 90.8% 5.7% 3.5%
---[NoImage] x264 [info]: SSIM Mean Y:0.9774826
---[NoImage] x264 [info]: PSNR Mean Y:42.234 U:48.297 V:48.692 Avg:43.449 Global:42.484 kb/s:649.96
---[NoImage] encoded 183160 frames, 12.62 fps, 649.99 kb/s

When I compare those two encodes I feel that KOMISAR666 is doing the better job, even creating smaller size. I think it is because the quantizer of B-frames is way too low...

[Dark Shikari]

When I compare those two encodes I feel that KOMISAR666 is doing the better job, even creating smaller size. I think it is because the quantizer of B-frames is way too low...Numbers tell us nothing; visuals tell us everything.

Also, testing builds that I have no idea about is a rather bad idea, because for all I know they've tweaked other settings randomly too (such as pbratio).

[kemuri-_9]

can the .diff be updated for latest x264 revisions (rev 929 specifically has the particular change in it),
since there's currently a rejection for the psyrdo 0.5+ psy trellis .diff:
encoder.c.rej
***************
*** 411,416 ****
h->param.analyse.b_fast_pskip = 0;
h->param.analyse.i_noise_reduction = 0;
h->param.analyse.i_subpel_refine = x264_clip3( h->param.analyse.i_subpel_refine, 1, 6 );
}
if( h->param.rc.i_rc_method == X264_RC_CQP )
{
--- 411,417 ----
h->param.analyse.b_fast_pskip = 0;
h->param.analyse.i_noise_reduction = 0;
h->param.analyse.i_subpel_refine = x264_clip3( h->param.analyse.i_subpel_refine, 1, 6 );
+ h->param.analyse.f_psy_rd = 0;
}
if( h->param.rc.i_rc_method == X264_RC_CQP )
{


as the bold line is no longer existent in the main code.
I fixed the .diff to workaround it for my own use, but other people will have problems

[Dark Shikari]

can the .diff be updated for latest x264 revisions (rev 929 specifically has the particular change in it),
since there's currently a rejection for the psyrdo 0.5+ psy trellis .diff:
***************
*** 411,416 ****
h->param.analyse.b_fast_pskip = 0;
h->param.analyse.i_noise_reduction = 0;
h->param.analyse.i_subpel_refine = x264_clip3( h->param.analyse.i_subpel_refine, 1, 6 );
}
if( h->param.rc.i_rc_method == X264_RC_CQP )
{
--- 411,417 ----
h->param.analyse.b_fast_pskip = 0;
h->param.analyse.i_noise_reduction = 0;
h->param.analyse.i_subpel_refine = x264_clip3( h->param.analyse.i_subpel_refine, 1, 6 );
+ h->param.analyse.f_psy_rd = 0;
}
if( h->param.rc.i_rc_method == X264_RC_CQP )
{


as the bold line is no longer existent in the main code.
I fixed the .diff to workaround it for my own use, but other people will have problemsIf you fixed it you could post the fixed version... ;)

[LoRd_MuldeR]

LoRd_MuldeR@MULDER_NEU /c/downloads/x264_git/x264
$ patch -p1 < ../psy-trellis.diff
patching file `common/common.c'
patching file `common/common.h'
patching file `common/dct.h'
patching file `encoder/analyse.c'
Hunk #2 succeeded at 1045 (offset 1 line).
Hunk #4 succeeded at 2078 (offset 1 line).
Hunk #6 succeeded at 2395 (offset 1 line).
patching file `encoder/encoder.c'
Hunk #1 FAILED at 411.
Hunk #2 succeeded at 484 (offset 1 line).
1 out of 2 hunks FAILED -- saving rejects to encoder/encoder.c.rej
patching file `encoder/macroblock.c'
patching file `encoder/macroblock.h'
patching file `encoder/rdo.c'
Hunk #2 succeeded at 330 (offset 2 lines).
Hunk #4 succeeded at 491 (offset 2 lines).
patching file `x264.c'
patching file `x264.h'

If you fixed it you could post the fixed version... ;)

Would be very welcome :)

[kemuri-_9]

ic how it is....
x264_psy_rdo.0.5+psy_trellis_01_r929.diff (http://kemuri9.net/dev/x264/patches/x264_psy_rdo.0.5+psy_trellis_01_r929.diff)

[LoRd_MuldeR]

ic how it is....
x264_psy_rdo.0.5+psy_trellis_01_r929.diff (http://kemuri9.net/dev/x264/patches/x264_psy_rdo.0.5+psy_trellis_01_r929.diff)

Working. Thank you!

[fachman]

Dear Dark Shikari

As for my builds the first is taken from http://komisar666.gin.by. It uses a lot of minor patches, but its list has been recently removed from the site. Most of them are minor but main are VAQ2 and PSYRDO05

The second one is SKYSTRIFE build
x264.928.modified.02.exe - Alternate Download
libx264-61.928.modified.02.dll - Alternate Download
(Source) - Alternate Download

Patches used:

x264_psyRDO_0.5+psytrellis.diff <-- This patch is experimental. See the PsyRDO thread for more details.
x264_new_bframe_decision_03.diff <-- This patch is highly experimental.
x264_hrd_pulldown.09_interlace.diff
x264.progress.indication.01.diff

gcc 3.4.5 fprofiled build.

I have also tweaked a bit bitrate to compare KOMISAR666 build at the same bitrate as SKYSTRIFE and received the following result:
--[NoImage] Job commandline: "C:\Program Files (x86)\megui\tools\x264\x264.exe" --pass 2 --bitrate 655 --stats "05.stats" --level 3.1 --keyint 99999 --ref 4 --mixed-refs --no-fast-pskip --bframes 16 --b-rdo --bime --weightb --direct auto --subme 7 --trellis 2 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --qpmin 24 --qpmax 35 --qpstep 13 --pbratio 2.1 --ratetol 100 --qcomp 0 --cplxblur 2 --scenecut 100 --me umh --merange 64 --threads auto --thread-input --progress --
--[Information] [2008-08-09 10:08:11] Encoding started
--[NoImage] Standard output stream:
--[NoImage] Standard error stream
---[NoImage] avis [info]: 1280x720 @ 25.00 fps (183160 frames)
---[NoImage] x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
---[NoImage] x264 [info]: cabac=1 ref=4 deblock=1:0:0 analyse=0x3:0x113 me=umh subme=7 psy_rd=1.000000 brdo=1 mixed_ref=1 me_range=64 chroma_me=1 trellis=2 8x8dct=1 cqm=0 deadzone=21,11 chroma_qp_offset=0 threads=6 nr=0 decimate=1 mbaff=0 bframes=16 b_pyramid=0 b_adapt=1 b_bias=0 direct=3 wpredb=1 bime=1 keyint=99999 keyint_min=25 scenecut=100(pre) rc=2pass bitrate=655 ratetol=100.0 rceq='blurCplx^(1-qComp)' qcomp=0.00 qpmin=24 qpmax=35 qpstep=13 cplxblur=2.0 qblur=0.5 ip_ratio=1.40 pb_ratio=2.10 aq=3:11:1.00
---[NoImage] mp4 [info]: initial delay 1 (scale 25)
---[NoImage]
---[NoImage] x264 [info]: slice I:319 Avg QP:26.16 size: 13626 PSNR Mean Y:46.09 U:49.63 V:50.03 Avg:46.95 Global:45.78
---[NoImage] x264 [info]: slice P:82918 Avg QP:28.19 size: 5672 PSNR Mean Y:43.93 U:47.68 V:48.04 Avg:44.81 Global:43.53
---[NoImage] x264 [info]: slice B:99923 Avg QP:32.94 size: 1199 PSNR Mean Y:42.62 U:47.14 V:47.49 Avg:43.62 Global:42.60
---[NoImage] x264 [info]: consecutive B-frames: 19.4% 25.2% 12.9% 17.5% 18.4% 5.4% 0.4% 0.0% 0.1% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.6%
---[NoImage] x264 [info]: mb I I16..4: 52.6% 45.1% 2.3%
---[NoImage] x264 [info]: mb P I16..4: 8.7% 5.0% 0.1% P16..4: 39.4% 3.0% 3.3% 0.0% 0.0% skip:40.5%
---[NoImage] x264 [info]: mb B I16..4: 0.1% 0.1% 0.0% B16..8: 21.0% 0.2% 0.2% direct: 0.3% skip:78.1% L0:32.1% L1:66.6% BI: 1.3%
---[NoImage] x264 [info]: final AQ sensitivity: 8.0000
---[NoImage] x264 [info]: 8x8 transform intra:37.0% inter:90.5%
---[NoImage] x264 [info]: direct mvs spatial:95.6% temporal:4.4%
---[NoImage] x264 [info]: ref P L0 70.5% 16.1% 9.8% 3.6%
---[NoImage] x264 [info]: ref B L0 91.1% 5.5% 3.4%
---[NoImage] x264 [info]: SSIM Mean Y:0.9803899
---[NoImage] x264 [info]: PSNR Mean Y:43.218 U:47.390 V:47.740 Avg:44.163 Global:43.001 kb/s:649.16
---[NoImage] encoded 183160 frames, 12.07 fps, 649.19 kb/s

As you might notice I am using completelly different encoding settings than anybody else. Those settings IMHO are optimal for receive maximum quality at low bitrates and are the result of one year of my research (some people are using their compute power to SETI, I use my compute power to test every x264 setting).
I will post a separate thread about my findings. Now I only tell you that PBRATIO=2.1 unleash the true power of Bframes. I am not sure why 2.1, but with this setting I receive at least 1dB of PSNR extra. With this setting you can see the difference with increased number of B frames (from 1 to 16), which is as you know is hardly to notice with PBRATIO=1.3
My personal theory is the Bframes are put in so simple positions that the temporaly lowering the quality of the scene (plus 6QP) does not affect the quality of the movie, while allows the saving bits to be put elsewhere where the difference is noticeable, but I am not the developer.

Keep up the good work

[Dark Shikari]

I will post a separate thread about my findings. Now I only tell you that PBRATIO=2.1 unleash the true power of Bframes.x264 isn't Xvid.

Xvid had an absurdly high pbratio--and we all know how that turned out... :scared:

Personally, I think consistent quality is much more important than anything else--decimating half of your frames to improve overall PSNR is not going to be a good idea visually. Its great though if all you ever do is compare individual P-frames... ;)
(x86)\megui\tools\x264\x264.exe" --pass 2 --bitrate 655 --stats "05.stats" --level 3.1 --keyint 99999 --ref 4 --mixed-refs --no-fast-pskip --bframes 16 --b-rdo --bime --weightb --direct auto --subme 7 --trellis 2 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --qpmin 24 --qpmax 35 --qpstep 13 --pbratio 2.1 --ratetol 100 --qcomp 0 --cplxblur 2 --scenecut 100 --me umh --merange 64 --threads auto --thread-input --progress --These are nonsense settings.

1. An extremely high keyint is going to screw up scenecut detection.
2. Your qpmin/qpmax settings are crippling AQ.
3. Qcomp 0 is retarded, even in CBR mode.
4. Scenecut 100 is going to screw up scenecut detection even more.
5. You're using --level 3.1, but you're ignoring the VBV implications of that.
6. Ratetol does nothing on the second pass (AFAIK).
7. Stop touching the ratecontrol parameters, seriously. qpstep does basically nothing outside of VBV mode.

[Sagittaire]

As you might notice I am using completelly different encoding settings than anybody else. Those settings IMHO are optimal for receive maximum quality at low bitrates and are the result of one year of my research (some people are using their compute power to SETI, I use my compute power to test every x264 setting).

Well I think that your setting are completely ridiculous:
--keyint 99999: useless. codec will use scenecut for iframe. default is good if you don't use particular hardware profil.

--bframes 16: useless too. more than 3 bframe don't help really. Here good setting for bframe: --bframe 3 --b-pyramid --b-rdo --bime --weightb

--partitions p8x8,b8x8,i4x4,i8x8: why use always this command. use simply --partitions "all"

--qpmin 24 --qpmax 35 --qpstep 13 --ratetol 100 --cplxblur 2: don't touch the RC if you don't know exactly what you do.

--pbratio 2.1: poor quality for bframe. IMO really better to use low ratio for constant local quality.

--merange 64: slow and useless for quality. default is good

--qcomp 0: useless with VAQ and it's absurd setting because it's CBR mode.



Try that ... better quality and better speed:


x264.exe --bframe 3 --b-pyramid --b-rdo --bime --weightb --ref 5 --mixed-refs --direct auto --deblock -1:-1 --bitrate 447 --pass 2 --stats "x264_stat.log" --min-keyint 1 --ipratio 1.25 --pbratio 1.30 --partitions "all" --8x8dct --me "umh" --subme 7 --no-fast-pskip --no-dct-decimate --trellis 2 --aq-strength 0.5 --aq-mode 2 --progress -o x264HP-450.mp4 Encodage.avs

[Soichiro]

--partitions p8x8,b8x8,i4x4,i8x8: why use always this command. use simply --partitions "all"

I agree with most of what you said, but not using all partitions is a good idea because p4x4 is practically useless and will just slow things down, as well as break hardware compatibility. Also, yeah, 16 bframes is useless for live action, though it does have uses in animated material. Since I can't exactly find what type of clip was being tested, though, I can't really say which it was, but from the stats it looks like it was live action (low bframe counts).

[Sagittaire]

I agree with most of what you said, but not using all partitions is a good idea because p4x4 is practically useless and will just slow things down, as well as break hardware compatibility. Also, yeah, 16 bframes is useless for live action, though it does have uses in animated material. Since I can't exactly find what type of clip was being tested, though, I can't really say which it was, but from the stats it looks like it was live action (low bframe counts).

- x264 will use 16 bframe only for really static scene without really saving bit in this case. It's like use 16 ref ... it's in practice useless.

- You break hardware compatibility with 16 bframes certainely more than with --partitions "all".

[tetsuo55]

What are the official b-frame limits for each level?

[Manao]

None. Either you allow bframes (and an arbitrary consecutive number of them) or you don't. 16 is a limitation coming from x264.

[tetsuo55]

None. Either you allow bframes (and an arbitrary consecutive number of them) or you don't. 16 is a limitation coming from x264.

So the fact that one or more hardware decoders crash with high number of bframes is a bug in the decoding hardware? (or a sneaky way to make cheaper decoder chips)

[Manao]

It's not even a cheap way. I just don't understand how they could crash because there's too many bframes in a row. 16 bframes in a row don't require more memory than 1.

[Sergey A. Sablin]

it's only true for plain B-frames, pyramid requires additional space in DPB for correct output.