Why is --qcomp 0.6 default for 2passes?

[simps]

*** Look at post #49 at page 3

Well, after a lot of tests with real life video, anime and footage from PC game (Counter Strike), I really don't see any good reason for --qcomp 0.6 to be the default setting when doing 2 pass encode. There is a very unbalanced distribution of bits when --qcomp is at 0.6, producing good looking static and slow motion scenes, and very bad fast moving scenes. This would only be reasonable, when there are non high motion on the clip at all, but this is not real in 99% of cases.

The high motion scenes are bad with --qcomp 0.6, unless you are using some overkill bitrate to make it look good, which is a waste, considering what better settings for 2passes like --qcomp 0.9 can do with much less bitrate.

From my tests, --qcomp 0.9 could be easily a good default for 2passes.

And I am actually using --qcomp 0.94.

Can someone explain why --qcomp 0.6 is default for 2passes, what is the logic behind that? I mean, I want to know when is it better than something like --qcomp 0.9? I believe there are situations where 0.6 would be better than 0.9, but from what I've seen, they are the vast minority. Why make a default setting for the vast minority?

Thanks,
Simps

[Dark Shikari]

Because when you're watching a video, you aren't pausing it and looking at each frame--you're watching a video. And when watching a video, you won't notice artifacts as much in high-motion scenes.

If you're freeze-framing to compare things, qcomp 1 should be optimal.

