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.

[PuzZLeR]

Thanks Akupenguin,

Nevertheless, regardless of distribution of benefits, it's clear that you'd, at least arguably, be better off with slower CRF settings than 2-pass in terms of value gained with respect to encoding time. It answers my question and should serve insight to the last question by the OP.

Hail to the x264 quantizer...:)

[SealTooGreat]

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.

You have made me thinking you have never used ABR in your life. Saying how CRF is great especially using 18 for VIP content, you are forgetting to say that ABR 1-pass has switch "--bitrate X" where you can type as much you can like ;)

Encode DVD content using CRF 18, take the info how much bitrate is used, type this value in ABR 1-pass cmd, encode and compare these 2 results, CRF and ABR. Do you think that ABR is bad? Let your eyes be the judge :)

I've never read that someone is openly saying that use CRF 31. According to that I can say CRF is bad, but is not. There is misunderstanding in all this story. Pls, separate words extra, good and shit (especially last 2 ones )

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.
Don't worry. ;)
I'm using both AVC and ASP.

[PuzZLeR]

Hey SealTooGreat,

Well I did do a comparison from CRF's resultant bitrate plugged into ABR 1-pass. Sorry. CRF, according to my eyes, was a considerably higher quality encode.

And yes, CRF=31, in my opinion is crap. But for a DvD type of resolution then so is ABR 1-pass, or ABR 2-pass, at 500kbps - pure crap.

Then again, I do admit, at higher bitrates, there may not be a huge difference between CRF and 1-pass ABR. If you're happy with 1-pass ABR, then by all means, if it serves your purposes then go for it.

And 1-pass ABR does give you the best speed and accuracy in file size, which CAN make it a good option depending on objectives.

To be consistent with the thread's title though "how to predict quality with x264", the encoding of CRF and then using that bitrate into 1-pass ABR would be a terrible idea though IMO, regardless of computing resources or objectives. I certainly hope, and assume, you will not do that.

CRF plugged into 2-pass ABR? We have a great argument. 1-pass ABR? Never.

Just my opinion my friend.:)

[Dark Shikari]

And yes, CRF=31, in my opinion is crap. But for a DvD type of resolution then so is ABR 1-pass, or ABR 2-pass, at 500kbps - pure crap.
Would you like me to upload a clip of my 1280x720 encode of 300 at 775kbps 2-pass ABR? :p

Or link you to my --crf 30 270MB, 50 minute long 720p EVE Online tournament video? :p

(Its weird, I'm obsessed with low file sizes rather than high quality...)

[Sagekilla]

@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?

Yeah, when I played around with the settings 19 is pretty much the sweet spot but I do have the storage space to spare so I shoot for the little extra. Plus most of the movies I'm ripping right now in crf 18 are my favorites. I don't think I'll have enough space to rip my entire collection, so I'm doing my favorites first.

[check]

don't forget you don't need to give integer values, 18.7 is legal, so is 19.65 or whatever :)

[((( atom )))]

si if i understand correctly, i can tweak other settings pretty much for better compression but stay at my crf 18 quality?

which settings are interesting?

doing that would surely make sense for less compressible movies, where my file might end up at 3gb or worse..

also it might be ok, since i have a core 2 quad waiting on my other desk to be tried out for encoding..

[check]

