Why is --qcomp 0.6 default for 2passes?

[Chengbin]

Originally Posted by Dark Shikari

This is not what qcomp is for.

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

[simps]

Originally Posted by Chengbin

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]

Originally Posted by Chengbin

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]

Originally Posted by Dark Shikari

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]

Originally Posted by 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

qcomp is applied before, not after, VBV.

[simps]

Originally Posted by Chengbin

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]

Originally Posted by Dark Shikari

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]

Originally Posted by Dark Shikari

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

[simps]

Originally Posted by 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.)

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


--qcomp 0.84


--qcomp 0.7


--qcomp 0.84


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]

Originally Posted by juGGaKNot

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

BHH