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.