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

[bkman]

I've actually noticed the Quants being unusually low using PsyRDO 0.5.

Btw Dark Shikari, my testing shows that the previous bug with the algorithm seems to have been fixed. And with the improvements in 0.5 besides its truly an amazing difference. Between AQ and Psy ROD, congrats on finally making x264 behave admirably no matter the characteristics of the source! It's great work and really simplifies the encoding process.

Now we just need a quality metric that will reflect the visual benefit of your psy algorithm, as SSIM doesn't seem to cut it anymore :P

[SilentTweak]

I've tried skimming through all 13 pages but I'm still a bit confused about a few things, if someone could answer these with a simple answer that'd be great:

1. Is psyRDO always on if I'm using the patch builded in this thread?
2. If so, is it okay to use 2-pass encode profiles or is it only for CFR?

Just some stuff people have been posting in the last few replies made things really confusing.

[LoRd_MuldeR]

I've tried skimming through all 13 pages but I'm still a bit confused about a few things, if someone could answer these with a simple answer that'd be great:

1. Is psyRDO always on if I'm using the patch builded in this thread?
2. If so, is it okay to use 2-pass encode profiles or is it only for CFR?

Just some stuff people have been posting in the last few replies made things really confusing.

1. Psy RDO is on by default (with default strength), but only if you use a x264 build with "Psy RDO" patch
2. It works with 2-Pass as well as with CRF, but it will make your files a bit bigger in CRF mode

The comment that Psy RDO has to be used with 2-Pass mode was only for testing Psy RDO against no Psy RDO.
That's because if you want to compare the quality of two encodes, they need to have the same size...

If you just want to use Psy RDO for your regular encodes then CRF is 100% fine :)

[SilentTweak]

Thanks for the quick reply Mulder :)

[Sharktooth]

also, it may sound obvious but it's better to be specific, PsyRDO works only in RDO modes (subme>=6)

[SilentTweak]

also, it may sound obvious but it's better to be specific, PsyRDO works only in RDO modes (subme>=6)

Okay well my profile uses subme=7 so I should be okay right? Also, are there any disadvantages to using this at low bitrates? Like 400kbps for SD res.

[smok3]

my try
insane, psyrdo should be default;
http://somestuff.org/flashAVC/flvplayer.php?moviename=movies/bbb_insane-x640y352.mp4
(in this sample: it seems to me as if the backgrounds have some decent texture now, but the foregrounds are over-sharpened, but i can be imagining things)

will try the same later with disabled psyrdo.

[Sharktooth]

it looks damn good to me being a 480kbps encode.
try with deblock 0,0 or -1,0 or 0,-1 if you think its too sharp.

[ncahammer]

1. Psy RDO is on by default (with default strength), but only if you use a x264 build with "Psy RDO" patch
2. It works with 2-Pass as well as with CRF, but it will make your files a bit bigger in CRF mode
If I use a non-psy x264 build a crf 18 will give me (most of the times) a transparent encode. Using this bitrate (or close to this) I could do a 2-pass encode with acceptable results.

Which method will give me a valid metric of source's compressibility when using a "Psy RDO" build ?

1) Should I raise crf to 20 ?
2) Should I somehow disable psy when doing this crf encode ?
3) Do a 1st pass with an expected bitrate and check QP of the log or .stats and then do 2st pass increasing or decreasing the bitrate ?

[LoRd_MuldeR]

Simply use the same CRF value that you used without Psy RDO, e.g. CRF 18 ;)
If you are not happy with the result, then lower the CRF. If you want to save some bits, then raise the CRF and check whether the result is still acceptable or not.

IMHO doing a CRF encode, taking the resulting average bitrate and re-encoding the video in 2-Pass mode is nonsense and a waste of time.
Your second encode (2-Pass) would look no different from the first one (CRF). At least the difference would be negligible.
It was said several times that a 2-Pass and a CRF encode of the same (average) bitrate look almost identical. Only with CRF you cannot predict the filesize in advance.

If you want to achieve a certain level of quality, then use CRF. If you need to hit a certain target filesize then use 2-Pass. That's it.

[ncahammer]

