Unusually small x264 output

[mp3dom]

You can try to set it to 10/12. The bitrate probably will jump to something near the range of pressed BD (25-35 Mbps)

[burfadel]

Yes, there's exactly a 17.57% difference; which is to say, the aq-mode 1 file is 17% larger than its aq-2 variant.

I suspected that would be the case, a lower CRF seems to be needed at times with aq mode 2 I have found.

Try raising the CRF of aq mode 1 until the output filesize is approximately the same as from aq mode 2. Remember CRF can have a decimal too, like 17.6 etc.

A comparison considering the same file size will truly show the quality differences between the aq modes. Of course this shouldn't need to be done, but it is classed as 'experimental' and probably needs some tweaking to suit all scenarios effectively.

[Audionut]

Yes, there's exactly a 17.57% difference; which is to say, the aq-mode 1 file is 17% larger than its aq-2 variant.

And you think there is something wrong with aq-mode 2 :confused:

As suggested, raise the bitrate of the aq-mode 2 encode to that of the aq-mode 1 encode before you make such claims.

[asarian]

And you think there is something wrong with aq-mode 2 :confused:

As suggested, raise the bitrate of the aq-mode 2 encode to that of the aq-mode 1 encode before you make such claims.
Why, yes, actually: if just switching to aq-mode 2 causes a severe deterioration, then yes, I'd say there's something 'wrong' with it; or, at the very least, that it should come with stiff warnings about having to compensate for it by adding bitrate (like lowering CRF). Otherwise people use it and find their output to be of worse quality than that of mode 1.

[nurbs]

Every option potentially has that effect. Turning off mbtree will often inflate the filesize, turning off psy can lead to much lower filesizes. CRF isn't really constant quality, especially not if you change options.

[asarian]

You can try to set it to 10/12. The bitrate probably will jump to something near the range of pressed BD (25-35 Mbps)
I think we're really getting somewhere here. :) Your continual good suggestions have been a big help! With --aq-mode 2 back in, and CRF 10, all of a sudden I got the best output so far:

aq-mode 2 + crf 10 (http://little-albatross.net/crf10.jpg)

And here with CRF 8, which is even slightly better:

aq-mode 2 + crf 8 (http://little-albatross.net/crf8.jpg)

I was 'raised' (ahem) how anything under CRF 16 was ridiculous. And you'd be surprised how many people on this forum as well have told me even CRF 16 is waay too low. But lowering it even further definitely seems the answer for -aq-mode 2 here.

I think I'm getting close to the best I can make it here. :)

[mp3dom]

Not bad, but as I've already seen on grainy source, x264 tends to make some small blocks of no-grain in a grainy source (look at the lowest left part of the seat in the crf10 image). This is not so good to the eye. I think here it could be preferable (at least to the eye) to have a very slighty blur on the grain but preserve the 'complexity' (so rather than have blocks with crispy noise as the source + small smoothed blocks it could be better to have all blocks with a slighty bit blurred grain but with all uniform grainy blocks)

Anyway, the lower the crf is, the more the accuracy is to the source :). What's the average bitrate now? (with crf 0 or qp 0 I think you're in the mathematically lossless)

You could also try to disable trellis 2 (set it to 0) and set deadzone-intra and deadzone-inter both to 0. It could enhance the dithering more (but I think it depends on the source)

[Audionut]

To add to what nurbs posted.

at the very least, that it should come with stiff warnings about having to compensate for it by adding bitrate (like lowering CRF)

So the option should be,

--aq-mode-2-I'm-expecting-the-same-bitrate-as-aq-mode-1-so-warn-me-if-the-bitrate-isn't-the-same-cause-I-don't-understand-how-crf-mode-works-and-need-assistance-so-I-don't-go-to-message-boards-and-post-false-information-based-on-my-own-lack-of-information.

How is supposed to know your shooting for the same bitrate. It's an option that provides a function.

Do a search for crf by Dark_Shikari and learn how it works.

I think we're really getting somewhere here. :)With --aq-mode 2 back in, and CRF 10, all of a sudden I got the best output so far:

