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

[Dark Shikari]

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.No, SSD is the standard RD metric.

SAD is used for a fast bit cost estimation, SATD for a slower one. SSD is a measure of *distortion*, which SAD and SATD aren't.

[Quark.Fusion]

…but introduces a gaussian variation in bitrate with stddev=20%. […] 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? […] What if the psy option is more consistent in quality than non-psy

I was thinking that CRF is better alternative to CQP as here were sayed that it's better to use CRF for quality-based encodes, now when I make another look at it — it's VBR option.
Problem in constant quantizer is that in high-motion scenes, darker areas, etc. — you can increase quant without noticeable quality loss, as you will be unable to spot difference looking at video. All that I want is constant visible quality of video, I don't care much about variance in bitrate — if that part of video requires 2x bitrate for same visible quality as other part, then ok — give it that. I don't want perceptive quality-deltas around timeline. (If I see on logo in corner, I want consistent quality around all video, not better here and lower there)
Quality-based modes is about unpredictability of the bitrate. Quality-based modes shouldn't think about bitrate, except VBV buffer. I don't care how much space one video will take on my HDD, but I care how much space all my videos will take.
If Psy-option is more consistent in quality than non-psy — then that must be enabled without questions.

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.
If VAQ also introduces variance in perceived quality across video for more stable bitrate, then I also against that.

Maybe I get wrong by thinking that you care about more stable bitrate in quality mode — correct me if I wrong.


Now back to difference in quality between old and new modes — if you get better quality in only specific areas of video as with film grain, then you shouldn't adjust CRF to get same bitrate as old mode (but give user option is good idea). If you change quality in all areas, somewhere better, somewhere lower — then you should do quality tests what video is more similar to old mode by quality. Not tests "I want same bitrate as before in quality-based modes".
All, who care about end size of video should do second pass or use ABR mode.

[Quark.Fusion]

I was re-reading your post…
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?
I want more consistent quality.
As psy option is new and it's purpose is in better quality at cost of encoding speed and non-psy produces inconsistent quality, then my answers will be "I will live with unpredictability in quality or decrease of quality, if I can't afford the speed cost" and "I don't care about bitrate, only quality and how much space require all my videos together"

[Avenger007]

I want more consistent quality.
That's the problem... What is "consistent quality"?
Your best description would probably be the code used to determine "consistent quality", because that's what the encoder will use.

Now back to difference in quality between old and new modes — if you get better quality in only specific areas of video as with film grain, then you shouldn't adjust CRF to get same bitrate as old mode (but give user option is good idea). If you change quality in all areas, somewhere better, somewhere lower — then you should do quality tests what video is more similar to old mode by quality. Not tests "I want same bitrate as before in quality-based modes".
All, who care about end size of video should do second pass or use ABR mode.
IMO, psy-rd is almost always better than no psy-rd at the same bitrate.
So what do you think the quality will be at a higher bitrate?
Would that affect the way you use CRF when adjusting psy-rd (default, off, various strengths) to achieve your "consistent quality"?
If your answer is "yes" then you see the problem. If your answer is "no" then so be it. :cool:

[Quark.Fusion]

Let's take film grain as example. You get better overall quality at same bitrate, yes, and if you use bitrate mode then no problem here. But that film grain requires bits to store it and here is problem: if I specify quality for encode and codec tries to get same bitrate as without Psy-RDO it must lower quality in all other areas to make room for grain, but my decision on what CRF value to provide is based on tests when I don't see artifacts in most important areas. And what I get as result if codec changes CRF? Better quality with grain and lower quality in all other areas on which I make my decision for CRF, so codec produces not that quality was I want.
My desire with CRF when I specify Psy-RDO is to preserve more details without lowering quality of anything visible. It's OK if it require more bitrate as quality-per-bitrate is better and quality is the key. It's not the same as just increase bitrate by lowering CRF value (as gain will be less). If I want same bitrate — I run two-pass.

> So what do you think the quality will be at a higher bitrate?
It will be quality that I want from quality-based mode :)

