how to predict quaity using x264

[((( atom )))]

Hi,

using xvid for ages meanwhile (600+ rips with gk) i think it is about time to move on to x264.
I found MEGui to suit most of my needs perfectly but for one: A compressibility test. I read several guides and opinions but could not make out anything usefull to answer my question why it is not present.

All the guides just say something like: "load and crop your movie and choose a filesize??!?"
It might be true for very new Movies that they all compress similar, but the movies I watch range from 1950 till today with a strong focus between 1960 and 1980. A mix of such sources is impossible to predict in compresibility by just watching the source.

Now there are people that say comp.-tests are unreliable since they only scan a percentage of the film but my experience is that their filesize prediction mostly hits the 1st pass size pretty good and if not, I can still reencode that particular movie.

Also comp.-tests allow decisions like using a different matrix or switch b-frames on or off to loose or gain an extra 5-15 percents of compressibility or to use the next step in accepted filesizes. All in all very nice system to precisely match quality size and resolution...

So how do people deal with that when using MEGui? crop, pray and encode? I cant't really imagine that after I have been rather actively watching people in this forum very long but also quite a while ago. Finding the ultimate settings was always taken very seriously here, so please someone set me on track again..

With best regards,

((( atom )))

[Dark Shikari]

Solution is to just use CRF mode... constant quality > constant filesize.

[((( atom )))]

But that would lead to different filesizes depending on movie length, so no more putting number x movies to a dvd for example. I think that is very unsatisfying, since in my understanding choosing a filesize for a rip should be no problem, never was..

[check]

If you feel that one bitrate does not fit all movies, then Constant Quality is for you :) Instead of aiming for a target filesize, with unknown quality (or partly guessed quality from comptest), Constant Quality (aka CRF) gives you a target quality, with unknown filesize (or partly guessed from comptest). Try encoding a film with constant quality 19.5, and see what you think.

If you find the quality is too high and you're prefer a smaller file, increase the number. Do the opposite if you want higher quality. A good range to try is between 17.5 and 22.0

[buzzqw]

automkv has a compression test with x264

it encode the 5% of movie in CRF 18, and looking at file size argue best width for keeping quality all thu movie

BHH

[RaynQuist]

To reiterate the OP's need, he wants his encodes to be of at least a certain quality, but wants the final filesize to be a DVD-friendly size. For example if quality is sub-par at 1/5 DVD he'll bump it to 1/4 DVD and if that's not good enough go to 1/3 DVD. Any file sizes in between will make the DVD under-utilized.

Personally I just guess, and if the quality sucks I'll take the hit and waste my time to re-encode.

[foxyshadis]

Rayn, that's a pretty inefficient way to go about it, though. If you have a target size and need to optimize the videos for it, the best you can aim for is to have all of them be about the same average qp. (Unless you care about some more than others.) You can do that by running a 2% or even 5% compressibility test on all the files, using a crf in the range you expect (18-22 are good choices, normally), and taking the relative filesizes of the output as ratios of the final sizes. Just scale the total sizes up to DVD, take the calculated bitrates, and encode away. Remember to include audio.

That's more trouble than I care to spend, I find an external HD or two more effective than easily damaged, difficult to manage stacks of DVDs, especially since the cost per gig is almost the same nowadays.

[SealTooGreat]

Atom, if you are aiming to the target size, thus you have certain value of bitrate to apply, than you have to do resizing in order to keep constant bpp over the picture. See the equation -> widht*height*fps*bpp/1000=kbps, where const. are fps and kbps (calculated from target size). Than select quality bpp and calculate width x height from mentioned inputs. Put the bitrate in ABR 1pass cmd/preset and encode the stream (which now have changed resolution). I think that FairUse have this type of an approach. Otherwise use CRF, if target size isn't of your interests.
automkv has a compression test with x264

it encode the 5% of movie in CRF 18, and looking at file size argue best width for keeping quality all thu movie

BHH