Yes, all the settings now basically just affect compression. This isn't entirely true, but it's pretty close to the truth.
As for interesting settings, read this (http://mewiki.project357.com/wiki/Video_configuration_dialog/X264_Configuration):)

[Dark Shikari]

si if i understand correctly, i can tweak other settings pretty much for better compression but stay at my crf 18 quality?

which settings are interesting?

doing that would surely make sense for less compressible movies, where my file might end up at 3gb or worse..

also it might be ok, since i have a core 2 quad waiting on my other desk to be tried out for encoding..
Some of them lower the bitrate by improving compression efficiency, while others are more likely to raise the quality a bit. Some do a combination. It depends on the situation.

For good quality at a good speed, use --subme 6 --trellis 1 --me hex --b-pyramid --weightb --bime --direct auto --bframes 16 --mixed refs --ref 3 --deblock 0:0 --partitions all --8x8dct and whatever ratecontrol and other options you need.

--subme 7, --me umh, and --no-fast-pskip will each give a 1.5-2% quality-per-bitrate improvement at the cost of a good bit of encoding speed. Raising --ref beyond 3 will help on animated footage.

[microchip8]

I read in the MEncoder manual page that one should not use p4x4 if you deal with big resolutions. I don't know why as they don't explain

if this is true, can someone explain why it "hurts" to use p4x4 on big resolutions?

[akupenguin]

p4x4 doesn't hurt, it just doesn't help. At large resolutions, individual objects in the movie are bigger than 4x4 pixels, so there's no point in partitioning mvs that small. Typically it might be enabled in 0.5% of macroblocks, and improve compression by 0.1%, making it one of the worst compression-per-cpu tradeoffs.

[microchip8]

ahh, now I get it, so what are large resolutions? Are we talking here about the common resolutions of today (720x576 or 720x480) or about the newly introduced HD resolutions 1080p/i, etc and where p4x4 "stops" working?

[akupenguin]

Just a matter of degree, but I don't use p4x4 even at 480p.

[((( atom )))]

so here we go: i just did "cinese box" and it hit 4.7gb for a 90 min movie without audio!
the source is very noisy although rather sharp. it simply contains extreme amounts of filmgrain.

now how could i deal with that best? i would not want to loose either resolution nor the noisy look, but some compromise will have to be made..

any hints?

[check]

you're right, a compromise must be made :) The two variables you are balancing are output filesize, and output quality.
If you want to reduce filesize, you will lose quality, no buts about it. Whether or not this quality loss is visible is another matter again, but in general, the higher the quality loss, the greater the drop in output size. Try these ideas to reduce the filesize:
o reduce resolution
o more heavily filter the clip (you should always do some basic filtering on all videos you encode, it can make a huge different to compressibility for almost no change in quality. I recommend fft3dfilter(sigma=0.3) or so, depending on the individual file. Test with AvsP)
o increase --crf target
o increase x264 quality settings
oo use a lower bitrate CQM. I'd suggest mp4guy's LRM, or possibly his MRM. http://forum.doom9.org/showthread.php?t=117041

If you're looking to

[Dark Shikari]

so here we go: i just did "cinese box" and it hit 4.7gb for a 90 min movie without audio!
the source is very noisy although rather sharp. it simply contains extreme amounts of filmgrain.

now how could i deal with that best? i would not want to loose either resolution nor the noisy look, but some compromise will have to be made..

any hints?
One choice is to remove the noise and re-add noise on playback using a simple filter. Reducing noise can drastically increase compression.

[((( atom )))]

that's no option for me, since i have a linux-player withoug a keyboard, only a remote control. also it is a tiny processor (via) wich can do x264 @ full pal with roundabout 75% load. so no filtering on a per movie basis :(

[Sagekilla]

Some of them lower the bitrate by improving compression efficiency, while others are more likely to raise the quality a bit. Some do a combination. It depends on the situation.

For good quality at a good speed, use --subme 6 --trellis 1 --me hex --b-pyramid --weightb --bime --direct auto --bframes 16 --mixed refs --ref 3 --deblock 0:0 --partitions all --8x8dct and whatever ratecontrol and other options you need.

--subme 7, --me umh, and --no-fast-pskip will each give a 1.5-2% quality-per-bitrate improvement at the cost of a good bit of encoding speed. Raising --ref beyond 3 will help on animated footage.

I was a bit interested in how setting B-Frames to 16 would help any.. I usually use 4 in my encodes with 4 reference frames. My methods may or may not be exactly the best (Someone please correct me in my procedure if you see anything amiss here) but from running 3 different test, with two settings each time I've compiled this much data. All settings listed in the image are the only ones changed. If a setting was unlisted, it meant I didn't use a switch to change it at all.

http://img.photobucket.com/albums/v621/Sagekilla/data.png

What I found to be a bit odd was the encoding speed actually -increased- slightly as I upped the number of B-frames to 16. It wasn't much, but it was fairly consistent in the fact that it did increase. Everything else remained pretty constant, with only a tiny drop in bit rate and corresponding tiny drop in average and global psnr, as well as SSIM.

I have the batch files used for running the encodes as well as the output stats and video files here (http://skdotnet.sytes.net:45312/x264/bframetest) if anyone is interested at taking a look.

[akupenguin]

A B-frame encodes faster than a P-frame, because most of the macroblocks in a B-frame are so obviously skips that it doesn't have to run motion estimation or any other decision.
Using B-frames may or may not be faser than not using B-frames, because B-adapt costs some time too. But if you're using B-adapt anyway, increasing the number of B-frames increases speed.

A B-frame decodes slower than a P-frame, because bidirectional motion compensation has to interpolate twice the samples.

[Sagekilla]

Hmm... gotcha, I guess I'd probably see the performance hit more on higher resolution or more complex scenes though. I just tested the video samples out and with task manager open, and --bframes 16 files seem to be only a bit more intensive then the regular ones.

I'm going to look around and see if I have any fraps recordings left to test this on, those are 1680x1050 native.

[Dark Shikari]

--bframes 16 is basically telling x264 to do whatever it thinks is best. This means that one doesn't have to think "Oh, this is a cartoon, it might need more b-frames": the encoder is just left free to do what it thinks is best.

[MarcioAB]

My 2 cents:

In my tests, for the same bitrate, Constant Quality ( --crf ) outperformed (OPSNR and SSIM) all the other modes.
It was a surprise to me that expected 2-pass should be better, but whatever so: crf rules !

BPP is nothing else than the compression index. I find it a very useful information.

Uncompressed YV12 (4:2:0) is 12 BPP, so a video with 0.20 BPP has a compression index of 60:1 ( 12/0.2 ).

More than sure that BPP is not an absolute value for visual quality but (at least for me) it help a lot:

- x264 videos below 0.16 BPP: high probability that it will suffer visual quality issues (imo).
- x264 videos above 0.20 BPP: high probability I am wasting bitrate.

Composing CRF + BPP + OPSNR + SSIM + your_PoV should give a good perspective.

( PoV = point of view )

[nurbs]

BPP is nothing else than the compression index. I find it a very useful information.

Uncompressed YV12 (4:2:0) is 12 BPP, so a video with 0.20 BPP has a compression index of 60:1 ( 12/0.2 ).

How often do you have an uncompresst YV12 source to work with? Most people here have already compressed sources (mpeg2, avc, vc1).

With enough experience you can estimate what bitrate and thus bpp a given source will need to look good, but it varies to much in my opinion to be any use as a rule of thumb. For instance I have very good quality Futurama encodes at about 0,06 bpp, but if I would try to encode Natural Borne Killers at the same bitrate it would look much worse. I was barely satisfied with 0,24 bpp on that movie.

[SealTooGreat]

How often do you have an uncompresst YV12 source to work with? Most people here have already compressed sources (mpeg2, avc, vc1).

With enough experience you can estimate what bitrate and thus bpp a given source will need to look good, but it varies to much in my opinion to be any use as a rule of thumb. For instance I have very good quality Futurama encodes at about 0,06 bpp, but if I would try to encode Natural Borne Killers at the same bitrate it would look much worse. I was barely satisfied with 0,24 bpp on that movie.

If we want questioning quality factors (CRF quantizer number) I can say I'm satisfied with CRF26 when encoding drama, but with the high motion action movies, 26 gives me worse quality. But it seems the people are rather to use CRF18 and saying how bpp needs balancing ;) If you want ultimate bpp than choose 0.3 and over and don't look back below. I've just encoded small sample (1min52sec) mixed high motion with short slow motion intervals. Qualty factor is 18 (CRF) and MediaInfo reports bpp=0.588 :) funny isn't that bpp enough for eyes's transparency. We are getting paradox - What is better CRF18 or ABR/bpp=0.588 ? As CruNcher says it's all about how you balance it in the end :)

[Plamen234]

that's no option for me, since i have a linux-player withoug a keyboard, only a remote control. also it is a tiny processor (via) wich can do x264 @ full pal with roundabout 75% load. so no filtering on a per movie basis :(

What is your system configuration?
I'm curious about mine...

[foxyshadis]

If we want questioning quality factors (CRF quantizer number) I can say I'm satisfied with CRF26 when encoding drama, but with the high motion action movies, 26 gives me worse quality. But it seems the people are rather to use CRF18 and saying how bpp needs balancing ;) If you want ultimate bpp than choose 0.3 and over and don't look back below. I've just encoded small sample (1min52sec) mixed high motion with short slow motion intervals. Qualty factor is 18 (CRF) and MediaInfo reports bpp=0.588 :) funny isn't that bpp enough for eyes's transparency. We are getting paradox - What is better CRF18 or ABR/bpp=0.588 ? As CruNcher says it's all about how you balance it in the end :)

If you're willing to dump enough bitrate on something to get it below CRF18, of course it's going to look as good or better than CRF18, that's a tautology. Did you check the average quants? You'd almost be better off keeping the original MPEG2 in that case - DVD9s usually have bpps around 1.0, and DVD5s around 0.5-0.6, and if made with a good encoder look about as good as mpeg-4 can most of the time.