You get lower bitrate in CRF with more refs, TESA search, CABAC, etc. But you don't change what CRF means to get same bitrate, right?

[Nikos]

From earlier Dark Shikari post (#513):

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.

From x264.937.modified.01.exe help:

--psy-rd Strength of psychovisual optimization ["1.0:1.0"]
RDO psyopts (requires subme>=6)
Trellis psyopts (requires trellis>=1)

-t, --trellis <integer> Trellis RD quantization. Requires CABAC. [0]
- 0: disabled
- 1: enabled only on the final encode of a MB
- 2: enabled on all mode decisions

The conclusion:
With defaults settings --psy-rd 1.0:1.0 -trellis 0, the psy trellis don't run.

Which is the difference between:
--psy-rd 1.0:1.0 -trellis 1
and
--psy-rd 1.0:1.0 -trellis 2

[wyti]

the difference is that with --trellis 1 Trellis is only used on the Final Encode of a MacroBlock (and psytrellis is only run when trellis is run right ?)
and with --trellis 2 Trellis is always run (better quality at the cost of speed)

[Dark Shikari]

the difference is that with --trellis 1 Trellis is only used on the Final Encode of a MacroBlock (and psytrellis is only run when trellis is run right ?)
and with --trellis 2 Trellis is always run (better quality at the cost of speed)correct

[Nikos]

The conclusion:
With --psy-rd 1.0:1.0 --trellis 1 psy trellis enabled only on the final encode of a MB.

With --psy-rd 1.0:1.0 --trellis 2 psy trellis enabled on all mode decisions.

With --psy-rd 1.0:0.0 --trellis 1 trellis enabled only on the final encode of a MB.

With --psy-rd 1.0:0.0 --trellis 2 trellis enabled on all mode decisions.

With --psy-rd 1.0:0.0 --trellis 0 trellis and psy trellis are disabled.

With x264.937.modified.01.exe defaults settings --psy-rd 1.0:1.0 --trellis 0 trellis and psy trellis are disabled.

Thanks

[Kurtnoise]

Keep in mind that the strength are not static...

we can have --psy-rd 1.0,0.800 --trellis 2 by example.

[Nikos]

I know that the psy trellis strength are not static, but i don't know what's the difference between --psy-rd 1.0:0.8, --psy-rd 1.0:1.0, --psy-rd 1.0:1.2.
In simple words, what's the meaning of psy trellis strength?

[kemuri-_9]

the strengths for psy-rd and psy trellis are currently allowed to be in the range of floats of [0,10], meaning it goes as high as a strength of 10.
(any values outside the range will be clamped to be within the range before processing)

trellis as far as i can remember has always defaulted to a default of 0, and as it has noticeable speed consequences, i infer that is why it is still default of 0 with the patch.

the patch changes the default subme from 5 to 6 to allow psy-rd to be run from the start though.

from what i've briefly browsed through the code again, it only appears once in an actual calculation:
int psy_value = h->mb.i_psy_trellis * abs(predicted_coef + unquant_abs_level * signs[i]);

this is a part of the actual psy trellis section which boils down to
ssd = (int64_t)d*d * coef_weight[i] - psy_weight * psy_value;
compared to the standard non psy trellis version
ssd = (int64_t)d*d * coef_weight[i];

so the psy trellis strength is effectively a scalar multiplier of how much to apply
/* Psy trellis: bias in favor of higher AC coefficients in the reconstructed frame. */

[Quark.Fusion]

correct

thank you, I was answer the same question :) It wasn't clear what psytrellis is and how it related to old trellis.

[TheBashar]

Am I mistaken in believing that CRF should be able to handle non-integer values?

I just completed three test encodes for a low quality TV show at CRF 27, 27.5 and 28. Surprisingly, the encodes came in at 15.1MB, 11.0MB, and 12.7MB respectively.

All three encodes were done using bob0r's x264.937.modified.01.exe with the same command line (excecpt crf obviously). The commandline was:

program --crf 27.5 --level 3.1 --keyint 1800 --ref 8 --mixed-refs --no-fast-pskip --bframes 5 --b-pyramid --b-rdo --bime --weightb --filter -2,-1 --subme 6 --trellis 2 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --me umh --threads auto --thread-input --progress --no-psnr --no-ssim --output "output" "input" --b-adapt 2

Unfortunately, I don't have the log from the 28.0 encode. Comparing the logs from the 27.0 and 27.5 two things stand out. First, while I recall that the 28.0 encode was around 1.5fps and the 27.0 encode resulted in 1.64fps the 27.5 encode was considerably faster at 2.02fps. Secondly, the consecutive b-frame statistics for the 27.0 and 27.5 encodes are substantially different.

27.0: 1.2% 5.4% 59.8% 14.4% 12.3% 6.9%
27.5: 21.7% 5.0% 49.6% 10.9% 9.0% 3.8%

I posted the question in this thread because I was using the new psy-rdo and psy-trellis.

Thanks

[Sagekilla]

x264 should be able to handle float values of CRF perfectly fine. I don't know why 17.5 would be smaller than both 27 and 28, but it sounds like a bug.

[Shinigami-Sama]

it supports anything from 0 - 10
with I think single floating point precision(so like 3 decimals?)
the fact the size came out different shows that it worked

[kemuri-_9]

Am I mistaken in believing that CRF should be able to handle non-integer values?

I just completed three test encodes for a low quality TV show at CRF 27, 27.5 and 28. Surprisingly, the encodes came in at 15.1MB, 11.0MB, and 12.7MB respectively.

if( h->param.rc.i_rc_method == X264_RC_CRF )
h->param.rc.i_qp_constant = h->param.rc.f_rf_constant;
the cli directly accepts floats, but this implicit float to int casting is more than likely the problem.

the code would need to be
1. more altered to accept float qp constants (rather than the current int only) (decent code editing/potential feature request?)
or
2. just strike out float precision and go to int (simpler - just a few line changes)

[TheBashar]

Am I mistaken in believing that CRF should be able to handle non-integer values?

I just completed three test encodes for a low quality TV show at CRF 27, 27.5 and 28. Surprisingly, the encodes came in at 15.1MB, 11.0MB, and 12.7MB respectively.

Please disregard. I was running some more tests when megui crashed with some kind of memory error. Three subsequent tests of the crf 27.5 all resulted in encodes sized between 27-28 and all within 4kb of each other. Some memory corruption must have caused the earlier anomalous result.

[plane]

I do not care ALL about metrics, I just disagree with you that metrics are useless.
PSNR and SSIM have been created as a tool for comparing quality. The people which created it have made many tests and in especially of SSIm compared their metrisc to Perceptual Quality which was all described in the article.
Let me give you the example. The knife is a tool used to cut things. It works pretty well in most cases but you have found that it can not cut metal and insist on that example to saying it is USELESS.


Metrics is just a tool for reference purpose no matter it is PSNR or SSIM. They are objective benchmark program and in video area, many folks really toward subjective method instead.

In the computer gaming area, many times those benchmark tools do not reveal the actual gaming experience as well. When it comes to the video side, the situation become even more complicated. I have been used x264 for more than two years, in the old day we have had enough PSNR/SSIM racing on doom9. Now it's time to improve the true quality.

I won't be surprised if there is a hardcore who said like metrics are useless. Indeed, they are useless. Ask any serious photographicer, I think 99% of em will tell you they only believe their eyes in photoshop.

[tetsuo55]

Yeah those synthetic benchmarks are important. They are unable to show phychovisual enhancements but that doesn't matter. (thats like faulting a benchmark of a game's FPS because it doesn't tell you if the game is fun)

[Sharktooth]

... once again and for all ...
metrics can be a reference for measuring inprovements in algos but dont tell the truth about quality since the human visual system is so complex it cant be even approximated by a simple mathematical model like PSNR or SSIM.

[Quark.Fusion]