Can you give quick explanation of arguing the best width. What happen after a compression test - Does encoder use CRF or bitrate?

[akupenguin]

if you are aiming to the target size, thus you have certain value of bitrate to apply, than you have to do resizing in order to keep constant bpp over the picture.
Haven't we discredited bpp thoroughly enough already?
The factors that make crf better than bpp don't depend on whether you have a target quality or a target size. If you agree that crf is a better measure of quality than bpp is, then you should use crf to determine resolution when encoding to a target size too. If you think bpp is a better measure of quality, then I need to go find my rant on the subject.

[buzzqw]

as i said i to a selectrangeevery to get 5% of full movie, the encode with selected profile (for get options used) but using CRF 18

then i do some calculous

width= original_width*(((select_size_bytes - audio_size)/0.99)/compression_test_size_bytes/12.5)

so a 720 width movie, compression test 80mb, audio size 96mb, 1 cd size wanted = 720*(((734003200-100663296)/0.99)/83886080/12.5) = 426.666 = 432 width (mod16)

using extreme profile of x264 the 12.5 could be lowere to 11 (and get 496 width)

empiric but efficent from my numerous tests, in this way you got a drf medium of ~18

BHH

[SealTooGreat]

If you agree that crf is a better measure of quality than bpp is, then you should use crf to determine resolution when encoding to a target size too.

So coud you point me how to use crf to determine resolution, keeping my aim as close to target size, but not doing 2pass?

Edit: buzzqw, thanx, although I don't understand math behind that on quick view.

[PuzZLeR]

I personally don't understand the need for all this. It's all a question of objectives: Either you want a quality level or you want a file size. You will never find the "sweet spot" that serves both objectives simultaneously.

Simple answer: pick an objective.

If you want a certain file size then just encode to that file size. What you get is what you get. If you want more quality, then just use slower options to squeeze a tad more into that size.

If you want a certain quality then use CRF and adjust your way of thinking:

Wrong way of thinking when using CRF: How do I get CRF to give me this file size?

Correct way of thinking when using CRF: What is the minimum quality (highest quantizer) I will accept to get the smallest file size possible?

Forget exact file sizes, especially with inexpensive huge hard drives available. The "exact file size" philosophy is a thinking of the past, when storage was scarce, and even so was wrong then too.

When the final specs of the CD were established 25 years ago, the size of it was not chosen because they wanted it to fit a compressed movie in H.264 to an optimal quality.

[SealTooGreat]

Haven't we discredited bpp thoroughly enough already?
The factors that make crf better than bpp don't depend on whether you have a target quality or a target size. If you agree that crf is a better measure of quality than bpp is, then you should use crf to determine resolution when encoding to a target size too. If you think bpp is a better measure of quality, then I need to go find my rant on the subject.
Why should bpp be discredited?! It's not bad though. And it's not that bpp is rate control, it's number upon I'm calculating bitrate or width/height in ABR 1_pass for purpose of getting desirable target size. ABR is rate control in this case not bpp. When we are talking about CRF you just can't only use parameter CRF in cmd without quantizer number beside it.

By the same spoken, it is not about CRF vs bpp, but rather ABR vs CRF(or "any other rate control" vs CRF), where bpp is similiar to CRF number (ie CRF 22) as a quality factor. Both values (bpp or CRF number) are subjectively/empirically chosen regarding quality/size trade-off, if one exist.

The fact is that CRF, as a rate control, is better than ABR, but that doesn't mean that ABR is bad, though. CRF is not target size predictable, unless you use it as an 1pass of 2pass(am I wrong?). And I don't use 2pass, only ABR_1pass. (my computer is rather slow for 2pass and it takes more than 15h to encode as such)

If you can show me how can I predict target size by CRF as an only 1 pass, I would be appreciated. :)

[Dark Shikari]

