HQ vs Insane preset in megui [Archive]

roozhou

22nd June 2009, 14:51

Ya, thats what I thought, I just wanted other peoples opinions on the matter. Because I've tried to look to see if there were any differences between the two, I can't say I found any.

"Insane" settings are just placebos. Actually my test shows that insane settings would even give worse visual quality. I posted two samples encoded with subme 6 and subme 9, and the comments were very interesting.

http://forum.doom9.org/showthread.php?p=1293408#post1293408

Dark Shikari

22nd June 2009, 17:45

"Insane" settings are just placebos. Actually my test shows that insane settings would even give worse visual quality. I posted two samples encoded with subme 6 and subme 9, and the comments were very interesting.If you think subme 9 is worse than subme 6, you have to immediately distrust the entirety of x264's analysis and switch to subme 5. There is no other choice, since if subme 9 is worse than 6, that means RDO's decisions are wrong, and thus 6 is clearly worse than 5.

Fortunately, since I'm not stupid, I'm not going to waste my time on trolls like this.

roozhou

22nd June 2009, 18:12

If you think subme 9 is worse than subme 6, you have to immediately distrust the entirety of x264's analysis and switch to subme 5. There is no other choice, since if subme 9 is worse than 6, that means RDO's decisions are wrong, and thus 6 is clearly worse than 5.

Fortunately, since I'm not stupid, I'm not going to waste my time on trolls like this.

It is not my opinion that subme 9 is worse than subme 6. Please take a look at the two samples and all the following posts.

Dark Shikari

22nd June 2009, 18:24

It is not my opinion that subme 9 is worse than subme 6. Please take a look at the two samples and all the following posts.Wait, are you seriously trying to take a piece of low-bitrate anime and applying the results universally to all videos? Is this a joke?

Also, the first one is subme9, you can tell trivially by looking at any of the B-frames. Furthermore--obviously--the subme 9 one has more detail and better dithering because that's what psy-rd does. It also has slightly blurrier lines--because that's, again, what psy-rd does.

If you don't like the effect of psy-rd on anime, turn it off instead of trolling and spreading blatant FUD across these forums with absurd statements like "subme 6 is better than subme 9."

Seriously, this a complete waste of everyone's time.

roozhou

22nd June 2009, 18:40

Wait, are you seriously trying to take a piece of low-bitrate anime and applying the results universally to all videos? Is this a joke?

Also, the first one is subme9, you can tell trivially by looking at any of the B-frames. Furthermore--obviously--the subme 9 one has more detail and better dithering because that's what psy-rd does. It also has slightly blurrier lines--because that's, again, what psy-rd does.

If you don't like the effect of psy-rd on anime, turn it off instead of trolling and spreading blatant FUD across these forums with absurd statements like "subme 6 is better than subme 9."

Seriously, this a complete waste of everyone's time.

Once again, I have never said "subme 6 is better than subme 9". I post this because I thought this should shock x264 devels and help x264 developing.

OK you are right, but everyone else in that thread were wrong and shown preference for subme 6. I also sent them to some friends and all of them thought the subme 6 one was better. Please remember the subme 6 one was also encoded with default psy-rd setting.

Dark Shikari

22nd June 2009, 18:42

Once again, I have never said "subme 6 is better than subme 9". I post this because I thought this should shock x264 devels and help x264 developing.

OK you are right, but everyone else in that thread were wrong and shown preference for subme 6. I also sent them to some friends and all of them thought the subme 6 one was better. Please remember the subme 6 one was also encoded with default psy-rd setting.Surprise: psy-RD is bad on low-bitrate anime. Since subme 9 uses more psy-RD than subme 6, it's worse.

Haven't I said this about a thousand times before?

