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

[Dark Shikari]

for us all ;) thanx, find them very useful... but... is there a public repository where we can follow the devel process?Here (http://git.videolan.org/?p=x264.git;a=summary).

[nerdpunk]

Here (http://git.videolan.org/?p=x264.git;a=summary).

i know, sorry, i meant a place where we can find your latest (psy-*) patches... or will they get merged in a forseeable future?

[Dark Shikari]

i know, sorry, i meant a place where we can find your latest (psy-*) patches... or will they get merged in a forseeable future?Soon enough... hopefully.

[gigah72]

Bah, I even have to rebase my patches for you...

Linkage (http://pastebin.com/m3fb0df)

thank you.

may i ask you, what is improved/reworked in this patch, beside the cmd-switch? i don't speak c, and from the comments, not much saying to me.
btw, i can't patch b-adapt patch from 29.07., saying something about other patch detected -> reverse, blabla, and i'm too clueless what do to ...

[skystrife]

thank you.

may i ask you, what is improved/reworked in this patch, beside the cmd-switch? i don't speak c, and from the comments, not much saying to me.
btw, i can't patch b-adapt patch from 29.07., saying something about other patch detected -> reverse, blabla, and i'm too clueless what do to ...

Remove the part in the b-adapt patch where it changes X264_BUILD in x264.h. The new psyrdo+psytrellis patch changes it already.

Or, just grab this (http://skystrife.com/x264/x264_new_bframe_decision_04.diff).

[gigah72]

Remove the part in the b-adapt patch where it changes X264_BUILD in x264.h. The new psyrdo+psytrellis patch changes it already.

Or, just grab this (http://skystrife.com/x264/x264_new_bframe_decision_04.diff).

thanx m8, for helping again :)

[turbojet]

Dark Shikari Why is psytrellis being forced upon us by replacing the origninal trellis algorithm instead of being an additional setting such as the new bframe decision?
BTW I'm rather surprised you decided to use -b-adapt 2 with the new frame decision and not try to dictate what everyone must use like you did with trellis 1 and now this whole psytrellis ordeal. Why don't you add to x264 rather than reinventing it?

[Zwitterion]

Dark Shikari Why is psytrellis being forced upon us by replacing the origninal trellis algorithm instead of being an additional setting such as the new bframe decision

It isn't. See here: http://forum.doom9.org/showpost.php?p=1170411&postcount=496
Also don't forget that PsyRDO and b-frame-adapt are still experimental patches and not yet commited. So nothing is 'forced upon you'.

[elguaxo]

turbojet, these are experimental patches, you are not forced to use them. :)

edit: what Zwitterion said

[turbojet]

--psy-rd 1:0 means regular trellis is used?
if yes, if --trellis 1 does this mean the old --trellis 1 is used and not an automatic switch back to 0 if psyRDO is used? <- this is what I'd really like to do again.
if no, then since r931 it appears that if you want psyrdo you are forced to have psytrellis. Which frankly makes the encoder alot more ineffecient and slower, not really what I'd call progress in, with the age of x264, should be a somewhat stable codec. I do like the idea but I think it needs some more optimaztion to be pushed into every psyrdo build, or a switch at least.

Don't get me wrong, this isn't a personal attack on you dark shikari. I do appreciate what you and anyone else involved did with vaq and psyrdo, and both of these have options to disable\enable them. --trellis 1 with psyrdo you've already seen my opinions on earlier in this thread. Why can't you make options for these and everyone can be satisfied? If you want people to use a certain thing, you could just make it the default, like trellis 0 already is, but leave the option open to the person encoding.

Also one thing I noticed while catching up on this thread is that Dark Shikari wants video clips to make comparisons, which I agree with. But he is asking others to judge psytrellis by a one frame comparison. Anyone can make a still frame look better or worse then its opposition, this is not saying you are lying to us on your pictures. But why not present it how you'd want it, with video clip. Such as a regular trellis clip compared to a psytrellis clip at the same crf, asking them to take size into consideration, and a 2 pass trellis vs psytrellis clip done at the same reasonable bitrate?

[Dark Shikari]

Dark Shikari Why is psytrellis being forced upon us by replacing the origninal trellis algorithm instead of being an additional setting such as the new bframe decision?
BTW I'm rather surprised you decided to use -b-adapt 2 with the new frame decision and not try to dictate what everyone must use like you did with trellis 1 and now this whole psytrellis ordeal. Why don't you add to x264 rather than reinventing it?You can adjust psy-trellis strength with --psy-rd... nothing is being "forced" upon anyone...
Also one thing I noticed while catching up on this thread is that Dark Shikari wants video clips to make comparisons, which I agree with. But he is asking others to judge psytrellis by a one frame comparison. Anyone can make a still frame look better or worse then its opposition, this is not saying you are lying to us on your pictures. But why not present it how you'd want it, with video clip. Such as a regular trellis clip compared to a psytrellis clip at the same crf, asking them to take size into consideration, and a 2 pass trellis vs psytrellis clip done at the same reasonable bitrate?I don't think I've posted much in terms of single-frame comparisons in this thread... I don't think its that much of my job to convince people that features are useful, rather, its my job to make useful features and let others test to see if they can find cases where they have a negative effect so that I can see if they need further tweaking. Again, if you don't like it, you can turn it off...

I don't get the hostility here; are people somehow mad because new features are being added (despite the fact that these new features are optional)?

[turbojet]

OK so let me get this straight, --trellis 1 --psyrd 1.0:0 is the same as --trellis 1 in vanilla builds?
mediainfo says --trellis 1, size is different then that of --trellis 0 and --trellis 2

935 from http://forum.doom9.org/showthread.php?p=1170562#post1170562
930 from http://forum.doom9.org/showthread.php?p=1168914#post1168914

using this on both: --crf 20.0 --level 4.1 --ref 3 --mixed-refs --bframes 3 --b-pyramid --b-rdo --bime --weightb --direct auto --subme 7 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --vbv-bufsize 30000 --vbv-maxrate 30000 --me umh --threads auto --thread-input --mvrange 511 --aud

--trellis 0 935 14.3 vs 13.2 MB 930
--trellis 2 935 14.9 vs 13.8 MB 930

935 is also a bit slower. I don't think this is the same trellis as before.

I appreciate the new features. My hostility started when you disabled trellis 1 with psyrdo because you didn't think it was optimized for it. Adding useful features is good as long as they are optional, removing features that people regularly use is bad and gonna come with some criticism. This is the first time in over 10 years of encoding that I've seen useful and used features being removed.

Think jack sparrow for pic comparison, its the only way psytrellis was presented in this thread.

[Dark Shikari]

OK so let me get this straight, --trellis 1 --psyrd 1.0:0 is the same as --trellis 1 in vanilla builds?
mediainfo says --trellis 1, size is different then that of --trellis 0 and --trellis 2

935 from http://forum.doom9.org/showthread.php?p=1170562#post1170562
930 from http://forum.doom9.org/showthread.php?p=1168914#post1168914

using this on both: --crf 20.0 --level 4.1 --ref 3 --mixed-refs --bframes 3 --b-pyramid --b-rdo --bime --weightb --direct auto --subme 7 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --vbv-bufsize 30000 --vbv-maxrate 30000 --me umh --threads auto --thread-input --mvrange 511 --aud

--trellis 0 935 14.3 vs 13.2 MB
--trellis 2 930 14.9 vs 13.8 MB

935 is also a bit slower. I don't think this is the same trellis as before.If it isn't the same, then there's a bug. If you don't like it, patches are welcome, or you can wait for me to find it.

(I'm going to guess the real difference lies in the chroma-qp-offset, however; I doubt there's a bug, but I'll check anyways.)

Edit: bug check done. When trellis is off, trellis is off and chroma QP offset isn't further decremented. When trellis is on, and psy trellis is 0, the psy trellis code is never run. When trellis is on, and psy trellis is nonzero, the psy trellis code is run. Seems to work.

[turbojet]

Frankly unless something signifigant was added like psyrdo and vaq, I don't remeber filesize changing by more than a few KB and speed not really changing at all when changing between x264 builds within a month or so of each other.

Wonder why this all of a sudden changes this by quite a bit.

Anyhow I'll be glad to have original -trellis 1 back, please do me a favor and don't go disabling it again

[Dark Shikari]

What do you mean by 'When trellis is on, and psy trellis is nonzero, the psy trellis code is run.' ?It does what its supposed to do--when the psy trellis strength isn't zero, and trellis is on, psy trellis is run. Otherwise, regular trellis is run (if trellis is nonzero) or no trellis is run (if trellis is zero).
Frankly unless something signifigant was added like psyrdo and vaq, I don't remeber filesize changing by more than a few KB and speed not really changing at all when changing between x264 builds within a month or so of each other.You're forgetting about the chroma QP offset.

[shon3i]

I am bit confused about new cmd.

--psy-rd x:y

is x PsyRDO strenght?
and is y PsyTrellis switcher and can be only 0 or 1 (off/on)?

if x not 0 and y = 1 trellis can be 1 or 2?
if x not 0 and y = 0 trellis can be 0 or 2, like earlier or not?

Can we use only PsyTrellis?

Thanks

[Dark Shikari]

I am bit confused about new cmd.

--psy-rd x:y

is x PsyRDO strenght?
and is y PsyTrellis switcher and can be only 0 or 1 (off/on)?

if x not 0 and y = 1 trellis should be 1 or 2?
if x not 0 and y = 0 trellis should be 0 or 2, like earlier or not?

Can we use only PsyTrellis?

ThanksBoth are float values; they can be decimal strengths.

You can use only psy-trellis and not psy-rd, but its not recommended (it helps, but its not nearly as useful as the combination). I guess it might be useful when you need high speed and can't afford RD.

[Sharktooth]

psy-trellis is suboptimal without psy-rdo.
x is psy rdo strenght (0 = disabled)
y is psy trellis strenght (0 = disabled)
trellis 0,1 and 2 work as usual... and psy trellis is useless with trellis 0...
that's at least is what i understood.

D_S: i would add a couple of checks though: if psy-rdo is enabled then automatically enable psy-trellis unless it is set to 0. if psy-rdo is disabled keep the normal trellis (if trellis > 0.... redundant...) unless psy-trellis is set > 0.

[turbojet]

What was changed with the chroma QP offset?
I was thinking it might be the faster deblocking affecting filesize, and maybe compile options affecting the speed, which isn't too signifigant and I've seen this sort of difference between 2 different builds based on same x264 revision.

I think I'll try testing different psytrellis strengths to find a good medium for my eyes when I find some time. I do see the potential in it from the little experience I've had with it, using defaults. What is the default strength of psytrellis?

[Dark Shikari]

psy-trellis is suboptimal without psy-rdo.
x is psy rdo strenght (0 = disabled)
y is psy trellis sytrenght (0 = disabled)
trellis 0,1 and 2 work as usual... and psy trellis is useless with trellis 0...
that's at least is what i understood.

D_S: i would add a couple of checks though: if psy-rdo is enabled then automatically enable psy-trellis unless it is set to 0. if psy-rdo is disabled keep the normal trellis (if trellis > 0.... redundant...) unless psy-trellis is set > 0.Psy trellis is 1.0 by default, psy RD is 1.0 by default.What was changed with the chroma QP offset?A chroma QP offset was added when using psy RD (and a further one using psy trellis) to compensate for the higher quants the two tend to cause.

[Sharktooth]

i meant, if psy-rdo = 0 then psy-trellis strength = 0 (unless some value (even the default one) is specified in the commandline)
if psy-rdo > 0 then psy-trellis strength = something (where "something" is the default (1) value if the param is not specified in the commandline or the value the user set in the commandline param).

[Dark Shikari]

i meant, if psy-rdo = 0 then psy-trellis strength = 0 (unless some value (even the default one) is specified in the commandline)If you specify --psy-rd X (without :Y), it'll set Y equal to X.

[Sharktooth]

ok, not much code changes on my side then.

[Quark.Fusion]

What now is optimal setting of trellis with psy-trellis on — 1 or 2? (At start of this thread was sayed that trellis 1 can't adequately work with psy-rd and trellis 2 is recommended instead, what is situation now?) Or psy-trellis replaces trellis?

[Avenger007]

What now is optimal setting of trellis with psy-trellis on — 1 or 2? (At start of this thread was sayed that trellis 1 can't adequately work with psy-rd and trellis 2 is recommended instead, what is situation now?)
trellis 0,1 and 2 work as usual... and psy trellis is useless with trellis 0...
So use what you like.

Or psy-trellis replaces trellis?
when the psy trellis strength isn't zero, and trellis is on, psy trellis is run. Otherwise, regular trellis is run (if trellis is nonzero) or no trellis is run (if trellis is zero).

[Avenger007]

I don't get the hostility here; are people somehow mad because new features are being added (despite the fact that these new features are optional)?
I'm guessing the significant increase in CRF file size might be a factor. There's also an increase in encoding time.
I don't mind the increase in encoding time but the increase in file size does take it's toll. However, I know I can always increase the CRF value. :sly:
A chroma QP offset was added when using psy RD (and a further one using psy trellis) to compensate for the higher quants the two tend to cause.
Would a CRF offset be a bad idea (what they don't know can't hurt them :devil:)? Since the AQ and psy-* patches increase perceptual quality at the same bitrate when compared without them, then the increased bitrate when using CRF seems... uncalled-for.

[kemuri-_9]

A chroma QP offset was added when using psy RD (and a further one using psy trellis) to compensate for the higher quants the two tend to cause.

Maybe people are looking for those numbers you stashed away in the code?
the chroma qp offset for a strength < .25 (but > 0) is -1, for strength >= .25 the offset is -2
this applies to both psy-rd and psy trellis strengths:
i.e.
1.0:1.0 produces a -4 offset
0.5:0.2 produces a -3 offset
0.15:0.10 & 0.4:0 produce a -2 offset
0.10:0 produces a -1 offset

(however x264 still enforces the [-12,12] range for chroma qp offset after this takes place so if you have a -12 offset before this, it will remain -12)

iirc, the offsets were first added in the first +psy-trellis patch
but in that case, if psy trellis was on, it was always a -2 offset.

[Shinigami-Sama]

Would a CRF offset be a bad idea (what they don't know can't hurt them :devil:)? Since the AQ and psy-* patches increase perceptual quality at the same bitrate when compared without them, then the increased bitrate when using CRF seems... uncalled-for.

the psy-* Stuff increase bitrate at a given quant...

[Dark Shikari]

Would a CRF offset be a bad idea (what they don't know can't hurt them :devil:)? Since the AQ and psy-* patches increase perceptual quality at the same bitrate when compared without them, then the increased bitrate when using CRF seems... uncalled-for.I've thought of the idea before; its not unreasonable.

[Avenger007]

I've thought of the idea before; its not unreasonable.
A snap-poll (thread) would be nice if you're planning on implementing it.
I vote for the psy-opts to have little impact on the bitrate when compared to not using them, in CRF mode. Other people may be more forgiving about a large difference in bitrate.

[Shinigami-Sama]

A snap-poll (thread) would be nice if you're planning on implementing it.
I vote for the psy-opts to have little impact on the bitrate when compared to not using them, in CRF mode. Other people may be more forgiving about a large difference in bitrate.

... all they have to do is up the crf a bit and it will still look as good as they're used too...

[Audionut]

I've thought of the idea before; its not unreasonable.

Please don't. People just need to adjust their ways and use a higher CRF to obtain the same visually quality.

And you could just ignore the un-constructive useless posts that some make.
Loren seems to do it well. :cool:

[akupenguin]

People just need to adjust their ways and use a higher CRF to obtain the same visually quality.
What exactly is better about having CRF20 represent quality X, rather than having CRF19 represent quality X?
Otoh, if some people use psy and some don't and some use various strengths, there is an obvious benefit from CRF having the same meaning in all those cases.
If an option increases quality and reduces bitrate, I don't have much of an opinion as to which one we should track; any compromise that's easy to implement is acceptable. And if an option sometimes increases and sometimes decreases bitrate, that's just life, we have to expect some variance in the output of heuristics. But if an option consistently and predictably increases both quality and bitrate while all ratecontrol options are held constant, then it's miscalibrated.
I have already applied this principle: If I hadn't included an arbitrary correction factor, CRF would mean different things depending on whether you enabled B-frames or not. Or more extremely, depending on your video resolution.

[Ranguvar]

Bah, I even have to rebase my patches for you...

Linkage (http://pastebin.com/m3fb0df)
Fails patching against r936 from git?

patching file common/common.c
Hunk #1 FAILED at 117.
Hunk #2 FAILED at 466.
Hunk #3 FAILED at 873.
3 out of 3 hunks FAILED -- saving rejects to file common/common.c.rej
patching file common/common.h
Hunk #1 FAILED at 377.
Hunk #2 FAILED at 456.
2 out of 2 hunks FAILED -- saving rejects to file common/common.h.rej
patching file common/dct.h
Hunk #1 FAILED at 41.
1 out of 1 hunk FAILED -- saving rejects to file common/dct.h.rej
patching file encoder/analyse.c
Hunk #1 FAILED at 467.
Hunk #2 FAILED at 1069.
Hunk #3 FAILED at 1962.
Hunk #4 FAILED at 2121.
Hunk #5 FAILED at 2401.
Hunk #6 FAILED at 2649.
6 out of 6 hunks FAILED -- saving rejects to file encoder/analyse.c.rej
patching file encoder/encoder.c
Hunk #1 FAILED at 410.
Hunk #2 FAILED at 484.
2 out of 2 hunks FAILED -- saving rejects to file encoder/encoder.c.rej
patching file encoder/macroblock.c
Hunk #1 FAILED at 94.
Hunk #2 FAILED at 121.
Hunk #3 FAILED at 163.
Hunk #4 FAILED at 447.
Hunk #5 FAILED at 495.
5 out of 5 hunks FAILED -- saving rejects to file encoder/macroblock.c.rej
patching file encoder/macroblock.h
Hunk #1 FAILED at 50.
1 out of 1 hunk FAILED -- saving rejects to file encoder/macroblock.h.rej
patching file encoder/rdo.c
Hunk #1 FAILED at 50.
Hunk #2 FAILED at 326.
Hunk #3 FAILED at 355.
Hunk #4 FAILED at 487.
Hunk #5 FAILED at 564.
5 out of 5 hunks FAILED -- saving rejects to file encoder/rdo.c.rej
patching file x264.c
Hunk #1 FAILED at 243.
Hunk #2 FAILED at 415.
2 out of 2 hunks FAILED -- saving rejects to file x264.c.rej
patching file x264.h
Hunk #1 FAILED at 35.
Hunk #2 FAILED at 239.
2 out of 2 hunks FAILED -- saving rejects to file x264.h.rej

[Dark Shikari]

Click download, don't copy/paste... :rolleyes:

Of course patching will fail if the text is not properly formatted...

[Ranguvar]

I did... just tried again, saving as text document and all files. Copy+pasting results in a different error (garbage in diff).

[Dark Shikari]

I did... just tried again, saving as text document and all files. Copy+pasting results in a different error (garbage in diff).Ensure that the encoding of the file matches the encoding of the x264 source files... this is really not very difficult...

[Ranguvar]

Both the source and the diff are ISO-8859-1 (or compatible).... saving as UTF-8, etc. also fails.

[kemuri-_9]

this shouldn't really be happening....
but have you tried converting the CR LFs in the downloaded file to LFs?
this may be causing the errors, or try the -l option in patch

[Dark Shikari]

Both the source and the diff are ISO-8859-1 (or compatible).... saving as UTF-8, etc. also fails.Windows encoding, or Unix?

One of them is CR/LF, the other is CR, of course it fails. I do not need to waste a page of this threading teaching people how to patch their source code.

[Ranguvar]

Thanks very much, kemuri :) I apologise for my noobishness in this area; I'm still very new to *nix. Did not know there was differences in the linebreak signaling. dos2unix from the hd2u package solved the problem.

[kemuri-_9]

windows uses CR LF, linux uses LF only, and mac uses CR only
(CR = Carriage Return - 0x0D; LF = Line Feed - 0x0A)
and why are they all different? to cause us all pain and suffering!

[Quark.Fusion]

A snap-poll (thread) would be nice if you're planning on implementing it.
I vote for the psy-opts to have little impact on the bitrate when compared to not using them, in CRF mode. Other people may be more forgiving about a large difference in bitrate.
Why you care about same bitrate in quality-based mode? You get better quality from psy-rd, but it depends on source.
Psy-algos works by raising quality where you see it and lowering where you don't, right? But gain in bitrate from lowering quality isn't the same as loss from raising it.
So bitrate at CRF can go in either side, because it's source who dictates bitrate, not CRF value.
And if you correct CRF you lowering quality somewhere and don't get same quality across clip, right?

[Quark.Fusion]

But if an option consistently and predictably increases both quality and bitrate while all ratecontrol options are held constant, then it's miscalibrated.
Is PSY-RDO increases bitrate on source without noise? What if you have face in center of clip and noise in the background (or face on the left and noise on the right) and then same face with clean background — shouldn't the face quality be same at CRF?

What if I adjust my CRF setting by visual comparing quality to get maximum value when I don't see ringing, then I turn on PSY and see compression artifacts in important to me areas? Should I make new comparison to get new CRF?

Any PSY option shouldn't lower quality where you see it at CRF, imho. Or it must be configurable, i.e. add "--add-psy" option to disable adjustion of CRF.

[akupenguin]

Or it must be configurable, i.e. add "--add-psy" option to disable adjustion of CRF.
What is "adjustion"? What decides that the baseline unadjusted value of psy-rd is ssd=>ssd+ac, as opposed to, say, ssd=>(ssd+ac)/2 ? If I change the meaning of any given quantizer, why do I have to keep the quantizer numbers constant rather than the perceptual quality? If I made a "--add-psy" but it did the opposite of what you suggest, i.e. enable the adjustment which was off by default, would you even be able to tell the difference?
Any psy option shouldn't lower the quality on average. But it should lower the quality of some movies to preserve the average, assuming it improves others.

[Quark.Fusion]

windows uses CR LF, linux uses LF only, and mac uses CR only
(CR = Carriage Return - 0x0D; LF = Line Feed - 0x0A)
and why are they all different? to cause us all pain and suffering!

I think it's related to early printers, when LF change line without carriage Return and carriage return without Line Feed.
http://en.wikipedia.org/wiki/Carriage_return
(You can overline wrongly typed text on typewrite with CR without LF)
On printers, teletypes, and computer terminals that were not capable of displaying graphics, the carriage return was used without moving to the next line to allow characters to be placed on top of existing characters to produce character graphics, underlines, and crossed out text.
On Mac file all text prints on same line :)

[Quark.Fusion]

If I made a "--add-psy" but it did the opposite of what you suggest, i.e. enable the adjustment which was off by default, would you even be able to tell the difference?
Did I understand right? PSY-RDO produces higher bitrate at CRF, so you increase CRF value to get same bitrate. With this adjustment you get lower overall quality that without it. So I will be able to tell the difference as both quality and bitrate will be different. Or you talk about comparing both to clip at same bitrate, but without PSY-RDO?
Any psy option shouldn't lower the quality on average. But it should lower the quality of some movies to preserve the average, assuming it improves others.
I think it's subjective what matter at CRF — average quality or not lower quality where user watch at it (minimum of quality). And user must have control on this.
For average you always have multipass bitrate-based mode.

P.S. sorry if my english wasn't perfect.

[Avenger007]

Why you care about same bitrate in quality-based mode?
Because I don't have infinite storage space.

You get better quality from psy-rd, but it depends on source.
This isn't about the source; I know I get better quality with psy-opts.

Psy-algos works by raising quality where you see it and lowering where you don't, right? But gain in bitrate from lowering quality isn't the same as loss from raising it.
And your point is...

So bitrate at CRF can go in either side, because it's source who dictates bitrate, not CRF value.
Actually, the CRF value does dictate relative bitrate.
Almost all clips I've tested show a significant increase (>25% @ CRF 22) in bitrate; I haven't been able to predict the exact increase amount.

And if you correct CRF you lowering quality somewhere and don't get same quality across clip, right?
Like I said...
Since the AQ and psy-* patches increase perceptual quality at the same bitrate when compared without them, then the increased bitrate when using CRF seems... uncalled-for.

[akupenguin]

Did I understand right? PSY-RDO produces higher bitrate at CRF, so you increase CRF value to get same bitrate. With this adjustment you get lower overall quality that without it. So I will be able to tell the difference as both quality and bitrate will be different. Or you talk about comparing both to clip at same bitrate, but without PSY-RDO?
Given that Dark Shikari has already posted the patch, yes you could compare it to another patch with a different effect. But suppose a different scenario: I post some implementation of psy, which you weren't allowed to look at the code of. In the interest of concreteness, lets make up some specific numbers: This hypothetical patch always increases quality-per-bitrate by exactly 10%, and doesn't change the average bitrate at any given CRF, but introduces a gaussian variation in bitrate with stddev=20%. (This doesn't make bitrate any less predictable than before; there was a certain amount of unpredictability both before and after the patch, I'm just quantifying the imperfect covariance between the two distributions). Therefore, the quality delta from enabling the option is +10+/-20%, and the probability of increasing quality on any given source is 70%. Is this outcome acceptable? Would you prefer it if I added an adjustment of +16% bitrate (i.e. a total of +16+/-20%) in order to change the quality distribution to +26+/-20% since that has a 90% chance of being better? Is 90% enough, or should I increase it more? What if I said the simplest way to implement the psy option inherently introduced the +16% bitrate bias and I offered to subtract 16% to bring average bitrate back to +0? Does it matter whether the psy option defaults to on or off, since the variance in bitrate applies in both directions? What if the psy option is more consistent in quality than non-psy, so a perfect object metric would actually say it's the non-psy option that has the unpredictability, would you then ask for the non-psy option to have higher bitrate so that disabling psy probably wouldn't decrease quality? Do you just want --psy to include an element of --placebo to convince people that it increases quality more than it really does?
(I realize that this isn't exactly the same scenario as I posed before, since this one is "bitrate average +0%, quality net positive", rather than "quality average +0%, bitrate net negative". But as I said before, I don't care that much between those two alternatives, only the +16% bitrate/+26% quality seems obviously wrong to me.)
Whatever your answer is, either make sure it's consistent with our verdict for --aq-sensitivity (http://forum.doom9.org/showthread.php?p=1091287#post1091287), or argue against that verdict too.

[Sagekilla]

I was just wondering.. SAD is a commonly used metric to compare blocks to each other to find the "best" match, and from what I understand PSY-RD takes that a step further by adding in SSD to the mix. Correct me if I'm wrong here, but would it not be useful to use the SAD + SSD as a new metric, sort of like SSIM? As Dark Shikari said, our eyes like to see an image that looks similar complexity wise, even if it's not perfect, so wouldn't this be a good perceptual metric on that basis?

Apologies if SSIM already does something like this or if I'm a bit naive in my views, but I thought I'd pose the question :)