BPP doesn't even come close to scaling with resolution - sagittaire conclusively established this years ago. BPP^2 does, sort of. But it's still more of a security blanket than a useful rule of thumb, when it's obvious that .2 bpp gives wildly different results. You can claim that experience gives you the ability to judge, but that can be reversed to experience allowing you to guess the bitrate that comes from a crf - not true in my experience, the codec tends to surprise you more often than not.

Have you actually tried the comp check by DDogg (which selects a quality based on a bitrate) or in automkv (which also selects resolution based on a quality & bitrate)?

[MarcioAB]

How often do you have an uncompresst YV12 source to work with? Most people here have already compressed sources (mpeg2, avc, vc1).
The point (12/BPP=compression ratio) is valid even if the source is already compressed.
(anyway it will be decompressed (uncompressed) in the middle of the process).

With enough experience you can estimate what bitrate and thus bpp ...
My point is the opposite. Example: assume you got the task to compress 1 hour of 1920x1080x60p source. What bitrate will you kick off ? No idea ... But assuming 0.2 BPP you will have a good starting point: the bitrate will be 0.2 x 1920 x 1080 x 60 = 24.88 Mbps, so expect 10.43 GB for the video part.

For instance I have very good quality Futurama encodes at about 0,06 bpp, but if I would try to encode Natural Borne Killers at the same bitrate it would look much worse. I was barely satisfied with 0,24 bpp on that movie.
I do not encode much anime but I think the BPP edges for anime should be lower than other types of movie. So for anime it could be something like this (for example):

- x264 anime videos below 0.060 BPP: high probability that it will suffer visual quality issues.
- x264 anime videos above 0.120 BPP: high probability it will be wasting bitrate.

- x264 extra-action below 0.180 BPP: high probability that it will suffer visual quality issues.
- x264 anime videos above 0.240 BPP: high probability it will be wasting bitrate.

[MarcioAB]

...Qualty factor is 18 (CRF) and MediaInfo reports bpp=0.588 :) funny isn't that bpp enough for eyes's transparency. We are getting paradox - What is better CRF18 or ABR/bpp=0.588 ? As CruNcher says it's all about how you balance it in the end :)

So, CRF 18 gave you 0.588 BPP. I suggest to try a much higher CRF, maybe 28, check the BPP and see if it please your eyes.

Let me suggest an hypothetical example just to exchange ideia:

film1 compressed at CRF 18 give 0.20 BPP and visual quality is good.
film2 compressed at CRF 28 give 0.20 BPP and visual quality is good.

This means film1 is "more compressible" (or "more easy") than film2. Maybe film1 is an anime, or low motion/low light ... does it make sense ?

[Sagekilla]

If we want questioning quality factors (CRF quantizer number) I can say I'm satisfied with CRF26 when encoding drama, but with the high motion action movies, 26 gives me worse quality. But it seems the people are rather to use CRF18 and saying how bpp needs balancing ;) If you want ultimate bpp than choose 0.3 and over and don't look back below. I've just encoded small sample (1min52sec) mixed high motion with short slow motion intervals. Qualty factor is 18 (CRF) and MediaInfo reports bpp=0.588 :) funny isn't that bpp enough for eyes's transparency. We are getting paradox - What is better CRF18 or ABR/bpp=0.588 ? As CruNcher says it's all about how you balance it in the end :)


Well constant rate factor is quite simply that -- constant.. It'll give you constant quality throughout. Even though it may report as being ".588 bpp" that's a global average across the whole video probably and isn't indicative of the bpp across various scenes in the movie. High motion will have higher bpp, low motion will have lower and so forth.

ABR on the other hand, gives you a little leverage to go slightly over or slightly under. But, the problem I see with it is that given a certain bit rate, say 3 mbps, in a low complexity scene it'll end up giving it way too much bit rate than actually needed and you'll have excessive quality. Whereas on a high motion scene it may not be giving enough and you'll start getting some video artifacts. But, like I said before, CRF will just give a uniform quality throughout and there won't ever be that "There's not enough bit rate for this scene" or "There's way too much quality and it's wasting bits in that scene."

'Course that's how it works, if anyone knows that any of that is incorrect feel free to correct me..

@MarcioAB: Your explanation seems a bit backward at the end of your post, I think you mean the other way around.. Lower CRF is higher quality, higher CRF is lower quality, so Film 2 should give better compressability since it doesn't need to use as low of a CRF.

[akupenguin]

ABR on the other hand, gives you a little leverage to go slightly over or slightly under. But, the problem I see with it is that given a certain bit rate, say 3 mbps, in a low complexity scene it'll end up giving it way too much bit rate than actually needed and you'll have excessive quality. Whereas on a high motion scene it may not be giving enough and you'll start getting some video artifacts.
That's CBR (i.e. ABR with one or more of: VBV, low --ratetol, or low --qcomp).
Lax ABR (i.e. --ratetol inf) tries to be CRF. It adjusts the RF value periodically to approximate the given filesize, but only the first few scenes have really variable quality. After that the variations in RF are progressively damped. ABR --ratetol inf still isn't as good as CRF, but there isn't such a huge difference. Otoh, --ratetol inf not only compromises between ABR and CRF in quality, it also compromises in filesize accuracy, being as much as +/-10% off.

[nurbs]

My point is the opposite. Example: assume you got the task to compress 1 hour of 1920x1080x60p source. What bitrate will you kick off ? No idea ... But assuming 0.2 BPP you will have a good starting point: the bitrate will be 0.2 x 1920 x 1080 x 60 = 24.88 Mbps, so expect 10.43 GB for the video part.


I do not encode much anime but I think the BPP edges for anime should be lower than other types of movie. So for anime it could be something like this (for example): ...

That was my point sort of. The bpp value that gives a good quality depends too much on the source to be of much help. Cartoons or stuff with low motion like talkshows or newsbroadcasts need less bitrate while an action movie or a movie from the thirties with the scratches that are common in old films need much more.