If you want to achieve a certain level of quality, then use CRF. If you need to hit a certain target filesize then use 2-Pass. That's it.
I don't want neither.
I don't want to waste bitrate or quality or media.
For example the problem is find out how many episodes of a series do fit in a DVD5, with a transparent (or close to it) quality and then encode targeting the DVD5 size or to align the encoded size of a movie to a DVD5/4 units.

Anyway, back on topic, I already do what you suggested on non-Psy builds, but it seems that I cannot balance it on "psy Rdo" builds. I don't have a starting point and numbers don't mean much any more. Must be something I am missing.

Thanks

[LoRd_MuldeR]

Find out which CRF value still gives acceptable quality for you. Then encode all your episodes with that CRF value.
Finally put as many episodes on the disc, as fit on the disc. That's it...

[Sharktooth]

line 273 please add:
\n after Does nothing at subme < 6.

[bob0r]

line 273 please add:
\n after Does nothing at subme < 6.

Dark has already fixed this "internally".
Also the 1.00000 value is fixed to 1.0 i guess.

[Dark Shikari]

line 273 please add:
\n after Does nothing at subme < 6.I have a couple minor fixes of the sort in my internal code tree--no point in releasing a new version for that yet.

[Revgen]

Is "Turbo" in MeGUI a good option to use with PsyRDO?

Will it affect the quality significantly? Some posts here mention that settings need to be the same on both passes.

[Sharktooth]

Turbo option just speeds up the first pass.
it does it using different (lower) settings than the second pass. that means a very slight final quality loss but a huge gain in first pass speed.

[smok3]

Sharktooth; looking at the insane profile, isn't trellis disabled there by default? (with psyrdo version of x264 i mean)?

[LoRd_MuldeR]

Only Trellis=1 is disabled when Psy RDO is on, Trellis=2 works just fine with Psy RDO ...

[Vit]

I've encoded full STEM clip at 15 MBits/s using this patch and Sonic CineVision 2.6. Sonic's encode is consistently better, am I doing something wrong or commercial encoders are not as crappy as some x264 apologists claim?

Here's the command line:
x264.910.modified.exe --pass 1 --fps 23.976 --bitrate 15000 --level 4.1 --keyint 24 --min-keyint 1 --ref 3 --mixed-refs --no-fast-pskip --bframes 2 --b-pyramid --bime --weightb --filter -2,-2 --subme 6 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --vbv-bufsize 45000 --vbv-maxrate 30000 --threads auto --thread-input --progress --no-dct-decimate --output "f:\stem_x264.264" "F:\Source Files\StEM_full.yuv" 1920x1080 --aq-mode 2

Second's pass settings are the same, but with --pass 2. I can post some pictures if anyone is interested

[Sharktooth]