Why should bpp be discredited?! It's not bad though. And it's not that bpp is rate control, it's number upon I'm calculating bitrate or width/height in ABR 1_pass for purpose of getting desirable target size. ABR is rate control in this case not bpp. When we are talking about CRF you just can't only use parameter CRF in cmd without quantizer number beside it.

By the same spoken, it is not about CRF vs bpp, but rather ABR vs CRF(or "any other rate control" vs CRF), where bpp is similiar to CRF number (ie CRF 22) as a quality factor. Both values (bpp or CRF number) are subjectively/empirically chosen regarding quality/size trade-off, if one exist.
BPP is exactly the same as target bitrate, because if you know the length of the video and its resolution, target BPP is equivalent to target bitrate. It completely ignores that many videos need a lot more bitrate (or a lot less) than others, and therefore it is nothing like CRF at all.

CRF means a specific quality. You choose the CRF because you want that specific quality. You don't think "what CRF do I need to get the quality in this video that CRF 22 got me in the last video" because the answer to that is, of course, CRF 22.

[PuzZLeR]

On the subject of BPP. This can be wrong thinking if you take it so far. It needs some care.

Two reasons:

1) A certain BPP may produce great quality in one film, but bad in another. Just like bitrate, and file size, this is fact.

2) One may get carried away with BPP. For example, there could be a false sense of security if you encode something to a very high BPP and conclude it sufficient. If your resolution is something like 160x120, you don't need that much bitrate to get a high BPP value. On a small screen it may look awesome. Blow it up to a big screen and you could be in trouble...

[SealTooGreat]

BPP is exactly the same as target bitrate, because if you know the length of the video and its resolution, target BPP is equivalent to target bitrate. It completely ignores that many videos need a lot more bitrate (or a lot less) than others, and therefore it is nothing like CRF at all.
Pls, read carefully what I have written. If you can't achieve target size using bpp, than resize video to lower values to satisfy the input bpp. As for "many videos need a lot more bitrate", that's true, but I'm limited with my hdd and I have to behave in such direction. And you still don't saying how you determine quantizer number you have to put next to the --CRF - It's subjective as bpp is. Once again, we are talking about CRF vs ABR, where each of them has it's own quality factor, bitrate(through bpp and width/height resizing) and quantizer number, respectivaly. CRF has better rate control than ABR, but it doesn't satisfy my needs.



CRF means a specific quality. You choose the CRF because you want that specific quality. You don't think "what CRF do I need to get the quality in this video that CRF 22 got me in the last video" because the answer to that is, of course, CRF 22.

I'm aware that CRF apply bitrate upon video complexity which varies from case to case. CRF can"t give me target size as only 1pass, ABR can. (and I don't use 2pass as I've said)

[Dark Shikari]

I'm aware that CRF apply bitrate upon video complexity which varies from case to case. CRF can"t give me target size as only 1pass, ABR can. (and I don't use 2pass as I've said)
Wait, you're using 1-pass ABR?! Are you nuts?

There's a considerable amount of quality loss in such a method (SSIM is lower by a wide margin overall), especially in high-motion scenes.

[PuzZLeR]

@SealTooGreat:

I understand your restraints, but keep in mind, probably the worst quality per bitrate/BPP/file size, etc, is 1-pass ABR.

One solution, is design an AVIsynth script that calculates every tenth frame with a quantizer. This will give you inference of quality quite accurately at a fraction of the time. Or maybe use a DivX or Xvid quantizer to do a quick pass ahead to determine, at least an idea, of the film's complexity and needs.

Other than that my friend, you may want to prioritize a future investment. Video, including H.264, is very demanding on PC resources as we all know.

[PuzZLeR]

See what you did SeatTooGreat? You freaked out two people at the same time in the last two posts with ABR 1-pass!:p

[Dark Shikari]

See what you did SeatTooGreat? You freaked out two people at the same time in the last two posts with ABR 1-pass!:pMy most recent experience with that was my crazed attempt to encode 300 in 720p to fit on a single CD-ROM. With tons of denoising it worked (about 775kbps on the video, and stereo AAC-HE audio), but the difference between the first pass and second was night and day even though they used similar encoding settings. The first pass had loads of blocky scenes; even the "WB" logo in the intro was blocked to high heaven. The second pass had hardly a noticable blocky scene in the whole movie.