Also, the original choice of value (inherited, AFAIK, from ffmpeg's original ratecontrol) maximized PSNR on a selection of clips.

[simps]

DS,

Looking at it frame by frame would make --qcomp 0.6 look even worst. I am not even talking about that.

I am talking about watching a movie really.
I have 2 sample encodes of the same movie, 2passes, with same bitrate in both files. In first sample encode, I have --qcomp 0.7, and the other I have --qcomp 0.94. When watching both files, I can easily see how bad the fast motion scene is on the one with --qcomp 0.7, where it looks good on the one with --qcomp 0.94. And the static and slow motion scenes look identical on both files.

Again, given that (I can upload both files if you want but I'm sure you know about this very well), why 0.6 is default?

[JohannesL]

A higher qcomp seems better for very low bitrates.

[Dark Shikari]

Again, given that (I can upload both files if you want but I'm sure you know about this very well), why 0.6 is default?If you would read my entire post before responding, you wouldn't still have this question.

[simps]

A higher qcomp seems better for very low bitrates.

For some reason I believe a higher --qcomp is better for high bitrates too? I don't see any reason for --qcomp 0.6 be default. That is a bad setting, that won't work right with 2passes under low and even mid bitrates. That setting only work if you are using some overkill bitrate, but for high and overkill bitrates, you might just disable everything too and it will still look good, so you can't base a default setting on high and overkill bitrate. I still don't get it.

[LoRd_MuldeR]

For some reason I believe a higher --qcomp is better for high bitrates too? I don't see any reason for --qcomp 0.6 be default.

What new default do you suggest? You would need to test the suggest qcomp value carefully with various sources of different type (HD and SD, cartoon and real-life), at various bitrates (from very high to very low) and in combination with all the options available. Only then you could decide whether your new default is a better choice than the current default or not.

[simps]

If you would read my entire post before responding, you wouldn't still have this question.

I read it, and you were saying that original 0.6 setting maximized PSNR in some clips. And in other thread, you said that the first thing to look for quality and comparisons of this kind, is our eyes. Than, after that come the metrics. Our eyes are subjective, I know that, but you got my point. You are not consistent in your arguments.

--qcomp 0.6 is just not ideal, and anyone can do its own test and proof it. I am trying to be constructive here. Don't get ofended please, I appretiate a lot your work. But 0.6 is a bad default, please consider changing it.

[simps]

What new default do you suggest? You would need to test the suggest qcomp value carefully with various sources of different type (HD and SD, cartoon and real-life), at various bitrates (from very high to very low) and in combination with all the options available. Only then you could decide whether your new default is a better choice than the current default or not.

Totally agree with that. But I can tell you after the small tests I have done, the optimal default would be no where near 0.6. This is not quantum mechanics and I don't need to do millions of tests to see that 0.6 is bad for 2 passes. Now, I agree with you, that to chose the right one, we would need to work deeper, but it wouldn't be 0.6, that I am totally sure of, after my small tests.

[LoRd_MuldeR]

Totally agree with that. But I can tell you after the small tests I have done, the optimal default would be no where near 0.6. This is not quantum mechanics and I don't need to do millions of tests to see that 0.6 is bad for 2 passes. Now, I agree with you, that to chose the right one, we would need to work deeper, but it wouldn't be 0.6, that I am totally sure of, after my small tests.

When using a different type of source, your results may be completely different. Also different people have different preferences.

It's not that easy to decide as you may expect. And you can be sure that the current default was chosen by the x264 developers for a good reason.

So I think it's a bit overhasty to say that 0.6 is bad, unless you did a complete series of tests...

[Chengbin]

qcomp 0.6 is optimal for most cases. A higher qcomp is good for low bitrates. A high qcomp with high bitrates leads to wasted bits.

[simps]

When using a different type of source, your results may be completely different. Also different people have different preferences.

It's not that easy to decide as you may expect. And you can be sure that the current default was chosen by the x264 developers for a good reason...

Ok, I understand your point, but I still hold my position.
I have the time, and I will do A LOT of tests, with different sources, and different values of --qcomp for 2passes, and I will make a comparison thread here in doom9 with the frames and video file results. I will try to make it as good as I can, to aim to find a better default spot. I will do this just for the fun it, if the developers want to ignore it, I am fine with it too, but lets see what will come out of it. Again, just trying to help.

[Dark Shikari]

I read it, and you were saying that original 0.6 setting maximized PSNR in some clips. And in other thread, you said that the first thing to look for quality and comparisons of this kind, is our eyes. Than, after that come the metrics. Our eyes are subjective, I know that, but you got my point. You are not consistent in your arguments.

--qcomp 0.6 is just not ideal, and anyone can do its own test and proof it. I am trying to be constructive here. Don't get ofended please, I appretiate a lot your work. But 0.6 is a bad default, please consider changing it.
What argument? I made no argument: I merely said that was how it was chosen in the past. I didn't say that it was inherently the best choice, merely that is how it was chosen--and it was chosen long before I even started working on the project. :rolleyes:

[simps]

qcomp 0.6 is optimal for most cases. A higher qcomp is good for low bitrates. A high qcomp with high bitrates leads to wasted bits.

I am sorry but there is no way I can agree with that. Can you show proof that a higher --qcomp will waste bits at higher bitrate? I see where you are going, but the argument is week, I can also say that a lower --qcomp will waste bits on the static frames with higher bitrates.

I get the point of stelling some bits from high motion and the hole idea of --qcomp, I just think that the default is bad. I am not saying it should be 1 by default too, but 0.6 is bad.

[Chengbin]

I am sorry but there is no way I can agree with that. Can you show proof that a higher --qcomp will waste bits at higher bitrate? I see where you are going, but the argument is week, I can also say that a lower --qcomp will waste bits on the static frames with higher bitrates.

I get the point of stelling some bits from high motion and the hole idea of --qcomp, I just think that the default is bad. I am not saying it should be 1 by default too, but 0.6 is bad.

When you use high bitrates and high qcomp, with a high motion scene, you can easily surpass the original bitrate. I've done a Blu-ray encoding before at 10mbps with qcomp 1, some peak bitrates are over 70mbps!! Note the maximum bitrate Blu-rays can play is 40mbps, so the original scene is under 40mbps.

[Dark Shikari]

When you use high bitrates and high qcomp, with a high motion scene, you can easily surpass the original bitrate. I've done a Blu-ray encoding before at 10mbps with qcomp 1, some peak bitrates are over 70mbps!! Note the maximum bitrate Blu-rays can play is 40mbps, so the original scene is under 40mbps.This is because x264 has no knowledge of the original stream, so if a section that was QP30 on the original Blu-ray is getting re-encoded, and the average QP of the output stream is QP20, x264 doesn't magically know that it can raise the QP up to 30 for that awful section.

[Chengbin]

This is because x264 has no knowledge of the original stream, so if a section that was QP30 on the original Blu-ray is getting re-encoded, and the average QP of the output stream is QP20, x264 doesn't magically know that it can raise the QP up to 30 for that awful section.

That's exactly what I mean why high qcomp is not optimal for high bitrates.

[simps]

When you use high bitrates and high qcomp, with a high motion scene, you can easily surpass the original bitrate. I've done a Blu-ray encoding before at 10mbps with qcomp 1, some peak bitrates are over 70mbps!! Note the maximum bitrate Blu-rays can play is 40mbps, so the original scene is under 40mbps.

That has nothing to do with "wasting" bits as you stated before. This is a totally new issue, and can easily be solved by setting a limit peak bitrate, just like the old mpeg-2 encoders had for dvd video not superpassing 9800kb/s or so.
You can have your peak limit set, and still work with a higher --qcomp. This is no issue at all. I am no expert on x264, so I am not sure if you can set your peak bitrate at current state. Some dev please help with this.

[Dark Shikari]

That's exactly what I mean why high qcomp is not optimal for high bitrates.This is not what qcomp is for.

[Chengbin]

That has nothing to do with "wasting" bits as you stated before. This is a totally new issue, and can easily be solved by setting a limit peak bitrate, just like the old mpeg-2 encoders had for dvd video not superpassing 9800kb/s or so.
You can have your peak limit set, and still work with a higher --qcomp. This is no issue at all. I am no expert on x264, so I am not sure if you can set your peak bitrate at current state. Some dev please help with this.

There is no point of using high qcomp if you're going to limit it with VBV.

That is what happens when you use high qcomp with high bitrate. I don't see how is that a different issue. When you raise qcomp, you're essentially telling x264 to use a lower Q for fast motions.

If you've encoded a video using CRF, once you use a low enough CRF value, x264 is wasting a lot of bits. There is almost no different between a CRF 2 and a CRF 8 (both ridiculously low CRF values), but bitrate has increased 4x.

[Chengbin]

This is not what qcomp is for.

Could you clarify? I don't understand what you mean.

[simps]

There is no point of using high qcomp if you're going to limit it with VBV.

That is what happens when you use high qcomp with high bitrate. I don't see how is that a different issue. When you raise qcomp, you're essentially telling x264 to use a lower Q for fast motions.

If you've encoded a video using CRF, once you use a low enough CRF value, x264 is wasting a lot of bits. There is almost no different between a CRF 2 and a CRF 8 (both ridiculously low CRF values), but bitrate has increased 4x.

I don't think you got what I wrote, or maybe it is just my bad english. Here is what I ment. If bitrate is high enough, you can still use high --qcomp and limit your peak bitrate if that is a issue. At high bitrates the difference from doing that, and from using low --qcomp is close to zero, since bitrate is too much, it will look good anyway. Difference is small, get it?

Now what about low and mid bitrates? The difference is NOT small. It is huge, meaning a higher --qcomp will produce better results in 2passes.

My point here was why set it to 0.6, when this is only good for the minority of cases? For every sample you can make that 0.6 is better, I can make 10 more where higher value is better. This is the point. 0.6 is not optimal as default.

You don't need to come here and show one or two cases where 0.6 is better, I know they exists, my point is that they are not majority. And the main point, in the most general way of thinking, about low, mid and high bitrates, a higher --qcomp will be better, and that is a good reason to have another default value.

[Dark Shikari]

Could you clarify? I don't understand what you mean.The purpose of qcomp is not to handle areas of higher quantizer in the original video.

x264 has no code designed to handle flaws in the input stream.

[simps]

double post

[Chengbin]

The purpose of qcomp is not to handle areas of higher quantizer in the original video.

x264 has no code designed to handle flaws in the input stream.

Sorry, that was a poor choice of words.

What I mean is, because x264 can use too high of a bitrate with higher qcomp, that leads lower compression efficiency because of wasted bits. That's why high qcomp is not so smart for high bitrates.

I'll say it again, the x264 developers chose 0.6 as default for a reason. It is the optimal value for most cases. IMO it is a good idea to raise qcomp with low bitrate encodes, I do that.

[shon3i]

I think I understand simps. with lover values qcomp, encoder make reserves, but if we encode for example video for Blu-Ray, and some frame need for example 70mbps, bluray restriction allow only 40mbps that is restriction by VBV, and qcomp 0.6 steal bits, and frame come out with 20mbps, instead with around 40mbps

[Dark Shikari]

I think I understand simps. with lover values qcomp, encoder make reserves, but if we encode for example video for Blu-Ray, and some frame need for example 70mbps, bluray restriction allow only 40mbps that is restriction by VBV, and qcomp 0.6 steal bits, and frame come out with 20mbps, instead with around 40mbpsqcomp is applied before, not after, VBV.

[simps]

Sorry, that was a poor choice of words.

What I mean is, because x264 can use too high of a bitrate with higher qcomp, that leads lower compression efficiency because of wasted bits. That's why high qcomp is not so smart for high bitrates.

I'll say it again, the x264 developers chose 0.6 as default for a reason. It is the optimal value for most cases. IMO it is a good idea to raise qcomp with low bitrate encodes, I do that.

What is the reason? I am still not convinced a higher --qcomp is not optimal for high bitrates too, and even if it isn't, what about low and mid bitrates? Are you going to choose default only because of high bitrates, and forget about low and mid? And still, for higher bitrates, you just limit your peak if that is an issue, and you are good, and if this is still a problem and hurt compression, I am sure the problem is VERY SMALL, compared to the VERY BAD high motion scenes in mid bitrate and especially in low bitrates caused by --qcomp 0.6 value.

I am not convinced of your argument, and even it you can proof that at higher bitrate 0.6 is better, do you think this is enough to set 0.6 as default? You just completly ignore the problem of mid and low bitrates? Your logic is not good. I don't see how you are relating the fact that you think --qcomp 0.6 is better for higher birates, with the fact 0.6 is not a good default value? (And this is the point of the thread)

In other words, you are pointing an argument weak enough, that to actually see the difference between frame quality with high and low --qcomp at high bitrate, you would need to look into it VERY carefuly, frame by frame. This mean small difference for one side or other. I couldn't care less about this small problem.

I am showing you a HUGE problem, with mid and specially low bitrates, where you can see the degraded frame quality from 5 meters away from the screen, in high motion scenes, where movie is playing.

I am sorry, but your argument has nothing to do with my point on 0.6 not beeing a good default.

[Dark Shikari]

Have you done any testing without AQ enabled? Do the results hold with AQ off as well?

[shon3i]

qcomp is applied before, not after, VBV.

Anyway, resulting frame will be 40mbps not 20mbps, while other frames which use extra bits for qcomp, will not get their food. Realy need more testing for BD encodings where bitrate is extremly high.

[simps]

Have you done any testing without AQ enabled? Do the results hold with AQ off as well?

I haven't. I will do. This week I will take some time, and do several tests, different sources, bitrates, all range of --qcomp, and will include AQ on and off too. Will do the best I can, and post a thread with frames comparison and video file. I think this way is better and more constructive than the discussion here. Hope it will help. If you have any hint / tip for me, please say it and I will include on comparison.

[Chengbin]

@simps

For mid bitrate, qcomp 0.6 will look just fine. Higher qcomp is good if you pause and watch the frames.

We have to define mid bitrate though. IMO mid bitrate for SD video is around 1000kbps.

For very low bitrates, high qcomp is good, sometimes very good. The advantage quickly deminishes as you raise the bitrate, and once you use high bitrates, it negatively affect compression efficiency because by then you can't really tell the difference between 0.6 and 1.

[foxyshadis]

x264 defaults are designed to be fairly sane for almost anything you could possibly throw at it. They're not meant to be optimal in all circumstances, you might as well ask why default is me hex, or no b-frames, etc. They're just a starting point.

The way I've always defined it: Low bitrate is avg q >25. Mid bitrate is avg q 21-25. High bitrate is avg q <21. (For some people, it's <18.)

[CruNcher]

very nice explained and thats why you can also change them and they aren't hardcoded :D so you have choice if you don't like something you can change it for sure qcomp could be adapted to the bitrate the same as i belive deadzones could be adapted and do nice things but you first have to find out how todo that in a balanced way and pleasing everyone, though adapting qcomp seems even easier then deadzones as deadzones can have a high visual impact on the look and feel of the source if done wrong (you can literally paint with it) :D

[simps]

x264 defaults are designed to be fairly sane for almost anything you could possibly throw at it. They're not meant to be optimal in all circumstances, you might as well ask why default is me hex, or no b-frames, etc. They're just a starting point.

The way I've always defined it: Low bitrate is avg q >25. Mid bitrate is avg q 21-25. High bitrate is avg q <21. (For some people, it's <18.)

I agree with that, it is a good point. But still, there is another way of looking at this. A higher --qcomp won't decrease encode speed at all, and will provide better looking results FOR SURE in the majority of cases, especially in mid and low bitrates. The settings you post, has some kinda of speed / quality trade off, and --qcomp will not jeopardize speed. Therefore is much more reasonable to think about those other features not beeing default. bframes is a tricky business, so I can understand that too.

And remeber I am talking about 2passes from the begining. I know --qcomp has more to it than this I am going to say, but still, a higher --qcomp will take more advantage of 2passes, in the sense that we were used to deal with multiple passes, like in mpeg-2 encoders for example, adressing bits where needed mroe, to give a more uniform quality. Another way of thinking about it, is that the lower --qcomp, the more like CBR things will be. It is not exactly it, because --qcomp has more to it than that, but still, you got the point.

I do agree the psy-visual idea of decreasing high motion a bit to increase the rest, is indeed a good idea. I am not defending --qcomp 1 as default here, never said so. The point is, this is only a good idea, once you decrease the high motion only by so much, that you can't really notice. A 0.6 --qcomp is decresing TOO MUCH the high motion. Don't get me wrong, I wanna take advantage of the psyco-visual into this too, but 0.6 is too agressive for that (another way of thinking).

Using your words, a "sane" value, would NOT be 0.6 for sure. You can't call "sane" a value that will jeopardize so much mid and low bitrates at high motions, and compromise the whole point of 2passes a bit, by taking away some of its freedom (again, not exactly this, but you got the point).

In the end, what I am saying, is that the whole idea behind --qcomp IS INDEED GOOD, it is just TOO AGRESSIVE using 0.6 for most of the part.

Don't you think it is reasonable what I am saying? And I came to this, after lots of tests, I am not especulating.

Here, another way of looking at this (2pass encode):

Higher --qcomp
low bitrate = MUCH BETTER
mid bitrate = BETTER
high bitrate = EQUAL (IF IT IS WORST, THE DIFFERENCE IS SO SMALL, IT Is IRRELEVANT)

Lower --qcomp
low bitrate = MUCH WORST
mid bitrate = WORST
high bitrate = EQUAL (IF IT IS WORST, THE DIFFERENCE IS SO SMALL, IT Is IRRELEVANT)

Now you can ask the question, why is 0.6 default than? It is NOT the most "sane" value at all.
And keep in mind, there is no speed / quality trade off here. --qcomp won't slow down encode.

If you wanna say this table depends whatever the source is (I can say everything depend on the source, but still), I can tell you yes, it will depend pretty much if the footage HAS or NOT high motion scenes. And really, footage without any high motion scenes are like what? 1% of total? For every example of a footage without high motion scene, we can come up with another 100 where there are high motion.

This is why I don't see the point on 0.6 as default. It is not the overall reasonable parameter, and I am sure a lot of people is using lower --qcomp because it is default, and than raising the bitrate to some overkill level, to compensate for the bad high motion scenes.

[simps]

Look at another reason why having a bad default value will lead to bad results. If you try staxrip or meGUI, and if you go for a 2pass encode, THEY WON'T adjust --qcomp correctly and automatic for you, considering the bitrate of choice.

This pretty much means end-users are encoding with meGUI and Staxrip, and having bad results at high motion scenes when using low and mid bitrate, and they are RAISING the bitrate solve the problem.

x264 is better than that, and can output decent without overkill bitrate, ONCE the parameters are right, and --qcomp is just WAY OFF. And if you want to go with overkill bitrates, than it will look even better with the right --qcomp. There is just no reason to leave this at 0.6.

Just is just another way to show that --qcomp 0.6 is not "sane" for default.

[simps]

--qcomp 0.7
http://img37.imageshack.us/img37/8620/85374highmotionx264.png

--qcomp 0.84
http://img37.imageshack.us/img37/7017/85374.png

--qcomp 0.7
http://img39.imageshack.us/img39/5950/151137highmotionx264.png

--qcomp 0.84
http://img188.imageshack.us/img188/2077/151137.png

I don't even have a --qcomp 0.6 because it is even worst than --qcomp 0.7 here, so you can imagine it.

I am doing this at low bitrate (--bitrate 240) and 640x352 resolution because it is easier to spot differences. And as far as you go up to --qcomp 0.85, you can't see the rest of the movie (static and slow motion scenes) jeopardized during playback. You only see the high motion scenes looking better. This is good. At up to --qcomp 0.78, you can't even tell frame by frame the difference at statis and slow scenes, even at --bitrate 240 for 640x352.

At --qcomp 0.85 or higher, at this low --bitrate 240 @ 640x352, you do see some degradetion on the static and slow scenes, but of course, the high motion look even better. So at least for default, so far I would say anything higher than --qcomp 0.85 at least, is also not a good idea.

Probably --qcomp 0.75-0.8 would be solid and good candidates for default. I will do the full range test on this, and post results.

I will also test at mid and high bitrates, but you can see from this, that they aren't really necessary, but I will do it anyway, or people will call it incomplete. This is one of those settings, that once you are balanced with a "sane" --qcomp, throwing more bits will scale pretty much equally all the static, slow and high motion scenes. In others words, results will be pretty much the same. If it is tunned for low bitrates, it has a VERY LARGE chance of been tunned for mid and high bitrates too. The only reason I am using low bitrates to do it, is because it is easier to see the differences. And if bitrate peak is an issue, than just use --vbv-maxrate, and you are good. Anyway, --vbv-maxrate arround 4-5x the avg bitrate, is always a good idea to use. It is enough to let VBR work properly, and won't give you crazy spikes.

[juGGaKNot]

Someone close it, change it to 1 if you like it ( as i do ).

[nm]

Someone close it
The thread? Why? I think this is an interesting discussion and I'm looking forward to a conclusive test.

[buzzqw]

... i suppose he mean "choose" not close... maybe a lapsus :D

BHH

[Sharktooth]

comparing still frames... pfff....
did you READ what D_S said?

[Manao]

simps : you have posted only the pictures that will benefit from a higher qcomp. Post the low motion ones too, because the only conclusion from your screenshots is "when i raise the bitrate, the quality is better".

Furthermore : high bitrate = EQUAL (IF IT IS WORST, THE DIFFERENCE IS SO SMALL, IT Is IRRELEVANT)No. Indeed, when you can't see a quality difference, you can't see it (thus the notion of saturation). That doesn't mean you couldn't have targetted a lower bitrate for the same quality.

[LeonLanford]

well I've done tests by fast moving anime and slow moving anime, indeed qcomp 1 is better for fast moving anime.

why it's better because in qcomp 1, the encoder use higher bitrate. you can even see the size different by the images given by simps above, 254kb and 260kb, the second example even with 253kb and 269kb. i also see the result in avidemux bitrate while encoding and it's indeed increasing more bitrate with qcomp 1 therefore the size also increased too. i've tried it with aq on and off.

and as long as i remember avidemux(don't know if it's x264 default setting or not) use qcomp 1 as default in the past, i just realized that after i checked my encoded anime in the past using mediainfo

just my personal opinion :p
sorry if my english weird

[Manao]

why it's better because in qcomp 1, the encoder use higher bitrateAnother great tautology. You can't compare quality if the overall bitrate is different.

[LoRd_MuldeR]

and as long as i remember avidemux(don't know if it's x264 default setting or not) use qcomp 1 as default in the past, i just realized that after i checked my encoded anime in the past using mediainfo

No it doesn't. And if it did at some time in the past, then this was a bug that is fixed now.

[kemuri-_9]

No it doesn't. And if it did at some time in the past, then this was a bug that is fixed now.

iirc, long ago there were some parameters that automatically caused qcomp to be set to 1 when they were set a certain way.
I wanna say that it was an old old version of AQ, but not 100% on that....

[LoRd_MuldeR]

iirc, long ago there were some parameters that automatically caused qcomp to be set to 1 when they were set a certain way.
I wanna say that it was an old old version of AQ, but not 100% on that....

Anyway, Avidemux' default settings should equal x264's default settings at any time. If they differ then this is a bug and it should be fixed.

[simps]

Manao,

You are right. I just posted the frames in high motion, where a higher --qcomp is better. I really will post frames of static and low motion scenes too, where a lower --qcomp is better.
I will do more than that, I will post the .264 video files too, so you guys can see the differences during playback, and I will also use different sources to test.
But it will take some time to do, but I will do it.

What I can say by now, is that with --qcomp arround 0.75-0.8, you don´t notice any degradetion on the static and low motion scenes, against --qcomp 0.6, but the improvement in high motion scenes is visible. With --qcomp larger than 0.8, you start to see degradetion on static and low motion compared to --qcomp 0.6.

I will prove all of this, but it will take some time to encode everything. But I will do it.

Please, don't get me wrong, I never defended --qcomp 1. I like the idea behind --qcomp, I just think it is too agressive with 0.6 as default. If we take away some bits from the static and low motion scenes, and transport them to the high motion scenes, overall result will be better, under pretty much any bitrate. (the way it is now with --qcomp 0.6, high motion SUX at low bitrates, and could be much better at mid bitrates) I just think we can fine tune --qcomp better, since 0.6 produces unbalanced results under low and mid bitrates. Something like 0.75 will end up to be ideal, but let me run the tests first.

[simps]

** This is comparision bewteen qcomp 0.7 and 0.89, this is not even the 0.6 default. KEEP THIS IN MIND, 0.6 is even worst than 0.7.

*** I upload the two .264 files. I sent the link via PM (will not post the link here on the thread, due to forum rules) to Dark Shikari, Manao, LoRd_MuldeR and Sharktooth so they can see not only frame by frame, but the differences during playback. They can check both files were encoded with exactly the same settings, only changing --qcomp parameter. Also, no zones, no pieces of files. I uploaded the full movie. PM if you want the link too. I don't trust encoding only pieces of movies to do this comparisons. Bit distribution will change during that pieces of movies, when you encode the full movie. So this is the best way to do it.

My conlusion is --qcomp 0.89 is MUCH more balanced and reasonable than even --qcom 0.7, so you can imagine how the default --qcomp 0.6 would look like. The difference on static and low motion scenes are close to zero, and in LOT of cases (maybe more than 50%), --qcomp 0.89 even win on low motion. But the difference in high motion scenes is HUGE. --qcomp 0.89 win BIG TIME.

I ask for the people who have the .264 files, to come here and post their impressions so we can discuss it more.

After lots of tests, I come more and more to this conclusion here, where puts --qcomp arround 0.8 to be a good sane candidate for real best default:

http://img34.imageshack.us/img34/9053/graphf.jpg

Here are the bitrate peak / distribution using --qcomp 0.7 and --qcomp 0.89:

ps: See how the distribution of a higher qcomp is also much more reasonable for 2 passes. It takes much more advantage of it. Imagine how much --qcomp 0.6 (default) would look like, to much close to CBR, not taking full advantage of 2 passes. This is another reason why doing 2passes encode, with lower --qcomp is not a good idea.
http://img34.imageshack.us/img34/1229/bitrateh.png

--qcomp 0.7
http://img34.imageshack.us/img34/3408/vbv3.jpg

--qcomp 0.89
http://img194.imageshack.us/img194/8930/vbv2.jpg



Some comparisons between --qcomp 0.7 and --qcomp 0.89



Static scene 1: - They are pretty much the same
--qcomp 0.70
http://img132.imageshack.us/img132/5188/7368staticx264qcomp070.png
--qcomp 0.89
http://img196.imageshack.us/img196/2812/7368staticx264qcomp089.png



Static scene 2: - They are pretty much the same
--qcomp 0.70
http://img41.imageshack.us/img41/60/84970staticx264qcomp070.png
--qcomp 0.89
http://img37.imageshack.us/img37/9859/84970staticx264qcomp089.png



Low motion scene 1: - They are pretty much the same
--qcomp 0.70
http://img199.imageshack.us/img199/3629/51615lowmotionx264qcomp.png
--qcomp 0.89
http://img34.imageshack.us/img34/3629/51615lowmotionx264qcomp.png



Low motion scene 2: - They are pretty much the same, but qcomp 0.7 is a bit better here
--qcomp 0.70
http://img29.imageshack.us/img29/1301/60666lowmotionx264qcomp.png
--qcomp 0.89
http://img32.imageshack.us/img32/1301/60666lowmotionx264qcomp.png



Low motion scene 3: - They are pretty much the same, but qcomp 0.89 is better, just look at the arm of the guy in brown jacket
--qcomp 0.70
http://img196.imageshack.us/img196/4690/87414lowmotionx264qcomp.png
--qcomp 0.89
http://img199.imageshack.us/img199/4690/87414lowmotionx264qcomp.png



High motion scene 1: - qcomp 0.89 win big time
--qcomp 0.70
http://img34.imageshack.us/img34/5097/1490400000.png
--qcomp 0.89
http://img20.imageshack.us/img20/1452/149040qcomp089.png



High motion scene 2: - qcomp 0.89 win big time
--qcomp 0.70
http://img34.imageshack.us/img34/7040/89771highmotionx264qcom.png
--qcomp 0.89
http://img29.imageshack.us/img29/7040/89771highmotionx264qcom.png



High motion scene 3: - qcomp 0.89 win big time
--qcomp 0.70
http://img32.imageshack.us/img32/6966/151035highmotionx264qco.png
--qcomp 0.89
http://img29.imageshack.us/img29/6966/151035highmotionx264qco.png



More frame comparison of High Motion on post #59


Thanks,
Simps

[Chengbin]

simps, I don't think you get it.

Raising qcomp above 0.6 with very low bitrate encode is a GREAT way to have better looking encodes. But as you raise the bitrate to "mid" to "high" bitrate, qcomp 0.6 is better.

Do some tests with mid to high bitrates, you'll see what I mean. There is very little difference frame by frame for mid bitrate encodes. For high bitrate, the difference is inperceptable.

If you dig some old threads up, you'll find that I raised THE EXACT SAME QUESTION of why 0.6 is the default. Then after many tests, I understood why 0.6 is the default.

I still use qcomp 0.8 for my encodes because they're low bitrate encodings for my Archos 5.

[simps]

simps, I don't think you get it.

Raising qcomp above 0.6 with very low bitrate encode is a GREAT way to have better looking encodes. But as you raise the bitrate to "mid" to "high" bitrate, qcomp 0.6 is better.

Do some tests with mid to high bitrates, you'll see what I mean.

If you dig some old threads up, you'll find that I raised THE EXACT SAME QUESTION of why 0.6 is the default. Then after many tests, I understood why 0.6 is the default.

I still use qcomp 0.8 for my encodes because they're low bitrate encodings for my Archos 5.


You are very wrong, at mid bitrate a higher --qcomp than 0.6 is also MUCH better. For the vast majory of cases, a higher than 0.6 will be much better. Just wait, and I will show proof for this too. And at high bitrates, its pretty much the same, you just have to look for some --vbv-maxrate, and that is it.

There is nothing magical about the low bitrate I am using. I am using it, because it is easier to spot differences. At higher bitrates everything will look much more equal.

And don't forget I am using --qcomp 0.7 here. 0.6 looks much worst than this.

Just wait for my final tests.

[Chengbin]

qcomp 0.6 is enough for mid and high bitrate encoding because x264 has enough bitrates for the high motion scenes. Therefore raising qcomp will not make much difference.

But in low bitrate, x264 does not have enough bitrate for that. Raising qcomp "fixes" that problem. That's why you (and I) see vast improvements for low bitrate encoding.

[Audionut]

Those bitrate peaks from neuron2's tools are wrong. He once mentioned that on the forums.

iirc, it only grabs the peak every few frames or so.

Try this instead.
http://www.winhoros.de/docs/bitrate-viewer/index.html

[simps]

qcomp 0.6 is enough for mid and high bitrate encoding because x264 has enough bitrates for the high motion scenes. Therefore raising qcomp will not make much difference.

But in low bitrate, x264 does not have enough bitrate for that. Raising qcomp "fixes" that problem. That's why you (and I) see vast improvements for low bitrate encoding.

Looks, I am just trying to help. I am up to discuss valid arguments, but this one is not. Basicaly what you are saying, is that given high enough bitrate, it will look good. Of course it will, even with bad settings, once you give enough bitrate, the difference will be either zero or small. This is not the point. The point is, a bit higher qcomp will produce much more balanced results, and therefore should be the "right" default.

And I will say this again, at mid bitrates, the difference is still there and visible, and a higher --qcomp IS better. I will show this too, it is just that takes some time to encode everything.

[Guest]

Those bitrate peaks from neuron2's tools are wrong. He once mentioned that on the forums.
They're not wrong. You just have to know what they are reporting.

[simps]

Those bitrate peaks from neuron2's tools are wrong. He once mentioned that on the forums.

iirc, it only grabs the peak every few frames or so.

Try this instead.
http://www.winhoros.de/docs/bitrate-viewer/index.html

Didn't know that. Please tell me how to properly get the peak bit rates from my .264 files?

[LeonLanford]

Another great tautology. You can't compare quality if the overall bitrate is different.

that's why you can't compare it, the bitrate and filesize itself already different(with only changing the qcomp setting), increasing qcomp=increasing bitrate=increasing size=increasing quality. try it yourself..

No it doesn't. And if it did at some time in the past, then this was a bug that is fixed now.

yes i said it 'was'..

[Guest]

Didn't know that. Please tell me how to properly get the peak bit rates from my .264 files? How do you define the "peak bit rate"?

[simps]

High motion scene 4: - qcomp 0.89 win big time
--qcomp 0.70
http://img132.imageshack.us/img132/1558/85295lowmotionx264qcomp.png
--qcomp 0.89
http://img29.imageshack.us/img29/873/85295highmotionx264qcom.png

[simps]

How do you define the "peak bit rate"?

I think it would depend on some small interval right? Like the "average" bitrate during that small interval...

Can I consider for that matter, what DGAVCindex say?

[simps]

Sharktooth inbox is full, can't sent you links for .264 files.
If you want, please free some space and PM me.

Thanks.

[simps]

Those bitrate peaks from neuron2's tools are wrong. He once mentioned that on the forums.

iirc, it only grabs the peak every few frames or so.

Try this instead.
http://www.winhoros.de/docs/bitrate-viewer/index.html

Thanks, I just added it to post #49. And you can see from graph that the distribution of qcomp 0.89 is more more reasonable too, taking more advantage of 2passes encode.

http://img34.imageshack.us/img34/1229/bitrateh.png

[Audionut]

Thanks, I just added it to post #49.

Left click on the little bitrate viewer icon at the very top left and select Auto scale mode. Or press Ctrl-A.

edit: and you should really use png compression for those screen grabs.

[Audionut]

See how the max bitrate on your qcomp 0.89 encode is much higher than the qcomp 0.7 encode while they both still have the same average bitrate.

Where do you think that extra bitrate is coming from?

And imo you should only be comparing to qcomp 0.6 (default).

[simps]

Left click on the little bitrate viewer icon at the very top left and select Auto scale mode. Or press Ctrl-A.

edit: and you should really use png compression for those screen grabs.

Thanks. Done, look much better now.

[Audionut]

Thanks. Done, look much better now.

Thankyou. Much easier on the eyes.

[simps]

See how the max bitrate on your qcomp 0.89 encode is much higher than the qcomp 0.7 encode while they both still have the same average bitrate.

Where do you think that extra bitrate is coming from?

And imo you should only be comparing to qcomp 0.6 (default).

What? That higher peak bitrate from --qcomp 0.89 came from moving bits from static scenes to those high motion scenes. This is exactly what it is supposed to do, and the whole point of the thread, trying to make high motion scenes look a bit better, without decading too much static and low motion scenes, and therefore making overall picture better.

Both files are the exactly same size 197.41MiB (the average bitrate is the same), this is the goal of 2passes.
The bitrate distribution of a higher --qcomp is much more sane, and takes more advantage of 2passes encodes. That is what the graph is showing.

--qcomp 0.6 is even worst than 0.7, and the bitrate distribution will look more and more closer to CBR too.

If you don't trust me, just test it yourself.

[Audionut]

They're not wrong. You just have to know what they are reporting.

Sorry Don. "Wrong" was a crappy choice of word.

[Audionut]

Well, imo your high motion scene doesn't look very high motion from your screen shot.

And regardless of how better or worse 0.6 is to 0.7, you should still be basing your comparisons from 0.6 because it is the default.

And, imo, in a flowing display of frames, where low motion, static scenes will more often than not be much greater than high motion scenes, I prefer more quality to those 95% of frames than trying to increase quality to 5% of frames at the sacrifice of the other 95%.

Personally, I think your comparison is beyond flawed. Yes, low bitrate might show "your" example much better, but, imo, your high motion 0.84 s/s are still crap quality.

And yes, I am intrigued now, if for no other reason than to prove you wrong. So I will be conducting my own tests.

[simps]

That pool scene is pretty high motion, water moving really really fast. It was all this movie had in it.

The point is, the amount you are decading static and low motion scenes is irrelevant. You can't tell the difference even at this low 240kb/s (imagine at higher birates), just look at the screenshots. But on the other hand, the high motion look MUCH better with a higher --qcomp. I am talking about 0.8 - 0.89 here, maybe 0.8 would be a very good default. I am not defending --qcomp 1, so I DO WANT TO JEOPARDIZE HIGH MOTION too, but not as much as 0.6, as it is too bad and too agressive.

Quality is just like this because I am at --bitrate 240. Try to encode some movie at 640x352 with --bitrate 240, and you will see the same.

Also, you can see the .264 files yourself, during playback, and see which one you liked better. I just PM'ed you with the link.

Also, do your own test, and please post results here like I did, with screenshots, and solid comparison, this will just add to the thread.

Also, I am pretty much finished with mid bitrates, and the results is pretty much the same, only high bitrate left to test :)