why did you use min-keyint 1 and keyint 24, only 2 b-frames, filter -2,-2, VBV limits, etc?
however look at the comparisons (http://mirror05.x264.nl/Dark/website/compare.html) x264 is way better than commercial encoders.

[Vit]

however look at the comparisons (http://mirror05.x264.nl/Dark/website/compare.html) x264 is way better than commercial encoders.

Laughing out loud. That's perfect argument

[Sharktooth]

laugh whenever you want. you're a n00b and not even able to set up an encoder correctly and you're still talkin? get out or learn something before speaking.
and, yes, it's a fair comparison made by competent ppl, not incompetent ppl like you.
x264 also won the last doom9 codec comparison... so better SEARCH before speaking as per forum rules.
if you came here for insulting the devs hard work then you're NOT welcome.

[Manao]

Sharktooth : VBV & gop restriction come probably from Bluray constraints, so he can't avoid them. And imho, you're overreacting (and that's an understatement)

Vit : I don't remember Bluray preventing you from using 3 bframes in a row. And VBV bufsize, iirc, is half a second, thus 15000, not 45000.

[Dark Shikari]

I've encoded full STEM clip at 15 MBits/s using this patch and Sonic CineVision 2.6. Sonic's encode is consistently better, am I doing something wrong or commercial encoders are not as crappy as some x264 apologists claim?

Here's the command line:
x264.910.modified.exe --pass 1 --fps 23.976 --bitrate 15000 --level 4.1 --keyint 24 --min-keyint 1 --ref 3 --mixed-refs --no-fast-pskip --bframes 2 --b-pyramid --bime --weightb --filter -2,-2 --subme 6 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --vbv-bufsize 45000 --vbv-maxrate 30000 --threads auto --thread-input --progress --no-dct-decimate --output "f:\stem_x264.264" "F:\Source Files\StEM_full.yuv" 1920x1080 --aq-mode 2

Second's pass settings are the same, but with --pass 2. I can post some pictures if anyone is interestedSo basically:

1. You use awful settings and wonder why the output sucks (sorry folks, but I'm not going to make x264 compensate for user stupidity here).
2. Instead of asking "how can I make these settings better", you start whining about "x264 apologists"...

Now, if what you actually meant was "How can I improve the quality of my output" and you just mistyped, try this instead:

x264.910.modified.exe --pass 1 --fps 23.976 --bitrate 15000 --level 4.1 --ref 4 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --me umh --mixed-refs --bime --weightb --filter -2,-2 --subme 7 --b-rdo --8x8dct --threads auto --progress --no-dct-decimate --output "f:\stem_x264.264" "F:\Source Files\StEM_full.yuv" 1920x1080

15 megabit 1080p is a rather bad place to compare at though, given that any decent encoder should be able to basically give transparency, and if you can't pick out the details between two encodes without using a microscope, its hard to compare them.

[cogman]

laugh whenever you want. you're a n00b and not even able to set up an encoder correctly and you're still talkin? get out or learn something before speaking.
and, yes, it's a fair comparison made by competent ppl, not incompetent ppl like you.
x264 also won the last doom9 codec comparison... so better SEARCH before speaking as per forum rules.
if you came here for insulting the devs hard work then you're NOT welcome.

now now, be careful lest you violate rule #4

Though, VIT Sharktooth is right, x264 when given the proper settings is a miracle worker. Try the settings that he gave you and see if there is any improvement.

[DarkZell666]

- Any screenshots and the details of the settings you used in CineVision to share ? :)
- CineVision isn't the only commercial encoder out there, so maybe you are right and it might well be better than other commercial encoders, but those have indeed been proven weaker than x264, you can't deny it. But the former also needs proving with pictures or samples :)

I've encoded full STEM clip at 15 MBits/s using this patch and Sonic CineVision 2.6. Sonic's encode is consistently better, am I doing something wrong or commercial encoders are not as crappy as some x264 apologists claim?

Here's the command line:
x264.910.modified.exe --pass 1 --fps 23.976 --bitrate 15000 --level 4.1 --keyint 24 --min-keyint 1 --ref 3 --mixed-refs --no-fast-pskip --bframes 2 --b-pyramid --bime --weightb --filter -2,-2 --subme 6 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --vbv-bufsize 45000 --vbv-maxrate 30000 --threads auto --thread-input --progress --no-dct-decimate --output "f:\stem_x264.264" "F:\Source Files\StEM_full.yuv" 1920x1080 --aq-mode 2

Second's pass settings are the same, but with --pass 2. I can post some pictures if anyone is interested

[smok3]

I think Vit is targeting bluray? (--keyint 24)

[Dethis]

I think Vit is targeting bluray? (--keyint 24)

If so, he should set
vbv-baffsize 30000 (1 sec),
vbv-maxrate up to the smaller among 40000 or 48000 minus the required bitrate by the sound tracks subtitles etc.

[Sharktooth]

he could also use 3 bframes (it's ok with blu-ray and could give a major boost in quality), eliminate --no-dct-decimate (that often results in bigger filesize hence worse quality for a bitrate based RC) and --no-fast-pskip, higher the deblocking (-2,-2 often means blocks), -b-rdo and -me umh are missing but he used other useless slow options (like --no-fast-pskip or --no-dct-decimation), --aq-mode 2 is redundant since it's the default, also the VBV paramaters are completely wrong... that shows he is incompetent (so my comment even if may sound a bit harsh is not an offense, it's just the reality). He shown he doesnt know anything about x264 coz he set the options almost randomly and he is still offending ppl and destructively criticizing x264 and the devs work without even asking if he was doing something wrong...
he joined the forum on march 2007 so he had all the time to document himself but obviously he didnt. He made 3 posts of which 2, in this thread, contain insults and are plain provocations...
IMHO if he keeps that behaviour he better find another place.

OT: anyone knows the AVC-HD exact vbv-buffsize?

[Manao]

He never criticized x264. You're criticizing his options, yet --no-fast-pskip / --no-dct-decimate / --filter -2:-2 were still advised by Dark_Shikari. He didn't use subme 7 / b-rdo / umh (he stopped at subme 6 / hex ) but it's still a coherent choice.

In the end, though the number of bframes / vbv-bufsize seem off, they may probably have been set to match those used in Sonic CineVision, in order to make a fair comparison.

And, on a side note, if 7 years ago I had received such a welcome on doom9, I would never have bothered.

[Dark Shikari]

And, on a side note, if 7 years ago I had received such a welcome on doom9, I would never have bothered.The reason he got such an icy response was not because of the complaint about x264 quality, but rather because of the phrase "x264 apologists"; it is quite reasonable to interpret this as an attack, a troll, or both.

If you used such inflammatory and loaded language, you wouldn't have been welcomed here either. Fortunately, you're much more mature than that and I would never expect anything of that sort from you.

I do agree that most people here were far too sharp in their reaction; there seems to be a tendency for people to see others overreact, and interpret that as a signal that they can overreact too. It generally is a good idea to assume good faith at least initially, which most people seem to forget...

[foxyshadis]

Sharktooth: Calm down. You get way too riled up when anyone posts something provocative, and start flinging insults, instead of putting them in their place by calmly pointing out what's wrong. You'll end up suspended for rule 4 if you don't stop reacting angrily.

[Sagittaire]

Well just my 2 cents.

1) BR and AVCHD specifications
- HP@4.1 specification with limitation
- Buffer max for 1080p24: 30 000 bits
- Max bitrate at 40 Mbps for BR and 30 Mbps for AVCHD
- 4,3 for p,b frame reference, 3 pyramidal bframe imply 3,2 ref for p,b. Use 2 bframes with 4,3 ref is better for software compatibility.
- Max gop at 24 with IDR
- WPred
- FGM is not supported

2) At 15 Mbps you have not transparence with 42" and higher screen. From my experience x264 with good patch is by far better than Mainconcept SDK (cinevision) but only at low/medium bitrate.
x264 produce really impressive result in [6-8] MBps interval for 1080p24 content.


@REM -----------------------------------------------------------
@REM
@REM Profil BluRay 1080p23.976 extra high quality
@REM
@REM -----------------------------------------------------------


@REM Source file name (suffit de mettre la source ici)
set E_SRC=Lossless.avs

@REM Set of quality (ici la qualité 1-50)
set E_BR=21.3

@REM Set of max bitrate (ici le bitrate max)
set MAX_BR=40000

@REM Set of Buffer (ici le buffer)
set BUF_BR=30000

@REM Set credit (frame de début du générique)
set CRE_FR=201560

@REM Set end credit (frame de fin du générique)
set END_FR=207442



@REM Profil

x264.exe --threads auto --thread-input --keyint 24 --min-keyint 1 --crf %E_BR% --vbv-maxrate %MAX_BR%
--vbv-bufsize %BUF_BR% --mvrange 511 --level 4.1 --bframe 3 --b-pyramid --b-rdo --bime --weightb --ref 3
--mixed-refs --direct auto --deblock -2:-2 --ipratio 1.10 --pbratio 1.10 --partitions "all" --8x8dct --me "umh"
--subme 7 --trellis 2 --no-fast-pskip --no-dct-decimate --aud --nal-hrd --sar 1:1 --cqmfile Sagittaire.cfg
--psy-rd 1.0 --zone %CRE_FR%,%END_FR%,b=0.33 --progress --pass 1 --stats "stat.log" -o 1080p_Q1.264 %E_SRC%

pause

[smok3]

Sagittaire, what range of CRF values do you usually use? (%E_BR%), any special reason for 21.3?

[Sharktooth]

Sharktooth: Calm down. You get way too riled up when anyone posts something provocative, and start flinging insults, instead of putting them in their place by calmly pointing out what's wrong. You'll end up suspended for rule 4 if you don't stop reacting angrily.
i am calm, i did not offend or insulted anyone.
what may sound an offence is a mere constatation of facts.
btw trust me, you dont want to see me angry.

[bob0r]

..
btw trust me, you dont want to see me angry.


Trust me aswell, i once trew a blu-ray disc at Shark "Zangief" Tooth's head..... i couldn't walk/speak/blink my eyes/go to the rest room for 5 months.

[Sagittaire]

Sagittaire, what range of CRF values do you usually use? (%E_BR%), any special reason for 21.3?

I make comparison with DarkNight uncompressed source.
x264 produce simply 12 Mbps at 21.3 for this encoding.
In this test x264 with psyrdo patch is a real killer.

[chainring]

He never criticized x264. You're criticizing his options, yet --no-fast-pskip / --no-dct-decimate / --filter -2:-2 were still advised by Dark_Shikari. He didn't use subme 7 / b-rdo / umh (he stopped at subme 6 / hex ) but it's still a coherent choice.
Argh, my head is hurting! I've tried keeping up with all the patch threads, the current version thread, and now I see, what seems to be, conflicting info on --no-fast-pskip / --no-dct-decimate / --filter -2:-2.

So, for a person using build 920, psyRDO on (default), trellis 2 (don't care about speed loss), and using CRF; what is the correct application of these settings? I've now seen Sharktooth say --no-fast-pskip and --no-dct-decimate are bad. I've seen Dark_Shikari say to just go with default filter values (0:0). Now, there's conflicting info in what I've quoted from Manao.

Any help?

BTW, here's my commandline as it stands now.
--crf 20.0 --ref 5 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --b-rdo --bime --weightb --subme 7 --trellis 2 --partitions p8x8,b8x8,i8x8 --8x8dct --me umh --threads auto --thread-input --progress --no-dct-decimate --no-psnr --no-ssim --output "output" "input"

[Dark Shikari]

Argh, my head is hurting! I've tried keeping up with all the patch threads, the current version thread, and now I see, what seems to be, conflicting info on --no-fast-pskip / --no-dct-decimate / --filter -2:-2.

So, for a person using build 920, psyRDO on (default), trellis 2 (don't care about speed loss), and using CRF; what is the correct application of these settings? I've now seen Sharktooth say --no-fast-pskip and --no-dct-decimate are bad. I've seen Dark_Shikari say to just go with default filter values (0:0). Now, there's conflicting info in what I've quoted from Manao.

Any help?

BTW, here's my commandline as it stands now.
--crf 20.0 --ref 5 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --b-rdo --bime --weightb --subme 7 --trellis 2 --partitions p8x8,b8x8,i8x8 --8x8dct --me umh --threads auto --thread-input --progress --no-dct-decimate --no-psnr --no-ssim --output "output" "input"--no-fast-pskip is not going to hurt quality. It might not help a lot, but it doesn't hurt.

[Manao]

I never given any settings on this thread. I just compared Vit's initial settings from those advised by Dark_Shikari and pointed out settings that were present in both, yet subject to polemic : no-fast-pskip, no-dct-decimate, filter -2:-2.

I don't know whether no-fast-pskip and no-dct-decimate ought to be used or not (instinctively, i'd say the first is good, and so is the second if trellis 1/2 is used). As for filter, between -3:-3 and 1:1, it's imho a subjective matter.

[chainring]

Hi Manao,

Thank you for the reply!

I wasn't meaning to imply YOU were giving the settings, per se, but just quoting what you were in turn quoting.

I never given any settings on this thread. I just compared Vit's initial settings from those advised by Dark_Shikari and pointed out settings that were present in both, yet subject to polemic : no-fast-pskip, no-dct-decimate, filter -2:-2.

I don't know whether no-fast-pskip and no-dct-decimate ought to be used or not (instinctively, i'd say the first is good, and so is the second if trellis 1/2 is used). As for filter, between -3:-3 and 1:1, it's imho a subjective matter.

[CruNcher]

I've encoded full STEM clip at 15 MBits/s using this patch and Sonic CineVision 2.6. Sonic's encode is consistently better, am I doing something wrong or commercial encoders are not as crappy as some x264 apologists claim?

Here's the command line:
x264.910.modified.exe --pass 1 --fps 23.976 --bitrate 15000 --level 4.1 --keyint 24 --min-keyint 1 --ref 3 --mixed-refs --no-fast-pskip --bframes 2 --b-pyramid --bime --weightb --filter -2,-2 --subme 6 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --vbv-bufsize 45000 --vbv-maxrate 30000 --threads auto --thread-input --progress --no-dct-decimate --output "f:\stem_x264.264" "F:\Source Files\StEM_full.yuv" 1920x1080 --aq-mode 2

Second's pass settings are the same, but with --pass 2. I can post some pictures if anyone is interested

Hi and welcome :) do you also have a Speed Comparision i guess Cinevision 2.6 uses the new G4 Encoder ?

[Sharktooth]

he used wrong settings for x264. you cant compare speed and quality of 2 different encoders if you cant set up them (or at least one of them).

[CruNcher]

it's only important that the G4 Encoder settings where of the same nature then the X264 settings, tough we dont know what the Cinevision 2.6 settings where if they where equal you could very well compare it :) especialy the decission side of things b-frame decission, partition decission, scenecut and b-pyramid decission is very important here. Compression/Complexity wise i agree Vit his settings aren't as effective as Sagittaire but to call them wrong hmm sure in terms of BD profile there way of too to what you normaly would use but it doesnt matter in his comparision he did with Cinevision 2.6 in this case for this very special Film source. :)