Summary: 1-pass ABR = bad.

[SealTooGreat]

Really I don't have any problem with ABR 1pass. :)

[PuzZLeR]

DS, I agree 100%. Been there myself.... ugghhhh.... even WORSE with codecs like DivX....:scared:

Summary: 1-pass ABR = bad.

Yes, but it does have one use I believe: Only for a one-time view on a tiny screen like an iPod where you don't care for quality. You only need a quick'n'dirty encode for something that you'll only delete after. Definitely NOT for archival purposes...

[CruNcher]

@Dark Shikari

What about if you use more tools in the 1pass abr so a higher compression factor compared to a less tools compression factor 2pass encode ? hehe i know 1 pass can't predict the complexity without a lookahead but does it really need too if compression is high enough for the complexity of the source ?
im still about to test it but somehow i feel that H.264 is much more efficient in that way then ASP and alot of people here only wan't better quality then ASP gave with small resolutions but with higher ones these days so ABR seems perfect to reach that in a timely manner sure decoding endsup to be more complex this way. But i doubt the difference would be that Visible for the Encoding time you would need for 2 passes :P but i could be wrong (it's all about how you balance it in the end) agreed a 2 pass is optimal but is it also the best balanced way ;).
At the moment only CRF seems to be better you wouldn't be able to predict final size 100% but balanced decoding complexity and encoding time very well :)

[SealTooGreat]

@PuzZLeR
Ipod have profile restriction. Using ABR is far away form such comparison. ;)

[Dark Shikari]

@Dark Shikari

What about if you use more tools in the 1pass abr so a higher compression factor compared to a less tools compression factor 2pass encode ? hehe i know 1 pass can't predict the complexity without a lookahead but does it really need too if compression is high enough for the complexity of the source ?
im still about to test it but somehow i feel that H.264 is much more efficient in that way then ASP and alot of people here only wan't better quality then ASP gave with small resolutions but with higher ones these days so ABR seems perfect to reach that in a timely manner sure decoding endsup to be more complex this way. But i doubt the difference would be that Visible for the Encoding time you would need for 2 passes :P but i could be wrong (it's all about how you balance it in the end) agreed a 2 pass is optimal but is it also the best balanced way ;)
I'd rather have a --subme 6 --me hex --ref 3 twopass than a --subme 7 --me umh --ref 6 --no-fast-pskip onepass; the difference in quality is probably larger from the twopass than from the extra options, and more importantly it doesn't destroy high motion scenes.

Why not just use CRF if you insist on onepass?

[foxyshadis]

Really I don't have any problem with ABR 1pass. :)

Maybe not, but you apparently either don't care about quality, or don't have serious filesize restrictions. You're welcome to use whatever settings and formulae you like, but you should make the well-known caveats of such methods apparent in your posts, or they'll degenerate into these flamewars.

[CruNcher]

@Dark Shikari
don't forget that in a High Motion Scene if it's a fast one in terms of timing for example (a car drives by the camera introducing motion blur followed by a scenecut) you won't see the blocks that are introduced by a onepass HVS wise in such a scene sure your metrics would go crazy ;) but the Eye is much more complex then a metric. HVS wise i think it's a good idea to also take the time into account a High Motion Scene lasts on screen for improving bitrate distribution and so doesn't risk that every High Motion Scene would be that decimated. Sure for a Fight Scene that lasts longer blocking would be deadly but fur such a 1 or 2 second scene as described above it would be marginal if the quality lose is not that big. This would only work in 2 pass tough as you need to analyze for how long heavy motion vectors are in action on screen and then decide in wich scene to take bits away that you then could spend either on High Motion Scenes that are longer on screen or to improve Low Motion scenes (Details) :)