Thanks,
Simps

[Audionut]

Quality is just like this because I am at --bitrate 240. Try to encode some movie at 640x352 with --bitrate 240, and you will see the same.

So I will reinforce a statement posed to you earlier.

x264 settings are as they are, because they are designed to do the best job they can on every source.

With all due respect. The amount of encodes at 640x352 with a bitrate of 240 are statistically 0.

I am more than sure that people could also do other encodes that show weakness in x264's default settings.

The point is, for the majority of encodes (think 99.9%) x264's default settings work. And this is what matters.

To change the devs mind and have them change the defaults you would need to show your results with more than 1 source.

Think, high motion, low motion, static, grainy, flat, anime, c/g, low brightness, high brightness, high-low-mid-ver low-very-high bitrates, and probably heaps more examples than I have shown.

So, the point being, if you are finding your results to be better than default, then use your settings. If you can prove your results are better on virtually every example, than let the devs know.

Else, stop arguing.

[simps]

You don't really read this thread do you?
I said here before I will do the full comparison, with different sources, all bitrate ranges, etc. So why are you saying this? You should read the thread with more attention.

The only reason I started with low bitrate, is because it is easier to find the differences this way. This is a fine tune we are talking about, and at higher bitrates, since the bitrate is already a lot, the difference are smaller, and harder to see.