Photoshop isn't best software from image quality PoV. It don't have lanczos/blackman resize or good color reduction and png optimization (for web).
Metrics can show something that your eyes can't, but same apply in other side. So it's better to use eyes and metrics. (If you don't see difference, then look at metric).

Edit: forget to ask — is chain-encoding good way to see difference in quality? what metric will say in that case?

[Sagittaire]

I won't be surprised if there is a hardcore who said like metrics are useless. Indeed, they are useless. Ask any serious photographicer, I think 99% of em will tell you they only believe their eyes in photoshop.

Well it's not useless ... but you must just use the correct threshold. With Delta at 0.2 dB you can't conclude but you can with delta at 2.0 dB. It's the same case with SSIM ...

[Sharktooth]

empiric deltas... no thanks...
a visual check is always needed.

[Sagittaire]

empiric deltas... no thanks...
a visual check is always needed.

No encoding at 45 dB will be always really better than encoding at 35 dB. A visual check is not needed here.

[Sharktooth]

what does it mean "better"?
...always the same dicussion... there's no best. maybe i like the blockfest more than smoothing so the 35 db (and blocky) encode may look better to me than a 40 db (and smooth) encode.
you still fail to understand quality is subjective. so, no, higher PSNR does not mean "better" qualty. maybe it's better for you but not for others.

[CruNcher]

No encoding at 45 dB will be always really better than encoding at 35 dB. A visual check is not needed here.

Tough it doesn't mean it's going to fall apart especialy not with high quality source as input but the golden rule is still starting with 38/39 dB use your eyes to judge @ 35 dB you can be pretty sure its gonna artifacting (tough it wont even block like Sharktooth said inloop deblocking is pretty nicely preserving that in most cases you will get other kind of artifacts like the ones you see @ joost these strange fizeled edges for example especialy in motion.
With direct spatial you gonna see more strange motion happening (backgrounds start moving with the camera) and you gonna see strange diagonal lines appearing @ block edges after movements the lower you go with the bitrate) :) also @ these bitrates --no-fast-pskip are gonna give a complete different look (perceptively more details less blur but tough heavier artifacts in motion) we are somewhere around 28 dB now (blocking ofcourse isn't possible to hide anymore too) ;).

[Sharktooth]

or maybe it is simply a bit colorshifed of brighter... but looks much better than the higher PSNR one...

[smok3]

http://somestuff.org/flashAVC/flvplayer.php?moviename=movies/theexpress2-x1056y448.mp4
insane 2pass, 1800 kbits, using 0.6 psy-rd.

[Sharktooth]

since my sight is gone nutz, to facilitate the viewing i bought a projector and a huge panel so i can still appreciate some HD stuff.
well, even if it is SD i watched the trailer you posted and some other encodes that are there. they seem quite good to me for the bitrate.

hint: im sure zambelli or ben will be be delighted too...

[Sagittaire]

or maybe it is simply a bit colorshifed of brighter... but looks much better than the higher PSNR one...

Perhaps but codec produce never that. Codec never change artificialy brigheter, contrast or color but try simply to produce in output the same than in input. Encoding at 45 dB will be always better for visual quality than the same encoding at 35 dB. It's like that. Final Point.

I hear that for some codec developper (H264) the PSNR thresold delta is 1.5-2.0 dB even with high psy optimisation.

[Sagekilla]

IIRC, it's been said you can see differences (objectively, in the case of a patch that say improves P and B Frames) when the psnr difference is as much as 0.5 dB. Anything over that should be noticeable, especially if it's 35 dB vs 45 dB. In that case there would be a dramatic difference. Objectively, of course. When we throw the subjective enhancements into the mix you can't really compare the old algo to the new one.

[CruNcher]

What is a dramatic difference for you if stability of the picture doesn't change and only the noise/detail layer does imho there is only 1 real hard issue and that is film grain. Without FGM that will allways stay a issue in low bitrates that H.264 is very well capapble of like 720p @ 3 mbit the grain layer alone needs aprox 3 mbit so you allways endup @ 6 mbit when trying to preserve it FGM could change that so in the end you have a 3 mbit encode with 6 mbit subjective result :)

[Audionut]

FGM could change that so in the end you have a 3 mbit encode with 6 mbit subjective result :)