[SealTooGreat]

@foxyshadis,
bpp formula is OK, there's nothing wrong with it. I don't get it, why do you think ABR 1 pass is shit? My size restriction are up to 1.3gb and I do care about quality. I've explained why I use ABR 1-pass over CRF and 2-pass.(slow CPU) What's the problem? :confused:

[akupenguin]

The problem is that comp test + CRF (or even 2pass) is better quality-per-cpu, not just better quality.

[Dark Shikari]

@foxyshadis,
bpp formula is OK, there's nothing wrong with it. I don't get it, why do you think ABR 1 pass is shit? My size restriction are up to 1.3gb and I do care about quality. I've explained why I use ABR 1-pass over CRF and 2-pass.(slow CPU) What's the problem? :confused:
Using Twopass with lower-CPU options is better than onepass ABR with higher-CPU options.

Heck, you can do this:

x264.exe --subme 1 --me dia --pass 1 (other options here)

Its an incredibly fast onepass which takes hardly any time at all, and hardly loses any quality over a higher precision first pass as compared to the quality loss you'd get from using onepass ABR.

[Terranigma]

Has anyone ever compared 3 pass to crf at the same bitrate (via a ssim/psnr test)?

[Dark Shikari]

Has anyone ever compared 3 pass to crf at the same bitrate (via a ssim/psnr test)?
I'll do that now. Results will be done in a bit.

[SealTooGreat]

The problem is that comp test + CRF (or probably even 2pass) is better quality-per-cpu, not just better quality.
No, the problem is ABR/bpp is not bad either. You are talking as ABR/bpp is the worst crap (just a feeling) - I don't have that experience. I am not saying that ABR/bpp is better than CFR/comp_test (which I haven't even tried, yet)

Anywat, as compression test, is there any other beside buzzqw's?

@Dark Shikari
I'll see what I can get from that 1st pass. However, my aim is full encoding below 15h. Will see. thnx

[Dark Shikari]

Source: 300, HD source, resized to 1440x800 from 1080p for faster processing. Scene: Xerxes encounters Leonidas. Mix of a bit of high motion at the start with lots of scene cuts and overall low motion. Has heavy background noise/grain.

Settings: --me hex --b-pyramid --weightb --bframes 16 --ref 4 --b-rdo --subme 6 --trellis 2 --bime --8x8dct --direct auto --partitions all --mixed-refs --deblock 0:0

--CRF 22:
Bitrate: 5177.50 kbps
SSIM: 0.9697870
OPSNR: 41.912

--bitrate 5177 --pass 1:
Bitrate: 5043.73 kbps
SSIM: 0.9686320
OPSNR: 41.699

--bitrate 5177 --pass 3:
Bitrate: 5280.15 kbps
SSIM: 0.9694797
OPSNR: 42.022

--bitrate 5177 --pass 3:
Bitrate: 5282.01 kbps
SSIM: 0.9693321
OPSNR: 42.037

Now that is interesting: CRF easily outperformed 3-pass mode, because on even a 500-frame clip 3-pass was not only unable to hit the target bitrate, but got worse SSIM than CRF even though the bitrate was over the target!

[akupenguin]

@SealTooGreat
The compression test I was referring to is DDogg's (http://forum.doom9.org/showthread.php?t=116773), not buzzqw's.

@Dark Shikari
wtf, abr missed the target bitrate by more than a factor of 3? I have to see this video.

[PuzZLeR]

@PuzZLeR
Ipod have profile restriction. Using ABR is far away form such comparison. ;)Of course iPod has its own restrictions. I was only being fair in that ABR 1-pass has a use after all, that's why I mentioned using it, for example, on an iPod profile.

Actually, alot of those scammy iPod conversion products sold all over the 'Net are crap because they DO use 1-pass ABR. Gee, use MPEG-4 Pt 2 instead and save encoding time.