I am open to sugestions for the comparions, once they make sense. Your post just doesn't make sense. Read the entire thread please.

And you know what? I have already shown some samples, where my point is valid. I showed it with comparisons, frames, files, analysis.

If you want to counter-argue this, than do it like I did. Do your encodes, your comparison, and post, other way, you are just losing your time.

[Daiz]

Well, from what I've experimented with CRF and qcomp, I've found qcomp 0.7 to be more visually pleasing than either 0.6 or 0.8. For a particular CRF DVD encode, the bitrate was around 1.6 Mbps and the source was anime. I don't have the all the test encodes from this case anymore though so I can't post any screenshots, but just saying. I've used 0.7 in for pretty much everything for a while already though, since it seems to give the best balance for the sources and target bitrate I have.

[Sagittaire]

In my memory best OPSNR result is for qcomp = 0.75.
Aku raise this value at 0.6 because Aku find that HVS threadoff is better at this value.

[Audionut]

High Motion

source

http://www.users.on.net/~audionut11/source1.PNG


qcomp=default

http://www.users.on.net/~audionut11/high0.6.png

qcomp=0.89

http://www.users.on.net/~audionut11/high0.89.png


Static

source

http://www.users.on.net/~audionut11/source2.PNG

qcomp=default

http://www.users.on.net/~audionut11/static0.6.png