Then there is also the resolution that comes into play. The highter the resolution the lower the bitrate you need to get a certain quality. foxyshadis mentioned this thread (http://forum.doom9.org/showthread.php?t=95122) where they talk about this relationship. Also note post number 4 by akupenguin in the linked thread. So while for a given movie 0,2 bpp may be the optimum value at PAL resolution it will still be a waste of bitrate at 1080p.

[MarcioAB]

@MarcioAB: Your explanation seems a bit backward at the end of your post, I think you mean the other way around.. Lower CRF is higher quality, higher CRF is lower quality, so Film 2 should give better compressability since it doesn't need to use as low of a CRF.
Sagekilla, allow me to explain my point using the graphics (made by myself) and explanation below:
http://pws.prserv.net/marcioab/compressibilty.gif
The way I understand it (as a week-end hobbyist) is that CRF could be associated to the "compress force", so high CRF means higher compress force to video data.
BPP could be associated to "the result of such compress action", so high BPP means less compressed result.
Assuming that is correct, then a high compress force (high CRF) resulting in a low compressed file (high BPP) means that such video data has a LOW compression characteristic or that it is more difficult to compress.

This graphic has 3 dimensions. The 3rd dimension is subjective and assume that each pair ( CRF, BPP ) is associated to a film with good visual quality AND near the low-edge. To find the low-edge one should compress the video and check if result is good. Then compress more up to point it became not-so-good. The low-edge is the previous compression level where visual quality is still good.

So, back to film1 and film2:

film1 compressed at CRF 18 give 0.20 BPP and visual quality is good.
film2 compressed at CRF 28 give 0.20 BPP and visual quality is good.

I applied a "low force" into film1 than film2 and both became same size, so film1 is more compressible than film2.

Does it make sense ?
Thank you

[MarcioAB]

...Cartoons or stuff with low motion like talkshows or newsbroadcasts need less bitrate while an action movie or a movie from the thirties with the scratches that are common in old films need much more.
Yes. There may be possible to set some sort of classifications to films and using it plus the pair ( CRF, BPP) get better control. Should not be that difficult ...

Then there is also the resolution that comes into play. The highter the resolution the lower the bitrate ...That is a good point. I already noticed that, but I do not have access to HD source to check by myself. My only exposition to HD was downloading HD trailers (720p, 1080p) and short movies and check visual quality and BPP. I found most of this content at 0.16 BPP but I found visual quality was not good enough to my taste in certain parts (low motion / low light) but than I learn here that this is a very-known MPEG4 issue [ will it be resolved someday? ] and not lack of BPP. So 0.16 BPP seems to be a good spot to HD content as opposed to 0.18~0.20 to SD.

Regard the math in that thread ... interesting, but because we are now in a so much empiric environment, isolate behaviors in ranges/layers ( SD, HD, anime, high-action, dark-film, etc) could be easier to work (IMO).

[MarcioAB]

But, like I said before, CRF will just give a uniform quality throughout and there won't ever be that "There's not enough bit rate for this scene" or "There's way too much quality and it's wasting bits in that scene."
'Course that's how it works, if anyone knows that any of that is incorrect feel free to correct me..


Let me give view on CRF ( fell free to correct me also).

I set a Q target (lets say 20) and let it run. For each block in the frame x264 will kick a Q (lets say from 10 to 30) but in the end the overall frame-mean Q (of all these blocks) will not be much far from my requested Q target (lets say from 14 to 26) and in the end, the overall Q will be very close my requested Q target.

I wonder how x264 with just a single pass can distribute all those Qs in the very best way. Could a 2nd pass CRF-oriented even improve quality ?

[akupenguin]

CRF isn't perfectly optimal, but the optimal algorithm doesn't need 2 passes either. Read up on Lagrange multipliers.

Your graphic shows good ideas, but it's not quite right. The curves should be hyperbolas curving away from the origin and never quite touching the axes, not circles.

[shon3i]

Well 2pass VBR will be i think best rate control :). VBR/CRF 1pass never can give max quality for desired quality level.

[Dark Shikari]

Well 2pass VBR will be i think best rate control :). VBR/CRF 1pass never can give max quality for desired quality level.
But my tests show that CRF yields superior quality to VBR, though not by a gigantic margin.

[shon3i]

You think superior than 2pass ABR because 2pass in x264 (and others) is ABR not VBR ;)

Well quality is probably better on CRF encoding, but what with size? what you can say about size?

For same size 2pass will be better.

IMHO CRF/VBR is more wasting bits, than i get max quality for that size. Aslo is hard to say what quality level is good for some move without some analyses before ;)

I have ability to test VBR mode in Ateme Digital Encoder, and i must say it have some improvements over x264 CRF

[Dark Shikari]

You think superior than 2pass ABR because 2pass in x264 (and others) is ABR not VBR ;)

Well quality is probably better on CRF encoding, but what with size? what you can say about size?

For same size 2pass will be better.
Did you even read my posts? I did a CRF, and then did a 3-pass mode on the exact same bitrate that CRF gave. Not only did ABR fail to converge to that bitrate (it was about 5% over), but the quality was still worse.

And what do you mean by "its VBR, not ABR"? ABR and CRF are both VBR methods.

[Terranigma]

ABR and CRF are both VBR methods.
VBR = a method based on a quality level (so VBR in avc would be -qp and -crf, not abr)
What shon3i was trying to say was that doing 1 pass crf/qp is not using x264 at it's full efficiency, and that doing "1st pass vbr" followed by an additional abr pass would be better.

[microchip8]

doing "1st pass vbr" followed by an additional abr pass would be better.

that's what I always use here. First pass in CRF @ 19, then second pass with a bitrate. Doing only 1-pass CRF encodes is too unpredictable in terms of file size

[RaynQuist]

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!

Lax ABR (i.e. --ratetol inf) tries to be CRF. It adjusts the RF value periodically to approximate the given filesize, but only the first few scenes have really variable quality. After that the variations in RF are progressively damped.

I think that may be a bit of what's happening here. Dark Shikari your 500 frames might not be enough for abr to stabilize, even with 3 passes. On my 20000 frame sample there was not much variance in metrics between crf and all 3 passes. If anything I would say 2nd pass was better than CRF. It's anime though.


bitrate fps avgPSNR glbPSNR SSIM AvgIQP AvgPQP AvgBQP
CRF 20 683.53 8.37 47.690 47.213 0.9866877 17.11 18.84 21.01
1st pass 685.62 8.40 47.765 47.354 0.9872845 18.15 19.91 20.39
2nd pass 684.11 8.44 47.908 47.498 0.9873787 17.49 19.29 20.23
3rd pass 684.03 8.42 47.914 47.508 0.9873756 17.57 19.19 20.24

[Dark Shikari]

I think that may be a bit of what's happening here. Dark Shikari your 500 frames might not be enough for abr to stabilize, even with 3 passes. On my 20000 frame sample there was not much variance in metrics between crf and all 3 passes. If anything I would say 2nd pass was better than CRF. It's anime though.


bitrate fps avgPSNR glbPSNR SSIM AvgIQP AvgPQP AvgBQP
CRF 20 683.53 8.37 47.690 47.213 0.9866877 17.11 18.84 21.01
1st pass 685.62 8.40 47.765 47.354 0.9872845 18.15 19.91 20.39
2nd pass 684.11 8.44 47.908 47.498 0.9873787 17.49 19.29 20.23
3rd pass 684.03 8.42 47.914 47.508 0.9873756 17.57 19.19 20.24