(It's also because psy-RD tends to increase the bits spent given a certain quantizer, so if you run psy-RD on P-frames only, e.g. subme 6, they get boosted with respect to B-frames, which might help here. Psy-RD also tends to bias somewhat against skips in B-frames, which costs some bits.)

roozhou

22nd June 2009, 18:53

Since subme 9 uses more psy-RD than subme 6, it's worse.

Haven't I said this about a thousand times before?

No, this is the first time. And you admitted that sometimes subme 9 is worse than subme 6.

Dark Shikari

22nd June 2009, 19:01

No, this is the first time.No, I've said it hundreds of times before, but you've ignored me, because you are a troll.And you admitted that sometimes subme 9 is worse than subme 6.No, I just repeated what I said earlier; that if the RD metric can't be trusted, everything RD will be worse than everything non-RD (so subme 5 will be better than subme >= 6).

As you have never contributed anything remotely of value to these forums, I am not going to bother with you anymore. You do nothing but mislead ordinary users with contrived examples and incorrect information.

gizzin

22nd June 2009, 19:38

"Insane" implies that you will spent a whole lot of additional encoding time for a very minor (if at all) quality improvement.

Would you agree with this shakiri? Depending on bitrate and source?

roozhou

22nd June 2009, 19:43

No, I've said it hundreds of times before, but you've ignored me, because you are a troll.

Please give me links to "hundreds of times", and pay attention to Rule 4.

Adub

23rd June 2009, 17:54

Would you agree with this shakiri? Depending on bitrate and source?

I'll answer for him. Yes, "I" agree. Once you understand what some of the settings actually DO, then yes, some of them are practically placebo's. ex. "--me tesa". It's almost more of an academic exercise than anything else.

ChronoCross

23rd June 2009, 22:13

Please give me links to "hundreds of times", and pay attention to Rule 4.

Read all the x264 threads, IRC conversations, mailing lists, etc. It's not like it's all that hidden.

Using options not meant to be used for your particular source isn't useful testing. you should better optimize your settings and put out a test that makes more sense.

Cyber-Mav

23rd June 2009, 23:37

Please give me links to "hundreds of times", and pay attention to Rule 4.

man you should take Dark Shikari's word as gospel, afterall he helped me make x264 so he does know a thing or 2 about it. :)

Dark Shikari

23rd June 2009, 23:39

man you should take Dark Shikari's word as gospel, afterall he helped me make x264 so he does know a thing or 2 about it. :)Though it doesn't mean I don't make stupid mistakes at times either ;)

And taking things as gospel tends to be dangerous, as it stifles creativity. But re-analyzing the gospel does require actual testing, not just unsubstantiated claims.

roozhou

24th June 2009, 06:40

man you should take Dark Shikari's word as gospel, afterall he helped me make x264 so he does know a thing or 2 about it. :)

I used to, but now I don't.

Using options not meant to be used for your particular source isn't useful testing. you should better optimize your settings and put out a test that makes more sense.

My conclusion is that sometimes psy-rd makes subme 9 worse than subme 6. Why should I tweak my settings to make subme 9 better than subme 6, in order to please x264 devels?

Dark Shikari

24th June 2009, 07:24

My conclusion is that sometimes psy-rd makes subme 9 worse than subme 5. Why should I tweak my settings to make subme 9 better than subme 5, in order to please x264 devels?Fixed that for you.

roozhou

24th June 2009, 07:52

Fixed that for you.

But my test was run on subme 6 vs subme 9 and this is only your inference.

Maybe better in this way:

With psy-rd enabled, higher subme value may result in worse visual quality.

Dark Shikari

24th June 2009, 07:56

But my test was run on subme 6 vs subme 9 and this is only your inference.No, I've tested it. I don't make claims without tests.

By definition, if psy-RD gives worse results than no psy-RD, then subme 5 will almost certainly be better than subme 9, because subme 5 means there is no psy-RD. This is not hard to understand, is it? :rolleyes:

Anyways, it seems I'm reneging on my promise to not bother with you again. Welcome to my ignore list; I recommend to everyone else to do the same, as your posts are a complete waste of space.

Audionut

24th June 2009, 08:21

Actually my test shows that insane settings would even give worse visual quality. I posted two samples encoded with subme 6 and subme 9, and the comments were very interesting.

Ok, I realize i'm getting old, but I see.

Well, I think
1.mkv is subme6
2.mkv is subme9

I might be wrong but I prefer 2.mkv

i think 1.mkv is subme6 and 2.mkv is subme9. 2.mkv has noticeably less noise/artifacts near areas of motion, at least in the one frame that i looked at. not surprising cus the setting applies to motion estimation

Where do you get, "Actually my test shows that insane settings would even give worse visual quality", "and the comments were very interesting", and "It is not my opinion that subme 9 is worse than subme 6. Please take a look at the two samples and all the following posts", out of 2 comments?

Does your link post to the wrong thread? Are you on drugs? Seriously!!

roozhou

24th June 2009, 09:46

Ok, I realize i'm getting old, but I see.

Where do you get, "Actually my test shows that insane settings would even give worse visual quality", "and the comments were very interesting", and "It is not my opinion that subme 9 is worse than subme 6. Please take a look at the two samples and all the following posts", out of 2 comments?

Does your link post to the wrong thread? Are you on drugs? Seriously!!

I also gave these samples to my friends and all of them showed preference to 2.mkv.

Actually 1.mkv is subme 9 and 2.mkv is subme 6. That's why I said "insane settings are placebos". I did not take my own test because I knew which one is subme 9 and I would search for more details in it.

No, I've tested it. I don't make claims without tests.
Was your test a blind test? Plz post your encoded samples and don't forget to remove x264 settings from the bitstream.

TiGR

24th June 2009, 15:26

Do you want to do some testing? Then why don’t you encode your low-bitrate anime at these settings:

--subme 5 (no psy)
--subme 6 --psy-rd 0:0
--subme 6 --psy-rd 1:0
--subme 6 --psy-rd 1.5:0
--subme 9 --psy-rd 0:0
--subme 9 --psy-rd 1:0
--subme 9 --psy-rd 1.5:0 (most psy)

I think that with psy-rd off you’ll see subme5 < subme6 < subme9, and with psy-rd on you’ll see, as you mentioned already, subme6 > subme9. You’ll most probably note that subme9 with strong psy is the worst and subme9 without psy is the best, which would not be possible if it was the --subme level itself what degraded the quality.

What is good in mid-high bitrate situations is not always good in low-bitrate ones. --psy-rd 1:0, --aq-strength 1 and --qcomp .6 (alas!) can all degrade quality in some cases. Settings that are not merely quality/speed trade-off are meant to be tuned, that’s why they aren’t hardcoded I think.

Feel free to prove me wrong, but don’t spread misinformation.

roozhou

24th June 2009, 18:09

Do you want to do some testing? Then why not you encode your low-bitrate anime at these settings:

--subme 5 (no psy)
--subme 6 --psy-rd 0:0
--subme 6 --psy-rd 1:0
--subme 6 --psy-rd 1.5:0
--subme 9 --psy-rd 0:0
--subme 9 --psy-rd 1:0
--subme 9 --psy-rd 1.5:0 (most psy)

So what form of test would you suggest? A vote for the favorite?

You’ll most probably note that subme9 with strong psy is the worst and subme9 without psy is the best, which would not be possible if it was the --subme level itself what degraded the quality.
Users don't care whether psy-rd 1.0 makes subme9 the worst or subme9 makes psy-rd 1.0 the worst. They only need to know the fact that with psy-rd enabled higher subme value(above 5) may bring worse visual quality on animes.

rack04

24th June 2009, 18:23

don't forget to remove x264 settings from the bitstream.

What is your reasoning for this?

kemuri-_9

24th June 2009, 18:27

Users don't care whether psy-rd 1.0 makes subme9 the worst or subme9 makes psy-rd 1.0 the worst. They only need to know the fact that with psy-rd enabled higher subme value(above 5) may bring worse visual quality on animes.

and that point was already made in other locations on the forums.
in the original psy-rd/psy-trellis test thread for starters iirc.

However, your original argument did not include the specific reference to anime either.
So it seems like you're trying to cover the tracks of your original unsound argument.

What is your reasoning for this?
because he likes being secretive/elitist about his settings and promotes others being similar

TiGR

24th June 2009, 18:33

So what form of test would you suggest? A vote for the favorite?
A thought experiment. There’s no need to do any actual encodes as the results are fairly predictable, I presume. I wrote them down just to emphasize the two settings that vary in this “subme problem” and their respective ourcomes in the given low-bitrate scenario.

Why should I tweak my settings to make subme 9 better than subme 6, in order to please x264 devels?
Because it delivers higher quality? :rolleyes:

rack04

24th June 2009, 18:34

because he likes being secretive/elitist about his settings and promotes others being similar

Sounds like it. If you're conducting a blind review why would removing the encoder settings from the bitstream matter?

ChronoCross

24th June 2009, 18:42

Users don't care whether psy-rd 1.0 makes subme9 the worst or subme9 makes psy-rd 1.0 the worst. They only need to know the fact that with psy-rd enabled higher subme value(above 5) may bring worse visual quality on animes.

Well this statement is also based on a single test of a single scene from a single anime. While you might very well be right for low bitrate anime (of which your encode is absurdly small for both the length of the video and the resolution) you need to provide a wide range of tests instead of basing what you have found for this single clipset.

Your primary problem and statement of contention is your trying to prove that your test was globally true for all sources of which currently you have shown no evidence of such.

roozhou

24th June 2009, 18:56

What is your reasoning for this?

I need a blind test. People can easily see the settings via Mediainfo. On my computer the settings can even be seen in the Explorer's status bar.

If people knows the settings for each video, they will assume that slower settings bring better visual quality. They will search for more details in videos w/ "insane" settings and search for more artifacts in those w/ "sane" settings. This makes the test completely pointless.

because he likes being secretive/elitist about his settings and promotes others being similar
Please read carefully before you post:
http://forum.doom9.org/showthread.php?p=1293408#post1293408

The audience watch the video not your x264 settings. For ordinary people the user data string does nothing except waste bitrate.

I know some people use all "insane" settings to save 0.0001% of bits. User data is just another 0.0001% of bits and the removal of it costs nothing.

roozhou

24th June 2009, 19:02

Well this statement is also based on a single test of a single scene from a single anime. While you might very well be right for low bitrate anime (of which your encode is absurdly small for both the length of the video and the resolution) you need to provide a wide range of tests instead of basing what you have found for this single clipset.

Your primary problem and statement of contention is your trying to prove that your test was globally true for all sources of which currently you have shown no evidence of such.

Have you seen the word "may" in my conclusion. To prove something "may" happen, a single example is sufficient.

ChronoCross

24th June 2009, 19:18

The audience watch the video not your x264 settings. For ordinary people the user data string does nothing except waste bitrate.

I know some people use all "insane" settings to save 0.0001% of bits. User data is just another 0.0001% of bits and the removal of it costs nothing.

Your argument about this is utterly pointless for removing the settings in regular practice. It's such a negligible amount of space that I could also argue that the extension should be removed from the file as I could always use Open with and the file would still be playable just to save space.

Have you seen the word "may" in my conclusion. To prove something "may" happen, a single example is sufficient.

yeah and I may jump off a bridge tomorrow because someone my age has jumped off a bridge before. Doesn't make my finding significant enough to warrant discussion.

roozhou

24th June 2009, 19:35

Your argument about this is utterly pointless for removing the settings in regular practice. It's such a negligible amount of space that I could also argue that the extension should be removed from the file as I could always use Open with and the file would still be playable just to save space.
The settings are 100 times more bits than the extension.
And what about thinking this in an opposite way. Does adding settings to bitstream give anything useful to the audience?

yeah and I may jump off a bridge tomorrow because someone my age has jumped off a bridge before.
Logically your statement is correct, and so is my conclusion.

ChronoCross

24th June 2009, 19:42

The settings are 100 times more bits than the extension.

And what about thinking this in an opposite way. Does adding settings to bitstream give anything useful to the audience?

omgodz a 100 bits of space wasted. call the hard drive police.

It allows for troubleshooting of files based on what settings they were created with. For example Quicktime only supports certain featuresets of the h264 standard. If someone asks why somehting isn't working right in quicktime the bitstream will tell us what features were used and why that clip is failing. Without that it would be much more difficult to determine the possible program.

Logically your statement is correct, and so is my conclusion.

You'd fail pretty much every science class ever but sure i suppose that you conclusion is "correct"

rack04

24th June 2009, 20:26

I need a blind test. People can easily see the settings via Mediainfo. On my computer the settings can even be seen in the Explorer's status bar.

If people knows the settings for each video, they will assume that slower settings bring better visual quality. They will search for more details in videos w/ "insane" settings and search for more artifacts in those w/ "sane" settings. This makes the test completely pointless.

Well then you need to improve your blind tests. Why would you let them use Mediainfo before watching the video?

roozhou

24th June 2009, 20:40

omgodz a 100 bits of space wasted. call the hard drive police.
The user data takes ~0.5k bytes not 100 bits.

For example Quicktime only supports certain featuresets of the h264 standard. If someone asks why somehting isn't working right in quicktime the bitstream will tell us what features were used and why that clip is failing. Without that it would be much more difficult to determine the possible program.

All compatibility issues(levels, ref frames, CABAC/CALVC, b-frames, etc.) can be found easily without the help of x264 settings. If you can't, that's your problem.

roozhou

24th June 2009, 20:46

Well then you need to improve your blind tests. Why would you let them use Mediainfo before watching the video?

I upload the samples and anyone can download and post comments on them. I just asked my friends to find their favorite sample. It is impossible for me to show the samples to every tester face to face.

ChronoCross

24th June 2009, 22:14

The user data takes ~0.5k bytes not 100 bits.

Dark_Shikari was right. You are a troll.

All compatibility issues(levels, ref frames, CABAC/CALVC, b-frames, etc.) can be found easily without the help of x264 settings. If you can't, that's your problem.

I can find them however a typical user "audience" may be people who aren't as versed in the intricacies of h264. removing the bitstream information can only hurt, it has no useful help to the format.

roozhou

25th June 2009, 05:25

I can find them however a typical user "audience" may be people who aren't as versed in the intricacies of h264. removing the bitstream information can only hurt, it has no useful help to the format.

You should suggest GCC devels remove "-s" from the parameters and "strip" from toolchain, because removing debug information can only hurt, it has no useful help to the binary.

Next time you should ask x264 devels to add system information and encoding fps to the user data because they make devels easy to see x264's performance on various CPUs.

LoRd_MuldeR

25th June 2009, 16:04

That comparison is completely invalid. The information that x264 writes to the bistream are negligible for the total filesize. It's less than 0.01%*, even for a very small 10 MB file :p

(*Look at the param2string() function. The user data takes at most 1000 bytes. A bit more, if zones are used)

At the same time debugging symbols can blow an executable file to twice the size, if not more! This even may hurt the performance :eek:

Furthermore debug symbols leak information that developers of Non-OpenSource software try to keep in secret. But x264 is OpenSource, so there is no legitimate reason to hide anything!

Especially information that the devs want to be in the steam. Trying to obfuscate the output of an OpenSource encoder perverts the entire idea! :rolleyes:

Sharktooth

25th June 2009, 16:20

my 2 cents:
dont use psy-rd/psy-trellis at low bitrates... problem solved.

roozhou

25th June 2009, 16:42

Especially information that the devs want to be in the steam. Trying to obfuscate the output of an OpenSource encoder perverts the entire idea! :rolleyes:

My bad to take the off-topic user data stuff into this thread. I think the user has the right to decide whether to write the user data to the bitstream or not, similar to the "-s" option in GCC. I have already added an option "--versioninfo" to my dshow x264 build, and I suggest x264 do the same.

Sometimes you should take the "negligible" size into account. One of my friends uses x264 to encode still images to H264 intra frames. He encodes thousands of images and most of the resulting frames are below 20k. The user data does bring a noticeable overhead.

poisondeathray

25th June 2009, 16:43

dont use psy-rd/psy-trellis at low bitrates... problem solved.

I agree! and I think the default psy-rd strength is much too high for this very reason.

LoRd_MuldeR

25th June 2009, 16:51

roozhou

25th June 2009, 16:57

my 2 cents:
dont use psy-rd/psy-trellis at low bitrates... problem solved.

Sounds reasonable. But there are still two problem:

1) The psy-rd is set to 1.0 by default and x264 won't turn it off automatically at low bitrates.
2) There are millions of x264 users around the world, but only a small portion go to Doom9 or the mailing-list. From "x264 --longhelp" they are not warned about the side effect of psy-rd at low bitrates. And they think subme 9 would bring better quality in the cost of slower encoding speed, but they don't know psy-rd hurts visual quality at low bitrates and subme 9 may make things even worse.