qcomp=0.89

http://www.users.on.net/~audionut11/static0.89.png

Sample

qcomp=default

http://www.users.on.net/~audionut11/0.6.mkv

qcomp=0.89

http://www.users.on.net/~audionut11/0.89.mkv


My opinion,

In the high motion scene both options can't provide enough bits.
In the static scene, qcomp=default pawns.

edit: stats


qcomp=default
---[NoImage] x264 [info]: SSIM Mean Y:0.9324036
---[NoImage] x264 [info]: PSNR Mean Y:36.830 U:41.786 V:43.371 Avg:38.018 Global:36.438 kb/s:999.41

qcomp=0.89
---[NoImage] x264 [info]: SSIM Mean Y:0.9305640
---[NoImage] x264 [info]: PSNR Mean Y:36.333 U:41.403 V:42.980 Avg:37.535 Global:36.515 kb/s:998.98


Bye!

[Chengbin]

The only reason I started with low bitrate, is because it is easier to find the differences this way. This is a fine tune we are talking about, and at higher bitrates, since the bitrate is already a lot, the difference are smaller, and harder to see.

No, low bitrate is the only place where high qcomp will help. Mid to high bitrate will not have a difference, and it will hurt the static images.

I was gonna show you, but Audionut was kind enough to do it before me, so here you go.