Yeah, I would guess there is a length at which CRF is overtaken by ABR; it would be interesting to test this.

[MarcioAB]

CRF isn't perfectly optimal, but the optimal algorithm doesn't need 2 passes either.
Great. I like mystery :cool:
In the meantime, CRF is the champion (for the same bitrate, sure), not by far, but the champion.

Read up on Lagrange multipliers.Too dense for me (I tried on Wiki and was not able to understand even the "very simple example").

Your graphic shows good ideas, but it's not quite right. The curves should be hyperbolas curving away from the origin and never quite touching the axes, not circles.
Good. I'm interested to improve. If I understood you correctly the graph should be something like the graphic-B ?
http://pws.prserv.net/marcioab/compressibility2.gif
But, I do not agree the graphic-B represent the compressibility, but I like to discuss that.:o

EDIT: 2nd thought: You are very correct !! Great. Thank you.

[MarcioAB]

... If anything I would say 2nd pass was better than CRF. It's anime though.

RaynQuist could you post your command lines ? ( despite I use MeGUI ).

I would like to try it in 20000 frames of my MADAGASCAR video.

Thank you.

[akupenguin]

Good. I'm interested to improve. If I understood you correctly the graph should be something like the graphic-B ?
But, I do not agree the graphic-B represent the compressibility, but I like to discuss that.
Yes.
I am assuming that each line represents one video, and that "complexity" is an inherent property of the content, while the various points on the line come from the user's choice of bitrate/CRF values. Then the shape of the curves can be experimentally determined by encoding at various RFs, it's not up to anyone to decide. I was just telling you the result you'd get if you ran that experiment.
So if graph B doesn't represent complexity, then complexity can't be represented as a function of bitrate and RF.

[MarcioAB]

Yes.
I am assuming that each line represents one video, and that "complexity" is an inherent property of the content, while the various points on the line come from the user's choice of bitrate/CRF values. Then the shape of the curves can be experimentally determined by encoding at various RFs, it's not up to anyone to decide. I was just telling you the result you'd get if you ran that experiment.
So if graph B doesn't represent complexity, then complexity can't be represented as a function of bitrate and RF.

Not sure if I followed you ... but let me explain how I imagine this graph works ( the B one, that you proposed, and I guess is more correct now) :

A person compress a video "near the edge" using CRF and end up with a BPP. With this pair of coordinates (CRF, BPP) this person plot the point in the graph and concludes if the video is highly compressible, mid compressible or low compressible.
The 3 division lines are just for easy "classification" regard compressibility.

Need think how "complexity" relates with "compressibility" ...

[Terranigma]

p4x4 doesn't hurt, it just doesn't help. At large resolutions, individual objects in the movie are bigger than 4x4 pixels, so there's no point in partitioning mvs that small. Typically it might be enabled in 0.5% of macroblocks, and improve compression by 0.1%, making it one of the worst compression-per-cpu tradeoffs.

Well since p4x4 isn't really useful, would you say that an AVC Level of 4.1 is just as good, or almost as good as unrestricted?

With megui, these are the maximum settings I was able to use with a profile level of 4.1 without p4x4

--pass 3 --bitrate 100000 --stats ".stats" --level 4.1 --ref 16 --mixed-refs --no-fast-pskip --bframes 16 --b-pyramid --b-rdo --bime --weightb --direct auto --filter -3,-3 --subme 7 --trellis 2 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --vbv-maxrate 50000 --b-bias 40 --me esa --merange 64 --threads auto --thread-input --cqmfile "Prestige CQM.cfg" --progress --no-dct-decimate --output ""ReallyInsaneSettings.mkv""

Of course i'd never use such settings, but I am quite curious as to what you think :cool:

[akupenguin]

@MarcioAB
In case it isn't obvious why graph A is ridiculous:
It says that lossless compression at 0.3 bpp is low compressibility? As is CRF28 at 0 kbps?

@Terranigma
There's no difference between 4.1 and 5.1 with regard to p4x4. Both forbid it. (To be precise: both forbid using p4x4 in all partitions of a macroblock at once, and I haven't bothered to support limited use of it.) There isn't any level that's a strict superset of all other levels.
I normally consider bitrate, vbv, dpb, and resolution to be the only important parts of level and ignore the rest, that's why I say 5.1 is the closest to unrestricted. But there are some other features that can only be enabled on lower levels.

[RaynQuist]

RaynQuist could you post your command lines ? ( despite I use MeGUI ).

I would like to try it in 20000 frames of my MADAGASCAR video.

Thank you.

--keyint 480 --min-keyint 12 --ref 16 --mixed-refs --no-fast-pskip --bframes 16 --b-pyramid --b-rdo --bime --weightb --direct auto --filter 1,1 --subme 7 --trellis 2 --analyse all --8x8dct --vbv-maxrate 25000 --me umh --merange 32 --threads auto --thread-input --progress --aq-strength 0.7

[MarcioAB]

@MarcioAB
In case it isn't obvious why graph A is ridiculous:
It says that lossless compression at 0.3 bpp is low compressibility? As is CRF28 at 0 kbps?

Humm, that open up another perspective (example):

Assuming lossless compression is represented by CRF=0 (the X-axis), then assume a lossless compression of film1 will get 2.0 BPP and a lossless compression of film2 will get 5.0 BPP.

We can say that film1 is High Compressible but film2 is Low compressible. So, the division curves should touch the X-axis.

On the other side, anything finishing near 0 BPP is very-High compressible, so the High/Mid division curve must be asymptote to Y-axis like this graph.
Does it make sense ?

http://pws.prserv.net/marcioab/compressibility3.gif

EDIT: The division curves are asymptote to X-axis on CRF=0, but maybe Lossless is something higher than 0, lets say CRF=5 and that is the reason why the division curves touch the "X-axis" (so the X-axis in fact is CRF=5). Make sense ?

[nurbs]

The division curves are asymptote to X-axis on CRF=0, but maybe Lossless is something higher than 0, lets say CRF=5 and that is the reason why the division curves touch the "X-axis" (so the X-axis in fact is CRF=5). Make sense ?

I think if you enter crf 0 it automatically encodes constant quantizer. Only 0 can be lossless in AVC.

[foxyshadis]

that's what I always use here. First pass in CRF @ 19, then second pass with a bitrate. Doing only 1-pass CRF encodes is too unpredictable in terms of file size

In that case you could probably save yourself a lot of time by first running DDogg's tool to see how large CRF 19 is likely to be.

Of course, if you run it while you're asleep or at work, it really doesn't matter how much time is 'wasted'.

[mitsubishi]