[Sharktooth]

he said cinevision was constantly better (subjective, without pics or clips) so probably he used much different settings and we also dont know anything about the source and cinevision settings.
he just came here, trolled and gone away.
he just didnt contributed in any way to the discussion, so, for what concerns me, he could even not post at all.

[CruNcher]

he said cinevision was constantly better (subjective, without pics or clips) so probebly he used much different settings and we also dont know anything about the source and cinevision settings.
he just came here, trolled and gone away.
he just didnt contributed in any way to the discussion, so, for what concerns me, he could even not post at all.

Yes i agree his behaviour for what seems to be a Professional Post House Encoder is a little weired indeed, but it doesn't mean his experience was wrong, tough i would thrust Sagittaire 1000x times more ;)

@Sagittaire
I hope we gonna see a Cinevision 2.6 vs latest X264 GIT and X264 GIT + Psy RD Blu-Ray restricted Film Source comparission from you in the future :)

[Sagittaire]

@Sagittaire
I hope we gonna see a Cinevision 2.6 vs latest X264 GIT and X264 GIT + Psy RD Blu-Ray restricted Film Source comparission from you in the future :)

1) Well from Mutek (Elecard SDK enginer): "there are not quality gain for G4 but only speed optimisation"
http://forum.doom9.org/showthread.php?p=1149767#post1149767