My suggestion:
Unless user manually set psy-rd value, x264 should tweak the psy-rd automagically according to bitrate and resolution, or we call it "auto psy-rd". It should try to make subme 9 always better than subme 6.

poisondeathray

25th June 2009, 16:58

You simply can't expect the default settings to be perfect for any situation. They are just a "reasonable" starting point.

If you think that the default Psy-RDO is too strong for "low" bitrates, then lower it for encoding at these bitrates. Where is the problem ???

Obviously it's impossible to define a default that makes everybody happy for his/her individual preferences.

If the devs lowered the default Psy-RDO strength, it wouldn't take long until somebody complains that the new default is too low ;)

That's a good point - you're not going to find a happy medium, and I'm sure that people who read these boards and frequently use x264 are aware of this.

My counter point is the "defaults" should be the least damaging for the general public who don't have prior knowledge. psy-rd / psy-trellis is very destructive at low bitrates, and this is a common scenarios for things like encoding to flash. I would argue there are many more people that are unaware of settings and intricacies than people who are aware...I have no problem with this myself, personally, it's just the vast majority of people who use the default settings are usually in for a surprise...

Chengbin

25th June 2009, 17:04

So for 500-800Kbps SD 2.35 and 1.77 encodes I should turn off psy-rd and psy trellis?