[simps]

No, low bitrate is the only place where high qcomp will help. Mid to high bitrate will not have a difference, and it will hurt the static images.

I was gonna show you, but Audionut was kind enough to do it before me, so here you go.

No. At mid bitrate a higher --qcomp than 0.6 is better too. The problem to find this higher value, and I wasn't saying 0.89 was likely to be default (exepct on first post, but that was befor most tests). So far its probably more like 0.75 - 0.8 to be good.

Just keep Audionut's sample in mind, and compare than with the samples I will post here, and you will see.

[simps]

Audionut,

From your sample, you so far can say 0.89 wouldn't be a better solution for your bitrate and res. You can't say anything about how a 0.7 or 0.8 --qcomp would do against default, and this topic is about a higher --qcomp beeing better than default, so you should try 0.7 and 0.8 and post back results, or we can't conclude anything for your results.

Also post more high motion frames, and more low and static too.

[Trahald]

Using your words, a "sane" value, would NOT be 0.6 for sure. You can't call "sane" a value that will jeopardize so much mid and low bitrates at high motions, and compromise the whole point of 2passes a bit, by taking away some of its freedom (again, not exactly this, but you got the point).

Perhaps because of language, but you must not under stand the word sane. you are saying 'sane' but using it like 'best' or even good and its definitely not that. sane, in this context, i would define as not horrifically slow and/or ugly. The audionuts screen shot of rambo close up looks better to me at default. more detail. but thats just mho. the difference in any of the screen shots in this thread definitely does not take you from sane to insane.