2) Moreover you can't use all the insane SDK setting in cinevision 2.5 and certainely not in cinevision 2.6 too. Cinevision is pro gui for high bitrate encoding. Certainely better here to use Reference or Converter for have the insane setting.

3) Psy RD patch for x264 is a real killer. Certainely the best patch that I have ever seen for x264. RDO for bframe decision don't make very higher quality like I expected but some small optimisation produce big improuvement at the end.

[CruNcher]

1) Well from Mutek (Elecard SDK enginer): "there are not quality gain for G4 but only speed optimisation"
http://forum.doom9.org/showthread.php?p=1149767#post1149767

2) Moreover you can't use all the insane SDK setting in cinevision 2.5 and certainely not in cinevision 2.6 too. Cinevision is pro gui for high bitrate encoding. Certainely better here to use Reference or Converter for have the insane setting.

3) Psy RD patch for x264 is a real killer. Certainely the best patch that I have ever seen for x264. RDO for bframe decision don't make very higher quality like I expected but some small optimisation produce big improuvement at the end.

So you experience tells you --b-rdo and it's resulting 20% speed lose can be saved now when useing psy-rd alone (visualy) ? that's great news :) seeing that RD is allready faster then some month ago :D and saving the 20% from --b-rdo without much of a subjecive visual quality lose that's really a big win and also what my subjective tests are indicating (tough im still testing) :)
And no it wasn't my intention to compare Insane settings vs cinevision non setable settings it was my intention to compare the decissions and the speed/quality difference if the're any for a Blu-Ray Framework @ exactly those High Bitrates and gop restrictions :)

[Dark Shikari]

So you experience tells you --b-rdo and it's resulting 20% speed lose can be saved now when useing psy-rd alone (visualy) ? that's great news :) seeing that RD is allready faster then some month ago :D and saving the 20% from --b-rdo without much of a subjecive visual quality lose that's really a big win and also what my subjective tests are indicating (tough im still testing) :)I'm pretty sure he's talking about --b-adapt 2, not --b-rdo...