LoRd_MuldeR

25th June 2009, 17:06

So for 500-800Kbps SD 2.35 and 1.77 encodes I should turn off psy-rd and psy trellis?

As always, there is no general recommendation ;)

You should test various Psy-RDO/Trellis strengths at your traget bitrate at least. Then you can see what you like best...

ChronoCross

25th June 2009, 17:13

Unless user manually set psy-rd value, x264 should tweak the psy-rd automagically according to bitrate and resolution, or we call it "auto psy-rd". It should try to make subme 9 always better than subme 6.

How would this auto adjustment be calculated? Basing this setting off of arbitrary resolutions and bitrates would be absurd as every source is different. There is no good way to determine what psy-rd setting to use so starting off at the current x264 default is always a good balance. The encoder should adjust it to his/her source accordingly.

Chengbin

25th June 2009, 17:16

Would that be considered "low" bitrate though?

roozhou

25th June 2009, 17:35

How would this auto adjustment be calculated? Basing this setting off of arbitrary resolutions and bitrates would be absurd as every source is different. There is no good way to determine what psy-rd setting to use so starting off at the current x264 default is always a good balance. The encoder should adjust it to his/her source accordingly.

Of course it can't be perfect, but better than always leaving it to 1.0.

ChronoCross

25th June 2009, 17:38