I guess you can get away with such bad encodes because the screen size is so small and the bad quality won't be as noticable. As well, it's great when you need a fast encode, at a certain size to meet bitrate limitations, and to have it ready for a trip or something in record time. You don't care to archive it, just watch it once or twice then delete it. ABR 1-pass is the BEST for this.

Other than that, I see very little use for ABR 1-pass.

If this is how you make use of H.264, or you have limited resources, you seriously are better off with MPEG-4 Part 2.

[Dark Shikari]

@SealTooGreat
The compression test I was referring to is DDogg's (http://forum.doom9.org/showthread.php?t=116773), not buzzqw's.

@Dark Shikari
wtf, abr missed the target bitrate by more than a factor of 3? I have to see this video.
Oops, mistake in the post. The target bitrate was the bitrate in the first one. I accidentally left the --bitrate note as it was before in the post even though I switched videos, as the first video I was testing had almost constant motion throughout.

[((( atom )))]

uff, i wasn't notified of any answers on this topic since the 1st one.. have to work atm, but from the little i could just read (and think about, recently) i am getting the point with crf. i just have to try and see what it will do with really bad sources..

one thing i still don't get at all: why can i choose a filesize in megui that leads to a bitrate calculation for the second pass? that doesn't make sense to me without knowing anything about the compressibility of my source.

so what i will try is a constant quality encode of maybe 80% first pass size (that's how i'd do it in xvid). so does that make sense and how would i best (and quickest) achieve that?

[check]

The point of constant quality is exactly that -- you will get an exactly known quality :) You don't need to do a first pass, just do a constant quality encode of 19 and it will be as efficient a compression as you are likely to get (give or take 0.5% or so, a high quality two pass encode would be negligibly better).

[Sagekilla]

I have to agree with check.. I've just switched from doing a 2-pass to using CRF and I'm loving it. It's quicker and there really isn't need for fuddling around with how big you need to make it. Unless you're targeting your encodes for saving to a DVD or CD, you're better off using CRF.

[Terranigma]