Of course, if you run it while you're asleep or at work, it really doesn't matter how much time is 'wasted'.

Hmm time maybe, but wasting all that energy on a regular basis will make Al Gore cry.

[jellysandwich]

In that case you could probably save yourself a lot of time by first running DDogg's tool to see how large CRF 19 is likely to be.

Of course, if you run it while you're asleep or at work, it really doesn't matter how much time is 'wasted'.

little lost here, but where might i find ddoggs tool?

[SealTooGreat]

That's CBR (i.e. ABR with one or more of: VBV, low --ratetol, or low --qcomp).
Lax ABR (i.e. --ratetol inf) tries to be CRF. It adjusts the RF value periodically to approximate the given filesize, but only the first few scenes have really variable quality. After that the variations in RF are progressively damped. ABR --ratetol inf still isn't as good as CRF, but there isn't such a huge difference. Otoh, --ratetol inf not only compromises between ABR and CRF in quality, it also compromises in filesize accuracy, being as much as +/-10% off.
Could you explain how does ABR --ratetol behave with low/mid values?

[microchip8]

In that case you could probably save yourself a lot of time by first running DDogg's tool to see how large CRF 19 is likely to be.

Of course, if you run it while you're asleep or at work, it really doesn't matter how much time is 'wasted'.

Well, I don't think there's DDogg for Linux and I haven't used Windows in over 6 years now (I also don't have XP here).

As I wrote somewhere else in another thread, I want to be able to squeeze up to 5 (usually 4) encodes on one 4.7 GB disc (still don't have a dual-layer DVD here) and I usually scale down my DVDs to 624x384 or 608x384, and use as bitrate for the second pass somewhere between 1050 and 1150 kbps

Only a few days ago, I encoded Sin City (the Uncut version) with a bitrate of 1060 kbps (2-pass encoding) and I couldn't tell the difference between the DVD and the encoding. For me, always doing a 1-pass CRF encoding is just too unpredictable when you want to take file size into account

[foxyshadis]

little lost here, but where might i find ddoggs tool?

This thread (http://forum.doom9.org/showthread.php?t=116773), tyee's tool (http://tplay.lunarpages.net/tiny/eFLiN) is near the end of it. (Several versions throughout the thread.)

froggy, if you almost always end up doing two pass, why not use a normal turbo first pass instead? Or if you use crf to proportion out the bitrate each movie is going to have, you can still get as good of an estimate using 5% and often even 2% of a movie, as outlined above. If Delphi works on wine, that gui might. Admittedly, if not, it'd probably be too much trouble to work the results out manually each time.

[microchip8]

@foxyshadis

I always do turbo=2 for the first pass, it takes me about 30-50 minutes (depending on the movie) to finish the first pass. The second pass, again depending on the movie, takes ~3-4 hours to finish, which is acceptable for me

I guess me always doing a 2-pass encoding has also to do with my mindset, since I'm accustomed to do a 2-pass encoding when I used Xvid in the past (and I used it for many years). At the moment, I'm happy with a 2-pass encode for H.264 so there's no real need for me to change anything :)

[foxyshadis]

No, I totally agree with you that 2-pass is the best way to reliably maximize the quality in a restricted space, like dvds. I just misunderstood and thought you were doing a full, not fast first pass. Sorry!

[MarcioAB]

How to predict quality using x264 ?

Just one idea based on the graph below:

http://pws.prserv.net/marcioab/compressibility4.gif

workflow: (just one idea, no tested at all)

1. encode film with any reasonable CRF and find BPP.
2. Plot this (CRF, BPP) pair in the graph.
3. By this point, plot your film curve, parallel to the guide curves (division curves)
4. Find your new (CRF, BPP) pair, more or less in the middle of the good-quality "work area".
5. You have BPP for the size estimation and CRF for the encode.

Obs: This graph has just example values. Need to collect as many (CRF, BPP) pairs as possible to make a real one.

[MarcioAB]

A graph comparing 3 films:

- Signs (Mel Gibson): the film I found to be most compressible.
- Casablanca (black&white): the film I found to be less compressible.
- Madagascar (anime): To compare with Signs.

The black rectangle is the point where I found image quality became bad for my taste.

http://pws.prserv.net/marcioab/compress2.png

Graph is an open source application found here (http://www.padowan.dk/graph/)
The graph data I used can be found here (http://pws.prserv.net/marcioab/crf.grf)

"Quick and dirt" encodes with MeGUI ( --crf nn --analyse none)
First 3000 frames of each film, right after the credits.

"Quick and dirt" Avisynth script like:
LoadPlugin("d:\PRGM\DGDecode\DGDecode.dll")
MPEG2Source("VTS.d2v").trim(4086,7085)

One can check his values against those in the graph using "Insert a point series".

Any comparison is welcome. I learn here that "Bad Boys 2" is also a low compression film but I do not have it (would be nice to check if it is even lower than Casablanca).

[MarcioAB]

Comparing const-Quality (--crf) with const-Quantizer (--qp) both in the same bitrate (or BPP) regard exponential-SSIM ( 100^SSIM, kind of zoom over SSIM )

http://pws.prserv.net/marcioab/ssim.png

"Quick and dirt" encodes of "Signs" film (3000 frames), but the same parms for both modes.

For this case, --CRF is much better than --QP in lower bitrates and trending to became equal at high bitrates.

[MarcioAB]

Another view (closer to the central "work area") using CRF 21 and 0.2 BPP as axis.
Included an interlaced film (The Promise): Reasonable fast action but I guess the reason for such low compressibility (even with --interlaced parm) is the interlace itself.

The pair (CFR=21, BPP=x) with subme=5 (to be faster) seems to be good to identify the relative compressibility between films.

http://pws.prserv.net/marcioab/compress3.png

[MarcioAB]

http://pws.prserv.net/marcioab/ssim_bpp1.png

A better view, now SSIM in Y and BPP in X and each discrete point correspond to an integer CRF.
The limit in the right (higher CRFs) are where x264 BPP match the original film BPP. In the left is the behavior near the "work area".
The more toward left the CRFs are, the more compressible is the film.
The smaller the distance between CRFs in the same curve, the better the quality is retained during compress.

"Eragon" is a very compressible film and retain quality during compress.
"Promess" has low compression and does not retain very well quality during compression.
"Casablanca" is bit more compressive than "Promess" but also does not retain quality during compression as "Promess".
"Signs" (movie) and "Madagascar" (anime) behave very much similar.

A close look into the graph varying x264 parms reveal some interisting points (next post).

Marcio

[MarcioAB]

http://pws.prserv.net/marcioab/ssim_bpp2.png

The 2 blue curves are "extrema" compressions of the same film (Eragon in the case).
The higher is using the Insane profile (adjusted to CRF) and the lower using the default profile (almost no parms).
The process speed for the higher curve was near 8 fps and for the lower 60 fps. Quality (SSIM) and compression (BPP) are in the graph.

Varying x264 parms it is possible to find parallel curves between these 2 with corresponding speeds. Follow the most significants (displayed in the graph):

1) Insane profile with subme 6, ref 3, bframes 3: speed 15 fps and quality/compression close to full-insame.

2) Insane profile with subme 6, ref 1, bframes 3: speed 19 fps and quality/compression close to (1).

3) Insane profile with subme 5, ref 2, bframes 3: speed 24 fps and quality/compression close to (2).

4) Insane profile with subme 5, ref 1, bframes 1: speed 30 fps and quality/compression close to (3).