Of course it can't be perfect, but better than always leaving it to 1.0.

Evidence?

roozhou

25th June 2009, 17:45

Evidence?

There are plenty of samples showing that psy-rd 1.0 sucks at low bitrates, especially on animes. I have seen many discussions on this topic among fansub makers.

poisondeathray

25th June 2009, 17:51

ChronoCross

25th June 2009, 18:11

psy-rd of 1.0 also sucks on non-anime sources at low bitrate. Anyone who has encoded for low bitrate flash will know this. Edges get ratty, and ringing is a lot worse. It's especially evident on clean edges like titles, or graphics (and anime outlines). psy-rd and psy-trellis essentially add noise, which requires more bitrate. If used in a low bitrate constrained scenario something has to give. I just think that 1.0 is too high for a default strength. I bet the general public doesn't even know what psy-rd is, let alone know they are supposed to lower it for lower bitrate scenarios...

The general public probably isn't using x264 in flash, or even low bitrate for that matter.

Also just so we could clarify what do you consider low bitrate and how do you suggest we determine what setting to use automatically? Do you have any proposals for this auto psy-rd?

roozhou

25th June 2009, 18:19

poisondeathray

25th June 2009, 18:21

The general public probably isn't using x264 in flash, or even low bitrate for that matter.

Also just so we could clarify what do you consider low bitrate and how do you suggest we determine what setting to use automatically? Do you have any proposals for this auto psy-rd?