The answer to your original question was its a left over setting from ffmpeg and perhaps picked by psnr. Dark Shikari is probably the closest to the answer you will get to an answer and he joined the project after the decision.

imho .6 is sane (considering how long its been default on a very popular encoder) setting. I btw do not change that setting in my command line and I am very happy with the results of my encodes.

Once a thread becomes 1 or 2 people beating a dead horse I generally tend to close them, Im not sure we are there yet although we are close.

[Audionut]

You can't say anything about how a 0.7 or 0.8 --qcomp would do against default,

No, cause i'm not interested. I was showing you how your qcomp 0.89=win was garbage.

and this topic is about a higher --qcomp beeing better than default,

Well it wasn't. But if you want to change it now that's your prerogative.

so you should try 0.7 and 0.8 and post back results, or we can't conclude anything for your results.

Yes we can, qcomp 0.89 is crap.

[Audionut]

Once a thread becomes 1 or 2 people beating a dead horse I generally tend to close them, Im not sure we are there yet although we are close.

Imo, there has been more than enough explanations by more than enough people answering the op's original questions.

Can someone explain why --qcomp 0.6 is default for 2passes, what is the logic behind that?

Vote 1 for thread closure.

[simps]

I am sorry I am logicaly minded.
When I post a scenario where a higher qcomp up to 0.89 is a overall WIN vs lower qcomps, it is obvious too assume, that any lower value than 0.89 would also win vs even lower values.

In other words, If 0.89 is better overall than 0.7, it is obvious that it would also be better than 0.6, or even 0.8 would be better than 0.6 too, and 0.75 would also be better, so you got the point.

You are showing a scenario where a 0.89 qcomp is not better than a 0.6 qcomp. In this case, YOU CAN'T SAY ANYTHING ABOUT HOW A 0.7 OR 0.75 QCOMP WOULD DO AGAINST 0.6. Or even how a 0.65 qcomp would do. All those values are higher than default.

