HQ vs Insane preset in megui

[gizzin]

What would you say the quality difference is between the two, vs the extra time used. Thanks.

[wyti]

i would say the best(yeah I know this isn't a doog word here) thing to do is to try them by yourself.

[LoRd_MuldeR]

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

Anything that gives a noteworthy improvement at the cost of a reasonable speed loss wouldn't be called "insane". So you have been warned ;)

[gizzin]

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.

[LoRd_MuldeR]

Because I've tried to look to see if there were any differences between the two, I can't say I found any.

Not surprising at all :D

[roozhou]

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]

"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]

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]

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]

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]

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]

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]

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]

"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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

What is your reasoning for this?

[kemuri-_9]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

[roozhou]

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]

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]

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 ;)

[roozhou]

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]

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]

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