I once said that crf was superior to 3 passes (old thread (http://forum.doom9.org/showpost.php?p=1000198&postcount=1)), but I never understood how & why. So it's basically frivolous to do 2-3 passes when you can get better quality by using the crf method.
Dark Shikari, if you don't mind, could you do one more test? 2 passes, but first pass using crf then compare to 1 pass crf?

[Dark Shikari]

I once said that crf was superior to 3 passes (old thread (http://forum.doom9.org/showpost.php?p=1000198&postcount=1)), but I never understood how & why. So it's basically frivolous to do 2-3 passes when you can get better quality by using the crf method.
Dark Shikari, if you don't mind, could you do one more test? 2 passes, but first pass using crf then compare to 1 pass crf?
Wait, you mean using CRF for the first pass and then using the second pass with --bitrate... you can do that?

[Terranigma]

Wait, you mean using CRF for the first pass and then using the second pass with --bitrate... you can do that?

Yes. Check my other old thread (http://forum.doom9.org/showthread.php?t=124965)

But if you do commandline encoding without a gui, for the first pass, you'd have it like this:

--pass 1 --crf 20.0


crf can only be used for the first pass though.

[Dark Shikari]

Same as before, --crf 22 --pass 1:
Bitrate: 5177.28 kbps
SSIM: 0.9697865
OPSNR: 41.911

--bitrate 5177 --pass 2
Bitrate: 5321.65 kbps
SSIM: 0.9698064
OPSNR: 42.084

Again, worse, because of the very off-target bitrate.

[((( atom )))]

allright! i did a megui anamorpic encode with crf 18 and i got a superb looking movie wich is around 2 gb with 2 ac3 tracks. so far very very nice!

i am running a comp-check with gk and xvid right now to see how big the movie would have turned out with my old method. to achieve that quality i would have used the mpeg matrix and maybe 1 b-frame. the point about the crf method is really clear now, since the quality will be the same for all my movies. taking that into account filesize really stops to matter...

next i have to dig up some noisy sources to check it out with these.

any special settings for very high quality at still ok filesizes? i guess i will end up with 2 or three profiles for different quality sources, so if anybody has something like that set up, i'd be interested in the used settings..

[PuzZLeR]

Just to comment, I'm in full agreement with check, Sagekilla and Terranigma in posts #39-#41. I'm a fully convinced CRF guy now. All that tinkering with multipass was a habit from DivX and older optical media storage. Passé...

There is very, very, very little difference at the same bitrate between that and 2-pass with x264, and the time you save on encoding is wonderful. I'm happy with every result, because obviously, I get a reliable quality each time. I could care less about the varied file sizes by now. 2-pass is only efficient for exact file sizes, but even that thinking is flawed because you're trying to fit H.264 video content onto media that wasn't made for it in the first place (such as a CD). No point.

From what I have seen in forums all this time, the more experienced encoders "mature into" a quality based workflow in the long run.

Having said that:


any special settings for very high quality at still ok filesizes?CRF again here.

I think your answer would be more in the form of "compression" - a function of quality and file size.

Use a CRF value that you like, such as you say, 18, and stick to it for everything else if from what you percieve is "high quality". It will give you that same "high quality" all the time.

However, use slower settings instead to get the same quality with a smaller file size. The profile "CQ-ASP-Q2" works great. Keep in mind, it will still give you the same exact quality as anything with CRF=18 will, but at a smaller file size (better compression).

[Sagekilla]

Just to comment, I'm in full agreement with check, Sagekilla and Terranigma in posts #39-#41. I'm a fully convinced CRF guy now. All that tinkering with multipass was a habit from DivX and older optical media storage. Passé...

There is very, very, very little difference at the same bitrate between that and 2-pass with x264, and the time you save on encoding is wonderful. I'm happy with every result, because obviously, I get a reliable quality each time. I could care less about the varied file sizes by now. 2-pass is only efficient for exact file sizes, but even that thinking is flawed because you're trying to fit H.264 video content onto media that wasn't made for it in the first place (such as a CD). No point.

From what I have seen in forums all this time, the more experienced encoders "mature into" a quality based workflow in the long run.

Having said that:

CRF again here.

I think your answer would be more in the form of "compression" - a function of quality and file size.

Use a CRF value that you like, such as you say, 18, and stick to it for everything else if from what you percieve is "high quality". It will give you that same "high quality" all the time.

However, use slower settings instead to get the same quality with a smaller file size. The profile "CQ-ASP-Q2" works great. Keep in mind, it will still give you the same exact quality as anything with CRF=18 will, but at a smaller file size (better compression).

Yup. I personally prefer using crf 18 since I like the quality. IMO, anything lower is mostly impossible to perceive at the resolutions I'm encoding at, and the bitrate starts jumping up pretty quickly too.

[akupenguin]

However, use slower settings instead to get the same quality with a smaller file size. The profile "CQ-ASP-Q2" works great. Keep in mind, it will still give you the same exact quality as anything with CRF=18 will, but at a smaller file size (better compression).
Don't stress it quite that much :). It's exact enough so that you can pick one value of CRF and use it everywhere, but not exact enough to let you measure an improvement in compression solely from a change in bitrate.

[PuzZLeR]

@Sagekilla:
For MPEG-2 source, you can't do much better than CRF=18 from my experience. Even though my compression "sweet spot" is 19, 18 is for the VIP content...:)...but to each his/her own right?

@Akupenguin:
Thanks for pointing that out. I'm a theoretical kinda guy in that assumption. :)

Granted - not the exact same quality due to maybe other factors in the encoding process with the slower settings. But if I may get your input for a moment, apart from the obvious smaller file size, does a profile as such affect the quality (in all probability) more than a range of +/-0.5%?

Thanks!

[akupenguin]

Assume one option set is 15% better than another at constant metric quality. Then at constant QP or CRF, 10% of the difference will be reduced bitrate and the other 5% will be increased quality.