I just used "flash" as an example of a commonly used low bitrate scenario. Another common low bitrate use is of course anime.

"Low bitrate", of course, is relative. It would depend on the complexity of the content, the fps, and the frame dimensions etc...

I don't have any programming experience so I have no idea how "auto psy-rd" would be implemented. I'm just making the point that psy-rd of 1.0 is too high especially for low bitrate scenarios, and the defaults should be less destructive for the general public (just like psy-trellis was set to 1.0 at one point, and was considered too high)

ChronoCross

25th June 2009, 18:29

Let x be bits per pixel*sec for the encoded video, and psy-rd value be f(x). We can make test to determine the optimal f(x) for different range of x.

how many tests do you plan on doing for how many different sources at how many different bitrates? If your going to try and have something correct stupid user choices your also going to have to test an extensive amount of sources to get any useable values.

Chengbin

25th June 2009, 18:43

Math doesn't work like that. You'll never get psy-rd to turn off because you're either reaching an asymptote or graph is concaving down indefinitely.

roozhou

25th June 2009, 19:15

how many tests do you plan on doing for how many different sources at how many different bitrates? If your going to try and have something correct stupid user choices your also going to have to test an extensive amount of sources to get any useable values.

First we should make it better than constant 1.0. It's not that difficult.

ChronoCross

25th June 2009, 19:18

First we should make it better than constant 1.0. It's not that difficult.

what value do you propose for low bitrate content?

roozhou

25th June 2009, 19:49

what value do you propose for low bitrate content?
Turn it off

ChronoCross

25th June 2009, 19:56

Turn it off

okay so what is low bitrate content?

Chengbin

26th June 2009, 03:38

I did a comparison between a comparison psy+psy trellis and no psy+psy trellis. CRF 20

It seems like psy is like a sharpener. Details seems accentuated.

Dark Shikari

26th June 2009, 03:39

I did a comparison between a comparison psy+psy trellis and no psy+psy trellis. CRF 20