But it still wouldn't be better.

[CruNcher]

Not really no, tough the regraining on playback would imitate the original much better then any current grain post pro that does it randomly, and make it this way much more beliveable and it wouldn't look as flat anymore (artificial). The way psy tries to reach this is allways the same it takes bits from somewhere and adds it where you want to get the effect (at high bitrates this can work very well but the lower you go the more problematic it gets, because you want also a stable detailful experience). With FGM the decoder adds the effect directly (based on the source or film stock) and doesn't try to get it from somewhere else, it's not shifting bits it creates them :)

I guess the actuall way it works is entirely on the Decoder side (database with Film Stocks) and in the bitstream their is only a sei or something written that tells the Decoder in what Scene he has to use wich Film Stock basicly something like [gstart Vision2 500T 5218].
But im not 100% sure it could be much more complex maybe even positional data of the original grain is written into the bitstream so it also adds the exact type @ the exact location as the Source, tough this would mean they Recorded these Data before wich isn't impossible todo basicly you would use Degraining data and record it. I guess as Time is more money in Hollywood (and im not sure what overhead writing all these positional data would create wich ofcourse would lower the bitrate win again) it's just a simple Database of pre recorded Film Stocks that get applied when asked for by the Decoder.

[wyti]

But this is consider as post-processing and this have to be implemented in the decoders.
I doubt that you can do this in the side of the encoder.

[Ranguvar]

It does indeed have to be implemented in the decoder as well, and nobody's sure whether any commercial decoders support it (libavcodec/ffdshow doesn't, for now). It's both in the encoder and decoder. If x264 gets FGM, though, it will most likely be implemented in libavcodec as well.

[CruNcher]

Isn't Cyberlinks Decoder supporting it at least it shows the possibility being able to ? tough it's called FGT their Film Grain Technology i guess their Decoder is capable of it there are just no titles released yet that can make use of it and i guess no one would even realize if it's being used :D

[smok3]

bbb 720p, balanced settings, 2pass targeting 1800kbits
http://somestuff.org/flashAVC/flvplayer.php?moviename=movies/BBB-1080downsized-x1280y720.mp4

[CruNcher]

It stutters here i guess thats because of the shitty decoder performance (Adobe do something) i tried in tcpmpx and there it works fine no stuttering in firefox @ 2.2 Ghz DualCore, it would be so easy just enable GPU Accelleration and it would be blasting Silverlight away, tough that ofcourse wouldn't help older systems :(

[kemuri-_9]

it's included in Flash player 10 (currently Beta RC):
http://labs.adobe.com/technologies/flashplayer10/releasenotes.html#features_vpi

[fields_g]

My Merom 2.0ghz seems to handle it just fine.

[CruNcher]

it's included in Flash player 10 (currently Beta RC):
http://labs.adobe.com/technologies/flashplayer10/releasenotes.html#features_vpi

No Mainconcept has to get their GPU Decoding right way back in Elecard times it worked nicely but after the Mainconcept changes it suddenly stoped working, tough i guess for the Flash player it needs even a different approach as it is not going over directshows dxva :(
But wait i see August 11 a new Flash was released i have the older 10 release :) lets see