5) subme 5, ref 1, bframes 1 --analyse p8x8,b8x8,i8x8 --8x8dct: speed 43 fps and quality/compression close to (4).

6) subme 5, ref 1, bframes 1 --analyse i4x4 --8x8dct: speed 51 and quality/compression not so close to (5).

I tested dozens of other combinations an check them against the graph and the profile above are the best. Look forward to see if I forgot something.

obs: as CRF increase the speed reduce somehow in all curves.

Next task is to proof (or not) how much and where CRF is better than 2-pass.

Marcio

[MarcioAB]

http://pws.prserv.net/marcioab/signs.png

oPSNR and SSIM comparison of CRF, Qp, 2Pass and 1Pass with low compression (almost no parms) and medium compression (Insane profile with subme 5, ref 1, bframes 1) over 3000 frames of SIGNS. Obs: SSIM was scaled to 60-380(1-SSIM) to fit near oPSNR in the graph.

Recomendations:

Low bitrate = up to 0.2 BPP for lite compression parms or 0.15 BPP for heavy compression parms
CRF is better (SSIM: constant higher and oPSNR: equal Qp).
obs for 2Pass: SSIM in the middle and oPSNR lower than all.

Medium bitrate = from Low bitrate up to 0.4 BPP
CRF better on lower edge and Qp better on higher edge.

CRF: SSIM: from higher to equal. oPSNR: from equal to lower.
Qp: SSIM: from lower to equal. oPSNR: from equal to higher.
2Pass: SSIM: same as Qp. oPSNR: lower than all.

High bitrate = from Medium bitrate up to 1 BPP
Qp is better (SSIM: equal for all and oPSNR constant higher than CRF)
obs for 2Pass: oPSNR from lower to equal Qp

Very High bitrate = above 1 BPP
Qp or 2Pass ( SSIM and oPSNR are almost equals)
obs for CRF: not available.

[Manao]

oPSNR and SSIM aren't suited to compare different rate control algorithm. They should only be used to compare short sequences.

[MarcioAB]

oPSNR and SSIM aren't suited to compare different rate control algorithm.They should only be used to compare short sequences.

The way I understood H264 so far is that in the end it is the selection of coefficients (Q) to be used to squeeze the difference between the real frame and the (motion) estimated frame.

So for the exactly same short sequence (as is the case), the comparison should be how much oPSNR+SSIM varies regarding the chosen Q selections (made by the Rate Control in some caser or by myself in others) and the efficiency of the (motion) estimation engine.

I would like to further understand why oPSNR+SSIM can not be used to compare different Rate Controls.

Thank you

[Manao]

It can't be used to compare rate controls because neither PSNR nor SSIM have an absolute meaning. For example, PSNR 42 doesn't amount to the same quality for two different sequences. So, when merging PSNR/SSIM scores of two different sequences ( which you do when you compute PSNR/SSIM of a whole movie ), you end up with a number that has lost almost its meaning.

[MarcioAB]

If I correctly understood, the issue is to use PSNR/SSIM to analyze more then 1 "sequence" ? In my case the extracted segment is only 3000 frames long, but for sure there are many "sequences" there.

But then, if analyzing "merged sequences" with PSNR/SSIM is the issue, it will be an issue even if analyzing it with just one single Rate Control.

So, when to use PSNR/SSIM ?

Thank you.

[Manao]

With a single rate control, i.e if you test quality settings, it's possible to use a whole video, because usually those settings have the same effect on the PSNR/SSIM of all the frames. So, for example, if you compare subme 5 with subme 7, you'll see that the PSNR of all the sequences of your video raises by something like 0.2/0.3 dB, and so the single PSNR figure you get at the end also raises by 0.2/0.3 dB.

However, if you were playing with a setting that would raise the quality of some scene, and reduce the quality of others, it would not be good to use PSNR/SSIM. With x264, such settings are all related to rate control.

Said otherwise, if you consider a video made with two sequences. With constant quantizer, the first one gets a PSNR of 42 and the second a PSNR of 41. With a CRF encoding, the PSNRs are 43 and 40.5 ( for the same size ). Can you say which rate control is the best ?

BTW, the same happen on single frames whenever you use adaptive quantization. That can be seen as a rate control algorithm on a single frame, and it tends systematically to lower the PSNR, while drastically improving the visual quality. That's another case where PSNR/SSIM are ill suited.

[MarcioAB]

Can you say which rate control is the best ?
Thank you to point that. You are all correct.
Btw, a superficial analysis on 3000-frames sequence (SIGNS) processed with 3 rate controls (Qp, CRF and 2Pass) with almost same resulted bitrate, almost same mean PSNR, with low motion (in the begining) and high motion (in the end), indicated better PSNR results for Qp in the high motion scenes and better PSNR results for CRF / 2Passes in the low motion scenes.

BTW, the same happen on single frames whenever you use adaptive quantization. That can be seen as a rate control algorithm on a single frame, and it tends systematically to lower the PSNR, while drastically improving the visual quality. That's another case where PSNR/SSIM are ill suited.

May I ask how to use "adaptive quantization" ? (in MeGUI ?).

Thank you.

[Manao]

May I ask how to use "adaptive quantization" ? (in MeGUI ?).You need a build of x264 with the adaptive quantization patch. There are plently of such builds available ( check the sticky )
indicated better PSNR results for Qp in the high motion scenes and better PSNR results for CRF / 2Passes in the low motion scenes.And that is normal, for two reasons :
- the human vision system is less sensitive to details/artifacts in high motion scenes, so it makes sense to reduce their quality
- slightly degrading a very complex scene allows to improve a lot of simple scenes ( because complex scenes have a high bitrate, hence degrading slightly their quality still gives a lot of bitrate to play with in comparison to the bitrate of the simple scenes ).

[Nikos]