It seems like psy is like a sharpener. Details seems accentuated.You can't compare at the same CRF since both psy RD and psy trellis raise bitrate at the same CRF.

Sharktooth

26th June 2009, 04:21

... as usual, COMPARE AT THE SAME BITRATE ...

Chengbin

26th June 2009, 04:56

... as usual, COMPARE AT THE SAME BITRATE ...

Will do, when I have time.

10L23r

26th June 2009, 07:32

No ! How many will it have to be repeated. The only way to judge the efficiency of a setting is to encode with and without the setting at the same visual quality, and to compare the resulting filesize.

Not when A and B are close from one another, which happens with most switches from x264 (when considered alone). So most of the time, you end up concluding nothing. Attempting to match the visual quality can be a long process, but one with which you can conclude something.

A proper methodology to test the setting X would be :
- create an anchor encoding without X, at a defined crf (close to the one you'll use)
- create several encoding with X, at several crfs, so that you have at least one encoding with X that is visually worse, and one that is visually better than the anchor.
- reduce as much as possible the uncertainty interval by refining the crfs of the worse and better encoding with X until they become almost indistinguishable from the anchor.

Once that is done, you have a bitrate interval with setting X enclosing - quality wise, an encoding without X. you can draw your conclusions. If you really have a lot of time to spend, you can do the same without X and draw a second interval around the anchor.

And, in the end, you are even able to tell "using setting X is x% better than not using it", which allows to compare different settings together.

uhm... so should we test at same bitrate or quality...

edit: srsly, i believe that psy-rd is so subjective that only a test on a large, uneducated (regular ppl who do not understand this stuff) sample would yield any meaningful results.

roozhou

26th June 2009, 11:01

uhm... so should we test at same bitrate or quality...

edit: srsly, i believe that psy-rd is so subjective that only a test on a large, uneducated (regular ppl who do not understand this stuff) sample would yield any meaningful results.

Of course same bitrate. How can you measure same quality?

LoRd_MuldeR

26th June 2009, 13:01

Of course same bitrate. How can you measure same quality?

As explained here:
http://forum.doom9.org/showpost.php?p=1293340&postcount=15

It's more work than comparing videos of the same bitrate though, but probably more useful.
For a "quick" compare it should be okay to compare encodes of the same bitrate...

Manao

26th June 2009, 13:47

Do note that the quotes don't quite apply there. In both cases, I was talking of users not being able to see a visual difference - the bitrate being fixed - with some settings, and which then concluded that the setting was useless.

As far as I can tell, people do see the difference between psy-rd and no psy-rd, even at fixed bitrate, so it shouldn't be a problem to say it's worse or better. Of course, if you need to differentiate psy-rd 0.5:0 and psy-rd 0.6:0, that would be another story...

TiGR

26th June 2009, 14:26

2) There are millions of x264 users around the world, but only a small portion go to Doom9 or the mailing-list. From "x264 --longhelp" they are not warned about the side effect of psy-rd at low bitrates.
Sure, a note in --longhelp similiar to the one about --b-adapt 2 would be a reasonable addition. It would not, however, protect an average user, who uses a GUI, from the defaults. Really, I think that adding low-bitrate profiles and tooltips for psy-rd settings into major GUIs (if they don’t have them already) would just work for the millions of unaware users – and the rest doesn’t need more than the commandline warning. No need of extensive testing or overhauling the x264 defaults.

Let x be bits per pixel*sec for the encoded video, and psy-rd value be f(x). We can make test to determine the optimal f(x) for different range of x.
Not that I have a deep understanding of H.264 or programming in general, but this sounds a little too simplistic. For example when the framerate doesn’t quite reflect the nature of material (anime, bobbed video), wouldn’t it screw up the function? Of course, we can’t magically adjust psy-rd to be perfect in every situation, but would such a simple solution work out when we feed it with the data? I’m not so sure.

Sharktooth

26th June 2009, 15:29

that function has no sense. psy-rd effects may be ok on some kind of sources and bad on some others. x264 doesnt know what is going to encode and a simple function is not going to be the solution. the source compressibility will also make a huge difference for the bitrate threshold (of that function), but again, x264 doesnt know the source compressibility...
the point is users must learn how an encoder works BEFORE using it. the same is true for every other software (despite what micro$oft want you to believe...).
settings are there so you can set the encoder properly for your needs. automatic B$ is always suboptimal.

Manao

26th June 2009, 16:29