Nope not better but whats also strange about this Flash stuttering it only seems to happen in Camera Pans the intro is allready showing that when the camera pans down in the middle of the Pan it stutters shortly. Also all the other Camera Pans stutter when the Characters are moving everything is fine, but as soon as the camera starts moving it goes to stutter somewhere in the Pan (like it would stop and skip a frame and then continue) tough looking @ the cpu utilization i cant explain why this might happen everything seems fine :(. These stutters are allways @ the same times in the Pans so it doesn't seem to be caused by a priority problem either tough i gonna try to set firefox priority higher and see what happens (no effect).
I only remember something similia in another context with X264 and that is low bitrate and the use of --direct spatial tough --direct auto should be fine --direct temporal perfect but it looks a little different then this stuttering here (i called the other effect pan wobling) .

Pan wobling in low bitrate looks like this tough the one here is different it's more like short stop and go
http://mirror05.x264.nl/CruNcher/force.php?file=./direct-spatial-extreme-wobling.mkv
http://mirror05.x264.nl/CruNcher/force.php?file=./direct-auto-less-wobling.mkv
http://mirror05.x264.nl/CruNcher/force.php?file=./direct-temporal-stable.mkv

No Problems outside of firefox and flash via MPC-HC either (Mainconcept Decoder,ffdshow) with it i give up :( (no idear where these stuttering in the Paning come from seems tough im the only one experience this currently)

[smok3]

is there a way to check if core plugin is installed? so i can offer that in priority to flash.

edit: the only difference with other encodes is that audio is 6ch aac sbr, which can take some additional cpu, and that i didn't bother to use -hint option with mp4box...

[CruNcher]

@smoke3
http://s3.directupload.net/file/d/1528/uygfquhf_png.htm <- it seems the problem is entirely on my side this kernel time looks suspicous could be a driver problem that Flash doesn't seem to like much, maybe it's even coming from the new Nvidia drivers or in the worst case from the Flash Plugin.
No no Driver Problem -> http://s7.directupload.net/images/080821/norooi7q.png

After restarting Firefox it's much better now with the 37 tabs here (with flash runining in some of them no video) seems to be a extreme test for Firefox and Flash :)
Opera seems todo better under these extreme conditions here under Windows

Runnin Big Buck 720p in the last tab (tab count 37)

Firefox 3.0.1
http://s1.directupload.net/images/080821/4fh3qh7k.png
Opera 9.52
http://s8.directupload.net/images/080821/8jfj8mfs.png

is there a way to check if core plugin is installed? so i can offer that in priority to flash.

edit: the only difference with other encodes is that audio is 6ch aac sbr, which can take some additional cpu, and that i didn't bother to use -hint option with mp4box...
Sorry dunno how todo that, there is not much information about it still as the successor CorePlayerX was in the makeing i dunno what happened with it maybe they gave up on it seeing flash coming shortly after them with support.

[smok3]

testing the playback on the other machine (opteron) i get almost 100% fluid playback, very slight strobe at the opening pan-down and very slight jumps here and there (occasional tearing as well, very slight and only when buffering is very close to playback head).

[jefrey]

Hi guys i have a currious problem with the new builds and trellis psytrellis, i've reencoded a bunch of blurays and some of them, two at the moment have encode errors.
For about 2-3 seconds, it looks like the enocoder have used tooo low bitrate and i see huuuge blurred macro blocks on an action szene or a marvel flipbook, they are very very huge, but just for 2-3 seconds in the whole movie,

my encodes are @ ~10000kbs and i didn change anything that can increase this corrupt ~3seconds :(

what can solve this problem?

[poisondeathray]

Hi guys i have a currious problem with the new builds and trellis psytrellis, i've reencoded a bunch of blurays and some of them, two at the moment have encode errors.
For about 2-3 seconds, it looks like the enocoder have used tooo low bitrate and i see huuuge blurred macro blocks on an action szene or a marvel flipbook, they are very very huge, but just for 2-3 seconds in the whole movie,

my encodes are @ ~10000kbs and i didn change anything that can increase this corrupt ~3seconds :(

what can solve this problem?

Are you sure it's psyrdo/psytrellis, not some other setting?

If you turn psyrdo/psytrellis off do you still get macroblocks? (--psy-rd 0:0)

Decrypted properly?

VBV setting?

[jefrey]

the settings are the same and i use always 2pass vbr
i never changed them because, never change a running system:D and the only thing i changed i activated trellis /psytrellis.

i will see tomorrow if the error is still there, i startet the encode again. Maybe dss or ffmpeg make this shit happen :(

[CruNcher]

@jefrey
join http://forum.doom9.org/showthread.php?t=140326&page=3 <- seems somhow some old issue is coming back