From wiki:
SSIM (Structural SIMilarity)
The Structural SIMilarity (SSIM) index is a method for measuring the similarity between two images. The SSIM index is a full reference metric, in other words, the measuring of image quality based on an initial uncompressed or distortion-free image as reference.
The SSIM index is a decimal value between 0 and 1.
0 would mean zero correlation with the original image, and
1 means the exact same image.
0.95 SSIM, for example, would imply half as much variation from the original image as 0.90 SSIM. Through this index, image and video compression methods can be effectively compared.

Is there a mathematical formula to associate SSIM values and quality variation?
For example if i have 0.88 and 0.82 SSIM values what's the difference in quality?

[Manao]

No.

Metrics such a PSNR / SSIM are mostly relevant when used on short sequences. You should try to get, for two different settings, the same PSNR or SSIM. The two settings will have a different bitrate, and the difference between those two bitrate is the only objective figure that has a meaning. 10% more quality means nothing, while 10% less bitrate does mean something.

[Nikos]

Thanks Manao for the reply, you are clear about relevant.
According to wiki:
0.95 SSIM, for example, would imply half as much variation from the original image as 0.90 SSIM
my question is:
0.88 SSIM, for example, would imply ??? as much variation from the original image as 0.82 SSIM.

[akupenguin]

0.88 SSIM, for example, would imply ??? as much variation from the original image as 0.82 SSIM.
It doesn't matter. Sure you can look at the formula for SSIM and say that 0.88 is X times as much variation than 0.82, but what would you do with that result? All you need to know about SSIM is that higher scores are better. Any quantitative comparison should be phrased in units of bitrate, not units of SSIM. Furthermore, you can't derive a change in bitrate from a change in SSIM, because that mapping is not always the same for different video content and different codecs. At best you could come up with a formula specific to some types of content and one codec, and develop an intuition for when to trust it.

[MarcioAB]

And that is normal, for two reasons
I see ... I just proved to myself that America was discovered.

Still intrigued regard those metrics, follow a graph:
http://pws.prserv.net/marcioab/ssim_psnr_frame.png

Horiz is the frames, Vert is SSIM(CRF-Qp) is red and PSNR(CRF-Qp) in blue, scaled to better view.
They both seems similar, despite PSNR seems to be more focused in luminance (dark and light) and SSIM seems to add motion on top that.

Visually inspecting the videos is difficult to judge where each scene is better/worst.
By far the most annoying issue to me is the blockness that seems none of these metrics (PSNR or SSIM) can caught/consider.

[akupenguin]

And that is normal, for two reasons :
- the human vision system is less sensitive to details/artifacts in high motion scenes, so it makes sense to reduce their quality
- slightly degrading a very complex scene allows to improve a lot of simple scenes ( because complex scenes have a high bitrate, hence degrading slightly their quality still gives a lot of bitrate to play with in comparison to the bitrate of the simple scenes ).
More precisely, it's normal because it's what CRF/2pass explicitly try to do. The above reasons are why I wrote it that way.
(Clarifying because otherwise a reader might think that x264 has some generic optimization algorithm that only usually gives such a result.)

[Nikos]

Thanks akupenguin for the useful reply.
I want to know the SSIM formula just because i am a physicist, but i can't find it.

If i want to compare same video, same codec, same bitrate with different settings, the SSIM value does have any meaning?

[akupenguin]

If i want to compare same video, same codec, same bitrate with different settings, the SSIM value does have any meaning?
Yes, but only insofar as it is an approximation of the real experiment, which is: same video, same codec, same SSIM, different settings (but same ratecontrol method), and measure bitrate.

You may ask, how do I pick a SSIM and measure bitrate when x264 has a --bitrate but not a --ssim? Encode at 2 or more bitrates/qps/crfs bracketing your target SSIM value, and interpolate between them. You can save some cpu time at the expense of approximation and complexity, by making multiple encodes for a few of the settings, then fitting your SSIM->bitrate predictor function to those results, then encode the rest of the settings at just one bitrate each and extrapolate their bitrate at the target SSIM.
On the other hand, you can spend some extra cpu time to simplify the process and provide a more complete picture, in the form of an RD plot: Encode each setting at several different bitrates, plot the SSIM vs bitrate of all encodes with a curve between the points of a given setting, and the distance between the curves is the relative goodness of the settings.

I want to know the SSIM formula just because i am a physicist, but i can't find it.
from http://www.cns.nyu.edu/~zwang/files/papers/ssim.html
http://akuvian.org/images/ssim_eqn.png
The equation is defined for a window of a few pixels (originally a gaussian weighted window, but we use unweighted 8x8 blocks because its faster). The SSIM score of an image is the average of the scores of all possible windows in the image.
x and y are the windows in the two frames to be compared.
mu_x is the average pixel value in window x.
sigma_x is the standard deviation of pixel values in window x.
sigma_xy is the covarience.
C1=1e-4 and C2=9e-4 if pixel values are normalized to the range [0,1].

[Nikos]

Thank you very much akupenguin, i feel happy.
I will follow your tips in my experiments encodes.

[Dark Shikari]

By far the most annoying issue to me is the blockness that seems none of these metrics (PSNR or SSIM) can caught/consider.
Use a blocking metric then. MSU's Video Quality program (freeware) has a blocking metric.

[MarcioAB]

Use a blocking metric then. MSU's Video Quality program (freeware) has a blocking metric.

I'm using the MSU tool for PSNR and SSIM frame-by-frame measures, but the "MSU Blocking (MPEG-4) BETA" results does not align even close to my perception of blocky.

To better view the blocks, I'm scaling gamma with avisynth "Levels(0, 2, 255, 0, 255)". To match the same blockness of the source MPEG-2 (in the dark and low motion areas of course) I need almost double the bitrate in x264. I know it is a known issue of x264 ... maybe someday.

[Dark Shikari]

I'm using the MSU tool for PSNR and SSIM frame-by-frame measures, but the "MSU Blocking (MPEG-4) BETA" results does not align even close to my perception of blocky.

To better view the blocks, I'm scaling gamma with avisynth "Levels(0, 2, 255, 0, 255)". To match the same blockness of the source MPEG-2 (in the dark and low motion areas of course) I need almost double the bitrate in x264. I know it is a known issue of x264 ... maybe someday.
Use AQ if you have issues with blocking...

[mav1]

What are you think about this profile for test compression bitrate?

"x264.exe" --qp 18 --bframes 3 --b-pyramid --direct auto --filter -2,-1 --subme 1 --partitions none --me dia --threads auto --thread-input --sar 1:1 --progress --no-psnr --no-ssim --output "file.mkv" "file.avs" --aq-strength 0.5

[Blue_MiSfit]

thread-ro-mancy!

Also, if you're going to post settings, don't post them like that. Post them in the form of a command line!

~MiSfit