You don't need to see it from a bitrate point of view. Just make an option in x264 disabling/reducing psy rd when the quantizer of a particular macroblock is over a threshold. settings are there so you can set the encoder properly for your needs. automatic B$ is always suboptimal. I strongly disagree. An encoder should strive to be as self-adaptive as possible. The only settings you ought to have to set are compliancy settings (cabac, gop, bframes, 8x8dct...), rate control (either bitrate driven or quality driven), encoding speed (with a single switch), and perhaps a switch setting the trade off between details and artifacts.

Not everybody has the time to watch pixel per pixel all the encoding he's doing to see if his settings are "optimal".

Sharktooth

26th June 2009, 16:36

that's true but the "theoretical" POV is always different than the practical POV.
it's the same difference between metrics and human eye.
some sources may benefit more than others from PSY-RD even at high quants... visual comparisons are always needed when you're going to get the "best" results.
a certain experience with a certain encoder is always good... so, for a beginner, it's a matter of trial and error until he gains the necessary experience to get the results he wants...
that's perfectly normal and it will never change.

elguaxo

26th June 2009, 21:11

make an option in x264 disabling/reducing psy rd when the quantizer of a particular macroblock is over a threshold.

I think we have something like that already?

Auto sensing mode. Raise or lower Psy-RD with bitrate.

edit: on a frame by frame basis.
x264 already does that. It raises psy-RD based on lambda ;)

The problem isn't that psy-RD needs to be lowered at very low bitrates--it's just that it's less useful overall, probably.

To what extent? If using CRF 18, could I lower Psy-RD to 0.4 and expect x264 to raise it as needed/necessary.
No, it's implicit in the algorithm. The strength is an extra weighting factor.

Judging by the results here, I would have thought it was safe to assume the Psy-RD needs to be lowered on very low bitrates.How can you say that given that we didn't test anything between 0.0 and 1.0? :rolleyes:

Manao

26th June 2009, 21:45

I think we have something like that already?It does change psy rd strength according to quantizer, but it actually increases it when the quantizer raises...

Actually, it's a bit more complicated than that. Without psy-rd, x264 chooses, for a particular MB, the mode that minimizes SSD + lambda x bits. In that formula, lambda depends on the quantizer (the higher the quantizer, the higher the lambda).

When psy-rd was added, it changed the previous formula which became : SSD + gamma x PSY + lambda x bits. It was then decided that gamma should be indexed on lambda (ie, gamma = alpha x lambda, with alpha constant whatever the quantizer, and linear to the psy strength).

That imho is a mistake. It makes sense that gamma may depend on the quantizer, but there are no reasons whatsoever for it to behave as lambda - unless experimental testing validates that. Since Dark_Shikari numerously said that psy-rd was bad at low bitrate/high quantizer, I think it safe to assume that the experimental testing didn't validate it (for the highest quantizers at least)

Dark Shikari

26th June 2009, 21:47

That imho is a mistake. It makes sense that gamma may depend on the quantizer, but there are no reasons whatsoever for it to behave as lambda - unless experimental testing validates that. Since Dark_Shikari numerously said that psy-rd was bad at low bitrate/high quantizer, I think it safe to assume that the experimental testing didn't validate it (for the highest quantizers at least)This is probably true; the lambda relationship may not hold at the highest quantizers.

Chengbin

27th June 2009, 05:07

I just did my little test on psy vs no psy on low bitrates. The video was The Matrix, and both videos are 480Kbps.

Here is my setting

cabac=1 / ref=6 / deblock=1:0:0 / analyse=0x1:0x111 / me=umh / subme=9 / psy_rd=1.0:0.4 / mixed_ref=1 / me_range=32 / chroma_me=1 / trellis=2 / 8x8dct=0 / cqm=0 / deadzone=21,11 / chroma_qp_offset=-4 / threads=3 / nr=0 / decimate=1 / mbaff=0 / bframes=4 / b_pyramid=1 / b_adapt=2 / b_bias=0 / direct=3 / wpredb=1 / keyint=250 / keyint_min=25 / scenecut=40 / rc=2pass / bitrate=481 / ratetol=1.0 / qcomp=0.80 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / pb_ratio=1.30 / aq=1:1.00

I like the psy encode better. Details are more accentuated. Even though some high motion scenes are not as good as the no psy version, I was looking for it. Overall I like the psy encode better.

elguaxo

27th June 2009, 20:36

It does change psy rd strength according to quantizer, but it actually increases it when the quantizer raises...

Actually, it's a bit more complicated than that...

thanks for the explanation! :)

10L23r

27th June 2009, 21:42