Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > MPEG-4 AVC / H.264

Closed Thread
 
Thread Tools Search this Thread Display Modes
Old 24th May 2009, 19:04   #1  |  Link
simps
Registered User
 
Join Date: Feb 2005
Posts: 149
Why is --qcomp 0.6 default for 2passes?

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

Last edited by simps; 26th May 2009 at 08:05. Reason: rule 9
simps is offline  
Old 24th May 2009, 19:08   #2  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,690
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.

Last edited by Dark Shikari; 24th May 2009 at 19:36.
Dark Shikari is offline  
Old 24th May 2009, 19:19   #3  |  Link
simps
Registered User
 
Join Date: Feb 2005
Posts: 149
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?
simps is offline  
Old 24th May 2009, 19:20   #4  |  Link
JohannesL
AviSynth/x264 user
 
JohannesL's Avatar
 
Join Date: Jan 2009
Posts: 149
A higher qcomp seems better for very low bitrates.
__________________
archlinux
JohannesL is offline  
Old 24th May 2009, 19:36   #5  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,690
Quote:
Originally Posted by simps View Post
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.
Dark Shikari is offline  
Old 24th May 2009, 19:37   #6  |  Link
simps
Registered User
 
Join Date: Feb 2005
Posts: 149
Quote:
Originally Posted by JohannesL View Post
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.

Last edited by simps; 24th May 2009 at 19:40.
simps is offline  
Old 24th May 2009, 19:42   #7  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 12,928
Quote:
Originally Posted by simps View Post
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.
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.



Last edited by LoRd_MuldeR; 24th May 2009 at 19:44.
LoRd_MuldeR is offline  
Old 24th May 2009, 19:46   #8  |  Link
simps
Registered User
 
Join Date: Feb 2005
Posts: 149
Quote:
Originally Posted by Dark Shikari View Post
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 is offline  
Old 24th May 2009, 19:48   #9  |  Link
simps
Registered User
 
Join Date: Feb 2005
Posts: 149
Quote:
Originally Posted by LoRd_MuldeR View Post
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.
simps is offline  
Old 24th May 2009, 19:52   #10  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 12,928
Quote:
Originally Posted by simps View Post
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...
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.



Last edited by LoRd_MuldeR; 24th May 2009 at 19:55.
LoRd_MuldeR is offline  
Old 24th May 2009, 19:55   #11  |  Link
Chengbin
Registered User
 
Join Date: Oct 2007
Posts: 1,059
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.
Chengbin is offline  
Old 24th May 2009, 19:56   #12  |  Link
simps
Registered User
 
Join Date: Feb 2005
Posts: 149
Quote:
Originally Posted by LoRd_MuldeR View Post
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.
simps is offline  
Old 24th May 2009, 19:56   #13  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,690
Quote:
Originally Posted by simps View Post
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.
Dark Shikari is offline  
Old 24th May 2009, 20:00   #14  |  Link
simps
Registered User
 
Join Date: Feb 2005
Posts: 149
Quote:
Originally Posted by Chengbin View Post
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.
simps is offline  
Old 24th May 2009, 20:05   #15  |  Link
Chengbin
Registered User
 
Join Date: Oct 2007
Posts: 1,059
Quote:
Originally Posted by simps View Post
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.
Chengbin is offline  
Old 24th May 2009, 20:10   #16  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,690
Quote:
Originally Posted by Chengbin View Post
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.
Dark Shikari is offline  
Old 24th May 2009, 20:13   #17  |  Link
Chengbin
Registered User
 
Join Date: Oct 2007
Posts: 1,059
Quote:
Originally Posted by Dark Shikari View Post
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.
Chengbin is offline  
Old 24th May 2009, 20:13   #18  |  Link
simps
Registered User
 
Join Date: Feb 2005
Posts: 149
Quote:
Originally Posted by Chengbin View Post
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.

Last edited by simps; 24th May 2009 at 20:15.
simps is offline  
Old 24th May 2009, 20:16   #19  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,690
Quote:
Originally Posted by Chengbin View Post
That's exactly what I mean why high qcomp is not optimal for high bitrates.
This is not what qcomp is for.
Dark Shikari is offline  
Old 24th May 2009, 20:20   #20  |  Link
Chengbin
Registered User
 
Join Date: Oct 2007
Posts: 1,059
Quote:
Originally Posted by simps View Post
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 is offline  
Closed Thread

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 03:14.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.