That is why I told you you need to try those outs too.
This is what I would expect from a logicaly minded person.

And the porpous of the thread is not "0.89 is the best", is to find a higher and better overall qcomp value.

And just to let you know, I have Rambo IV HD too, and will use it, same scenes, res, bitrate you did, to show how a 0.7 against 0.6 would do, or 0.8 vs 0.6, and so on.
you can post it yourself too, but obvious after this, I won't trust any post from you anymore.

Cheers,
Simps

[simps]

Also about closing the thread, not a good idea. There are some interesting info here and discussion too. Some times people like you come arround to trash talk the thread. This happens all the time, unfortunatly. For me, its a piece of cake to get pass this, don't close anything. Not sure for you though.

[Sagekilla]

There really is no new concepts in this thread at all though. qcomp controls how bit distribution occurs between scenes.

For bitrate (Non-CRF or QP) low values of qcomp cause it to allocate bits in a CBR-like manner where each frame gets a similar number of bits. As everyone knows, low motion scenes need fewer bits than high motion scenes because the residual is smaller when not a lot of motion is happening.

On the other hand, high qcomp values cause it to allocate bits unevenly. Instead of forcing each frame to have the same number of bits, it tries to give each frame similar quality.

Unfortunately, in bitrate mode this means high motion scenes tend to suck up inordinate amounts of bits and the overall quality of the whole movie suffers. Yes, your high motion scenes improve, but you won't be able to tell the difference if you're actually watching it!


I don't see why this thread has continued for as long as it has. It's simple, if you want higher quality in high motion scenes (at the expense of your low motion scene quality), you increase qcomp. The only reason why 0.6 is the default is because, like most other defaults, it provides a good balance of quality in your average movie watching experience. If you're really concerned with having nice quality high motion scenes, use CRF mode and increase qcomp slightly.

[simps]

There really is no new concepts in this thread at all though. qcomp controls how bit distribution occurs between scenes.

For bitrate (Non-CRF or QP) low values of qcomp cause it to allocate bits in a CBR-like manner where each frame gets a similar number of bits. As everyone knows, low motion scenes need fewer bits than high motion scenes because the residual is smaller when not a lot of motion is happening.

On the other hand, high qcomp values cause it to allocate bits unevenly. Instead of forcing each frame to have the same number of bits, it tries to give each frame similar quality.

Unfortunately, in bitrate mode this means high motion scenes tend to suck up inordinate amounts of bits and the overall quality of the whole movie suffers. Yes, your high motion scenes improve, but you won't be able to tell the difference if you're actually watching it!


I don't see why this thread has continued for as long as it has. It's simple, if you want higher quality in high motion scenes (at the expense of your low motion scene quality), you increase qcomp. The only reason why 0.6 is the default is because, like most other defaults, it provides a good balance of quality in your average movie watching experience. If you're really concerned with having nice quality high motion scenes, use CRF mode and increase qcomp slightly.

Agreed. I still want to post the mid and high bitrate comparison, to show you can get a overall better quality with higher qcomp. Is it going to be as high as in the low bitrate test? No. Maybe 0.8, 0.7, I don't know yet, need to do more tests.

Also, the idea of "adaptative qcomp" would be some BIG WIN, if possible. What do you think about that?

[Sagekilla]

Adaptive qcomp sounds absurd and unnecessary. I have reason to believe it would make rate control completely screwy and unreliable for that matter.

My point is that qcomp = 0.6 works fine for your average encode. In terms of crf, this means most people use values from 18 - 25 whereas your encodes of 240 kbps is akin to going to crf 30. As (I believe) Audionut said earlier, why ruin 95% of the encodes to benefit the 5% where higher qcomp matters? If you're -really- concerned with quality, you would find what works best for your source.

I mean, if you can find conclusive evidence on a wide variety of videos across different bitrates (low to high) and rate control modes (1-pass, 2-pass, crf, qp) that higher qcomp is more beneficial now to the overall quality, by all means post your results. But I don't think you're going to find any real difference at mid to high bitrates.

Remember, if you're seriously going to look at changing qcomp, do extensive testing on many different videos. One isn't going to cut it.

[kumi]

The audionuts screen shot of rambo close up looks better to me at default. more detail. but thats just mho.Agreed.

[simps]

Agreed.

But I agree to that too. This just shows --qcomp 0.89 is extreme for that mid bitrate and res. This doesn't say anything about how a --qcomp 0.7 or --qcomp 0.8 would perform, and this are both higher than the 0.6 default.

The only thing you can conclude so far is that for low bitrates with SD res, you can have better results up to some --qcomp 0.89 at least. There is evidence for this here.

The other thing you can conclude, is that for mid bitrates with 720p resolutions, a --qcomp 0.89 is too much and won't work for the best. And that is it, you can't say anything about other higher than default values, for example 0.7 or 0.8, for mid bitrates so far.

The problem here, is that people is kida slow minded (no offense to anyone). First when I stated the issue, people were thinking I was talking about --qcomp 1, which is not true. Now that I've posted that a --qcomp up to 0.89 is better for low bitrates at SD, people are using the 0.89 value to compare at 720p with mid bitrate.

The point I made, is that you CAN find a higher than default value of --qcomp for the bitrate you want. They will just not be a constant.

For low bitrates you might have some 0.89 optimal, for mid bitrates it might be some 0.72 and for high bitrates it could be 0.66. I am speculatin this numbers so far, just to get you an idea. But with my tests we will get to the correct numbers.

The point is, if you can find a higher --qcomp to suit you at any given bitrate, than why 0.6 is default?

This is the idea here, and what we are trying to find out.
It is too bad that people are slow minded and don't get the point, like Audionut doind that test with --qcomp 0.89, and concluding something that has NOTHING to do with what I am saying. That test does not prove me wrong.

Sorry for the "slow minded" term. My english is bad and I don't know what is the right term to use to define this.

For the mid bitrate discussion, you will need to wait for me to post my results. I will not do small clips like Audionut did, because that don't represent what the bit distribution will be when you encode the full movie. I will do it the right way, encoding full movie with each setting, and it takes time. I also have other things to do, so I won't be posting this today or tomorrow. When I have it posted here, than lets discuss the mid bitrate issue. And than, lets start to work on the high bitrate.

[Guest]

@simps

Since you're now resorting to accusing people of being slow-minded, and you are vacillating in any case about your claims, and your original question has been answered, it's time to close the thread.

If you eventually have some data to support a clear claim, then feel free to start a new thread to discuss it. But please refrain from personal attacks, per forum rule 4.