And what's the bitrate of the new encode compared to the others!! Can you not see how increasing bitrate, increases quality??????

I was 'raised' (ahem) how anything under CRF 16 was ridiculous. And you'd be surprised how many people on this forum as well have told me even CRF 16 is waay too low. But lowering it even further definitely seems the answer for -aq-mode 2 here.

--aq-mode has got nothing to do with it. "Generally", yes, --crf 16 is normally overkill. But, it's also known, that to fix banding issues, you generally have to throw bitrate at it. ie: lower --crf.

(with crf 0 or qp 0 I think you're in the mathematically lossless)

Yes --crf 0 is lossless as stated by the --help option.

You could also try to disable trellis 2 (set it to 0) and set deadzone-intra and deadzone-inter both to 0. It could enhance the dithering more (but I think it depends on the source)

The only reason to disable trellis is for speed. You could add some psy-trellis to try keep the grain, --psy-rd x.x:0.25

deadzone settings of 0 :confused: Why do you advise settings you're not even sure could help?

[asarian]

So the option should be,

--aq-mode-2-I'm-expecting-the-same-bitrate-as-aq-mode-1-so-warn-me-if-the-bitrate-isn't-the-same-cause-I-don't-understand-how-crf-mode-works-and-need-assistance-so-I-don't-go-to-message-boards-and-post-false-information-based-on-my-own-lack-of-information.

How is supposed to know your shooting for the same bitrate.
Nobody is talking about shooting for the same bitrate -- except you.

There's many options in x264 that lower bitrate, one way or the other. Usually that's good thing (in a nutshell: x264 takes away from scenes that need it less, and gives to scenes that need it more). It only becomes a problem when lowering the bitrate also comes with an overall, severe deterioration of the image quality, as is the specific case here with --aq-mode 2. In cases like that, yes, a simple line somewhere, like: "Please, be sure you substantially increase bitrate when using --aq-mode 2, or you may lose image quality!" wouldn't have been amiss.

And what's the bitrate of the new encode compared to the others!! Can you not see how increasing bitrate, increases quality??????
You really don't get it, do you? :)

It's all about the benefit/penalty ratio. --aq-mode 2 attempts to adapt quantization strength per-frame; and I think we can agree on this happening for the purpose of making things look better, right? In order to achieve the desired result, it apparently (often, it would seem) needs a higher bitrate. That's, in itself, not unreasonable; except that it needs not just a bit more here, but a lot more: i.c., for this movie you need to go from CRF 16 to at least CRF 10. To quote Dark Shikari himself: "Dropping CRF by 6 will double filesize. Dropping CRF by 1 will raise filesize by 12.5%." There you have it.

So the question then is simply: is going from --aq-mode 1 to --aq-mode 2 worth doubling your output file size for? I say no: the penalty here far outweighs any possible, minute visual improvement you may gain. There may well be instances where --aq-mode 2 works miracles at the same bitrate (or with just slightly higher rates); but so far, in earnest, I'm not so sure about it. I've had similar experiences with --aq-mode 2 with "The 13th Floor" and "Avatar." So, I may well revert to using mode 1 on my future encodes. Haven't decided yet.

The only reason to disable trellis is for speed. You could add some psy-trellis to try keep the grain, --psy-rd x.x:0.25

deadzone settings of 0 :confused: Why do you advise settings you're not even sure could help?
His advice, your confusion despite, is dead accurate! And no, "The only reason to disable trellis is for speed" is incorrect. Basically, trellis and the --deadzone settings are incompatible:

--deadzone-inter and --deadzone-intra tweak a parameter of the deadzone algorithm. (The parameter in question is "deadzone", that's where the algorithm got its name.) --trellis determines when to use the trellis algorithm (0=never, 1=sometimes, 2=almost always); any dcts that don't use trellis must use deadzone instead. So, the fact that --deadzone* still has some minor effect when you enable trellis does not contradict the fact that deadzone and trellis are incompatible. Don't do that. If you enable trellis, then deadzone is only used as a fast estimate of trellis, so a reduced value of --deadzone does not provide any grain retention, it just reduces the precision of that estimate and thus of the mode decision process.

So, Mp3dom was spot-on right suggesting I disable trellis when using the --deadzone tweaks. And, indeed, the image quality improved as a result!

[mp3dom]

deadzone settings of 0 :confused: Why do you advise settings you're not even sure could help?

I've see improvements setting deadzone to 0 and trellis to 0 in some fadein/fadeout prior of the fade-improvement patch (which is anyway not committed actually, but only available as a separate patch) even when using weightp 2. In Fadein/Fadeout you need to preserve dithering/subtle grain if you don't want to have posterization during the fades so that setting worked for me. I have not tested it deeply for every kind of footage so I've suggested to try and see if it could help to improve preserving the dithering a lot more.

[Audionut]

Ok sparky.

Nobody is talking about shooting for the same bitrate -- except you.

Yes, because it's the only way to compare 2 different encodes with different settings. crf setting doesn't matter!!!!

In cases like that, yes, a simple line somewhere, like: "Please, be sure you substantially increase bitrate when using --aq-mode 2, or you may lose image quality!" wouldn't have been amiss.

There's no magical way for x264 to figure out in advance what effect a given setting will have on filesize at a given CRF, particularly for some types of settings. It varies wildly from source to source; if there was an easy way to compensate, we would have already done it.
http://forum.doom9.org/showthread.php?p=1386676#post1386676

Of course, that's beside the fact, that any sane person would see that the bitrate has dropped significantly and would lower their crf setting to compensate before saying this or that option is bad. You cannot compare different settings at different bitrates. crf does not compare, equal, mean bitrate. Expect to say, that lowering crf, increases bitrate and raising crf, lowers bitrate, with the same settings.

And also besides the fact that doing just that, ie: lowering crf to compensate, which you have tested, increased the quality with aq-mode 2.

I think we're really getting somewhere here. :) Your continual good suggestions have been a big help! With --aq-mode 2 back in, and CRF 10, all of a sudden I got the best output so far:

Fancy that!!!!!!!!!!!!!!!!!!:stupid:
Are those encodes about the same bitrate? Cause the fact that they have different crf settings, doesn't mean anything.


You really don't get it, do you? :)

It's all about the benefit/penalty ratio. --aq-mode 2 attempts to adapt quantization strength per-frame; and I think we can agree on this happening for the purpose of making things look better, right? In order to achieve the desired result, it apparently (often, it would seem) needs a higher bitrate. That's, in itself, not unreasonable; except that it needs not just a bit more here, but a lot more: i.c., for this movie you need to go from CRF 16 to at least CRF 10. To quote Dark Shikari himself: "Dropping CRF by 6 will double filesize. Dropping CRF by 1 will raise filesize by 12.5%." There you have it.

Full of fail. --crf doesn't mean you will get a certain bitrate with different options as you have found out. How do you know that aqmode 2 needs a higher bitrate to maintain the same quality? Can you post you command line results proving this, or are you basing the fact that aqmode 2 requires crf 10 to equal aqmode 1 at crf 16 on this source. Again, --crf xx.xx doesn't mean you will get the same bitrate or same quality when changing options.
There's no magical way for x264 to figure out in advance what effect a given setting will have on filesize at a given CRF
So how about making an encode with aq-mode 1 at crf 16. Note down the resulting bitrate of the encode, and then make another encode with aq-mode 2 while adjusting crf to get an encode with the same bitrate. The fact that each encode uses a different crf doesn't mean diddly squat. If both encodes hit the same bitrate or very close, only then can you compare aq-mode 1 and aq-mode 2 on this source and make a claim that 1 is better than the other.


So, Mp3dom was spot-on right suggesting I disable trellis when using the --deadzone tweaks. And, indeed, the image quality improved as a result!

do,

x264.exe --preset slower -o x:\output.mkv input.avs

x264.exe --preset slower --trellis 0 --deadzone-inter 0 --deadzone-intra 0 -o x:\output.mkv input.avs

Adjust the crf of each to get an equal bitrate encode from both and then judge quality.

Trellis has the benefit of psy-trellis, so you could also do,

x264.exe --preset slower --psy-rd 1.00:0.25 -o x:\output.mkv input.avs

Again adjust the crf to get the same bitrate as the 2 encodes you get above and see the result.

[Audionut]

I have not tested it deeply for every kind of footage so I've suggested to try and see if it could help to improve preserving the dithering a lot more.

I do apologize for this coming across rather nasty in advance.


I would suggest, particular as you yourself have not thoroughly tested the settings, that you don't offer settings advice such as --deadzone to someone who clearly doesn't have a grasp on how to compare 2 different settings.

Also, you advise him to adjust based on your experience with fades, and I don't recall the op mentioning fades.

Also, as you rightly point out, fade-compensate patch helps with fades and will mean that the op will probably still be using funky deadzone parameters when the patch has been committed.

That setting is only adjusted once out of every preset and tune option provided by the developers of x264 and only down to 6.

[asarian]

Of course, that's beside the fact, that any sane person would see that the bitrate has dropped significantly and would lower their crf setting to compensate before saying this or that option is bad.
You wilfully don't get it, do you? If you pay X amount for quality Y with option Z, and you have to pay X x 2 for same quality Y with option Z2, then any sane person would shy away from using option Z2. Why is this concept so difficult to grasp for you?

Full of fail. --crf doesn't mean you will get a certain bitrate with different options as you have found out.
Again with the strawman! Nobody staked such a claim about getting a certain bitrate.

How do you know that aqmode 2 needs a higher bitrate to maintain the same quality? Can you post you command line results proving this,
Don't need to: already did. I posted two samples, one with aq-mode 1, and the other with aq-mode 2 (and otherwise same settings). Clearly the aq-mode 2 sample was worse, and could only be 'cured' by increasing bitrate drastically (= lowering CRF, in this case).

The fact that each encode uses a different crf doesn't mean diddly squat. If both encodes hit the same bitrate or very close, only then can you compare aq-mode 1 and aq-mode 2 on this source and make a claim that 1 is better than the other.
As I've tried to explain to you, for the umptiest time, 'better' is not just a matter of final output quality, but also a matter of cost. If it costs me twice as much in file-size to achieve the same result with aq-mode 2 as it does for aq-mode 1, then, in this case, however loud you decry the fact, aq-mode 2 is bad.

[Audionut]

Don't need to: already did. I posted two samples,

Screen shots are not samples.

[MokrySedeS]

Why is this concept so difficult to grasp for you?

I'm sorry, but it is for YOU, obviously. Audionut is absolutely right.

[asarian]

I'm sorry, but it is for YOU, obviously. Audionut is absolutely right.
All y'all can agree with each other until you see blue in the face, LOL, but I, for one, am not prepared to double the output file size with aq-mode 2, to get the same result with what aq-mode 1 offers me for half the size. If that makes me wrong, then I don't want to be right. :)

[Audionut]

It's not a matter of wrong or right, simply that you seem to be confused about a few things.

Bitrate and file-size are directly comparable. Increase bitrate, increase file-size. decrease bitrate, decrease file-size. No, ifs, buts or maybe's.

Lower crf, increase file-size, raise crf, lower bitrate. Unless you change other command line options. You've experienced it yourself. Your original aq-mode 2 vs aq-mode 1 encodes at the same crf had completely different bitrates and file-sizes.

This doesn't make aq-mode 2 bad. It simply means that x264 is not smart enough to maintain the same bitrate (file-size) when enabling aq-mode 2 as what happened when it encoded it with aq-mode 1.

This also is not a bad thing. It just means that the user has to manually adjust the crf setting if he wants to hit the same bitrate (file-size) as he got with aq-mode 1.
edit2: I guess what you are saying, is that x264 should get the same quality with the same crf regardless of other options. It doesn't work like that, and afaik, won't work like that any time soon. There are simply to many variables to take into consideration.

Please, for the love of god, conduct this little experiment.

Make one encode with aq-mode 1. Now make another encode with aq-mode 2 and adjust no other option except --crf to make the aq-mode 2 encode equal the same bitrate (file-size) as the aq-mode 1 encode.

Now have a look at both encodes and decide which you like the best. If you conduct this experiment, I don't care if you decide aq-mode 2 sucks balls, and aq-mode 1 is best. Atleast I will know that you have conducted an analysis of aq-mode 1 vs aq-mode 2 correctly.

edit: all other things being equal, bitrate and quality are also directly comparable. Increase bitrate, increase quality.

[mp3dom]

Using CRF for that kind of test I think is too a "hit-or-miss". It could require a lot of time to hit the same bitrate since with CRF you don't know the final used bitrate. Probably is better to do a 2pass encode with fixed bitrate/maxrate/bufsize.

[Audionut]

Using CRF for that kind of test I think is too a "hit-or-miss". It could require a lot of time to hit the same bitrate since with CRF you don't know the final used bitrate. Probably is better to do a 2pass encode with fixed bitrate/maxrate/bufsize.

Yes and no. But most importantly, the op doesn't seem to quite understand the relationship between, crf, different settings and bitrate (file-size)

He seems to think that a lower crf automatically means larger file-size. Which in turn bases his opinion that aq-mode 2 is crap on the fact that aq-mode 2 requires a lower crf to hit the same quality and/or file-size.

@asarian

You can add --frames 1500 to the command line. This will make each encode shorter and faster to get the correct crf settings for both encodes.
Or, upload a small sample of the original source somewhere, and I'll do the test for you and post all the results here.

edit: just for a bit of clarity around something you posted earlier and I missed.
To quote Dark Shikari himself: "Dropping CRF by 6 will double filesize. Dropping CRF by 1 will raise filesize by 12.5%." There you have it.

This is true for encodes with the same settings. If you change settings, for example, aq-mode, then that statement by Dark Shikari is meaningless.

[creamyhorror]

It's all about the benefit/penalty ratio. --aq-mode 2 attempts to adapt quantization strength per-frame; and I think we can agree on this happening for the purpose of making things look better, right? In order to achieve the desired result, it apparently (often, it would seem) needs a higher bitrate.
How is this supported by what you posted? Your aq-mode 1 encode had a bitrate 17.6% higher than your aq-mode 2 encode, and the quality of the former was (expectedly) better. The unequal bitrates is a confounding factor to the question of whether aq-mode 1 or 2 is better: you have to eliminate it if you want to make a pronouncement.

CRF is not an absolute scale tied to a particular bitrate curve. It changes for many combinations of options. Under certain options (and across different sources) you may have to use lower or higher RF values than normal to achieve the level of quality you want. aq-mode is probably one of those options.

So the question then is simply: is going from --aq-mode 1 to --aq-mode 2 worth doubling your output file size for? I say no: the penalty here far outweighs any possible, minute visual improvement you may gain. There may well be instances where --aq-mode 2 works miracles at the same bitrate (or with just slightly higher rates); but so far, in earnest, I'm not so sure about it.
On what basis? Have you actually tested the same-bitrate case?

Simply do a 2-pass encode under aq-mode 2 with the same bitrate as a CRF encode under aq-mode 1, and compare those. That is a fair test.

I think you had an expectation that you should be able to use the same RF values irrespective of your other settings, to obtain (roughly) the same bitrates. This is simply not justifiable in light of how CRF and bit distribution works. Audionut may have been rather blunt, but he's right, in a nutshell. Even mp3dom wouldn't disagree.

[asarian]

Originally Posted by asarian
To quote Dark Shikari himself: "Dropping CRF by 6 will double filesize. Dropping CRF by 1 will raise filesize by 12.5%."
This is true for encodes with the same settings. If you change settings, for example, aq-mode, then that statement by Dark Shikari is meaningless.
And this is exactly what I've done all along: I only lowered CRF (from 16 to 10), both with aq-mode 2 and everything else the same; and, lo and behold, my output file size doubled.

Your aq-mode 1 encode had a bitrate 17.6% higher than your aq-mode 2 encode, and the quality of the former was (expectedly) better. The unequal bitrates is a confounding factor to the question of whether aq-mode 1 or 2 is better: you have to eliminate it if you want to make a pronouncement.
People seem to be under the impression (introduced by Audionut) that I don't understand this. Well, I do. :)

What people seem to gloss over here, en masse, is that I've repeatedly said I already needed to go way beyond equal bitrates for -aq-mode 2 to get the same visual quality as I did for aq-mode 1. In this case, on my aq-mode 2 encoding, I had to lower CRF all the way to 10 (down by 6) to even get something looking similar to what I got from aq-mode 1. So, for the aq-mode 2 encode, I wound up with a file that was 164.8% the size of that of the aq-mode 1 file (remember, with both at CRF 16, the aq-mode 2 file was 17.6% smaller to begin with).

Also, I've never sad aq-mode 2 sucks in general. I've continually said that, in this partical case it makes things much worse, and that I needed to lower CRF too much for my taste to compensate for the quality loss.

For the sake of curiosity, I'll gladly do some experimenting (after the current encoding job is done) with roughly equal bitrates between aq-mode 2 and 1. For this particular movie (Evangelion 1.11), I already know the result: it's worse; but there are some other movies I can try, like "The 13th Floor," with good dark scenes, that will perhaps give me a fairer idea of what I can expect from aq-mode 2 for regular movie content at comparable bitrates. Anime, encoding wise, simply remains a category of its own.

EDIT: Current bitrate for aq-mode 2 sample with CRF 10 hovers between ~40-60Mb/s.

[asarian]

... Also, with the lowish bitrates you're getting, the bitrate isn't going to get anywhere near those vbv values. And even, if you had a crazy scene that "maybe" could reach those bitrates, imo, it would be frames of just grain like the hbo logo and would be better being limited in bitrate to spare more for the rest of the movie.
Hmm, I don't think I fully understand this. I thought CRF encoding was kinda 'open-ended' that way, in that it doesn't matter whether or not one scene needs a whole lot of bitrate, as it won't be subtracted from some sort of total amount.

After several encodes with the new x264 and settings, indeed, I'm seeing lower average bitrates and higher max rates (vs. higher average rates vs. lower max rates, as it used to be). If I wanted to allow bitrate intense scenes to keep their high bitrate, without this going at the expense of the rest, would lowering qpmin help?

[nm]

Hmm, I don't think I fully understand this. I thought CRF encoding was kinda 'open-ended' that way, in that it doesn't matter whether or not one scene needs a whole lot of bitrate, as it won't be subtracted from some sort of total amount.

Correct.

[asarian]

Correct.
In that case, how should I interpret Audionut's comment about sparing bitrate for the rest of the movie? :confused:

[nurbs]

You should interpret them as only being applicable for when you use bitrate based encoding and VBV.

[nm]

Yep.

Btw, I'd use Blu-ray compatible settings if those encodes are archived for later use. That way you may not need to re-encode if you get another standalone device at some point.

[asarian]

You should interpret them as only being applicable for when you use bitrate based encoding and VBV.
Oh good, thanks. :) Trying to eliminate the possible reason(s) for getting consistently lower bitrates with my new encodes; so, with my CRF encodes, at least I can strike off my unusually high VBV setiings as the cause.

Btw, I'd use Blu-ray compatible settings if those encodes are archived for later use. That way you may not need to re-encode if you get another standalone device at some point.
I currently stream my encodes from my TwonkyMedia media server; so I can lax a bit on absolute scrictest Blu-Ray compliance. I don't go over the amount of specified reference frames for a certain resolution; but b-frames and bitrate and such, I tend to give myself some allowance in that area. :)

[nurbs]

You have been told several times why you are getting different bitrates. You have skipped 500 revisions, you are using completely different settings and a different ratecontrol method (mbtree).

[asarian]

You have been told several times why you are getting different bitrates. You have skipped 500 revisions, you are using completely different settings and a different ratecontrol method (mbtree).
I just found a good article on mbtree. Finally understand what it does now, and why I'm getting lower bitrates with it. :)

Okay, I'll stop worrying about the bitrate decrease now. Thanks for your patience.