resolution vs quality, which to choose?

[sysKin]

Originally Posted by Teegedeck

That doesn't really belong in this thread but use the SixOfNine CQM and set motion search precision to '4' and VHQ to '3'

What a weird setting. VHQ looses its primary effect if you disable INTER4V motion mode, which is what you do at motion precision 4 and lower.

[Teegedeck]

Yes, lowering efficiency is exactly the desired effect. It helps exceptionally much with source material that 'hides' detail in noise or exhibits very little actual detail but only noise (which you want to keep in order to create the illusion of detail) and/or has low contrasts.

Didée once sent me a PM where he theorized on it; perhaps I can find it and retell/translate some of it.

Edit: My conversation with Didée was about reducing the floating walls effect really, but from what I found optimized motion vectors also hurt perceived detail in mildly noisy, scarcely detailed, typically low-contrast sources. Sources that look 'flat'.

OK, here we go. This is not a literal translation in all parts, I'm just rephrasing some thoughts and mixing them with my own comments:

The combination of ME=4 and VHQ=3 seems contradictory at first because ME=4 means inter4v is deactivated but the general idea is to let 'normal' ME only search for vectors for 16x16 blocks. Afterwards VHQ should only try to refine 8x8 blocks within the absolute positions that the 16x16 blocks have been assigned to. So hopefully halfpel and qpel refinements should not lead to a visible 'floating' effect because the 16x16 blocks should stay fixed.

Maybe it doesn't work that way, but the effect certainly looks good.

One could also forego inter4v for sure by using ME=4, VHQ=2. Which should preserve noise even better but it's really a matter of diskspace. Still, because 'flat' movies are generally very compressible lowering motion search precision and VHQ are meaningful ways to enhance quality under such circumstances.

The general idea is that as soon as noise is dominant the search for efficient vectors should be given up and simple and 'safe' vectors should be used instead and more bits used for storing texture information.

This is meant to tackle the infamous floating-walls effect: Starting at VHQ=3 extented searches for 8x8 DCT blocks are performed and when XviD tries to optimize 8x8 blocks those blocks will get shifted back and forth till they are optimally 'aligned' with the noise. In flat areas noise is the dominant component of the picture signal and thus the most effcient encode is not what the human visual system likes.

[loro]

thanks for the hint tegedeck, I will try this as soon as I can

[Blue_MiSfit]

@teegedeck

While I agree that formulas are a waste of time, bits/(pixel*frame) is not a totally useless figure. It can give you a VAGUE idea, provided you have seen a bit of the source. If you have a super clean awesome source, then you will PROBABLY be correct in assuming that ~.250 should make it look REASONABLY good. If you have a really filthy source, you can assume that more will be needed

That's the number I usually shoot for, at least - when I was doing non full resolution backups.

Now I always simply overcrop the mattes to get mod16 and maintain AR as much as possible, then encode full resolution anamorphic, targeting 1/4 -> 3/4 DVD+R depending on how much space I need to do the job right.

[Teegedeck]

Well, I think that the formula doesn't even make for a vague guess. Let me try to put it like this:

The formula is based on the assumption that at a fixed quantizer, every movie produces the same bitrate for the same duration at the same resolution at the same number of frames/second.

This basic assumption is obviously not true.

And that would settle the whole argument right at the start. But let me get into more detail.

The assumption would only hold true if it really was the same movie every time, only varying in duration and fps. But as we know, movies not only differ in content, they differ in how postproduction is handled, the lighting differs, the sets of MPEG-2 custom quantization matrices that were used on the movie differ etc.

Thus the different 1st-pass filesizes of the hypothetical 'average' movie can not be attributed to their different durations - and duration is the only relevant source-dependant variable that actually changes the result of your calculation if you use the formula.

When I say 'average' movie I'm talking about the group of movies you get most often; they would come out, if you use a constant quantizer 3 with the SixOfNine matrix (my standard first-pass setup), at around 1200 - 1800 MB. (Batman Begins and The last Samurai are two examples.) For these movies the formula would be useless for determining the 'ideal' resolution because their different compressibility does not (only) depend on the duration, but still suggestions on a resolution based upon the result of using the formula would probably be sane. (Though, usually, a ridiculously small resolution is chosen based upon the result.)

Then there's the next group of movies that would yield a result at constant quant=3 (SixOfNine) of above 2 GB. (Kingdom of Heaven, Domino...). Such filesizes are by about half larger than the most common group of movies I mentioned above. So in such cases the formula is not only useless but the resulting suggested resolution based upon it would no longer be sane.

And then we have a group of movies that come out unsuspectedly big (like Sin City or War of the Worlds or one about some Penguins marching through a predominantly white landscape...); i. e. might be somewhere between 3200 and 3600 MB. Now, such filesizes are more than a 100% off the assumptions that the formula is based upon, and they are not that uncommon. And you cannot tell whether you've got one of those type of movies before you have made a compressibility check. So here the formula goes not only completely useless but any suggestions for a resolution based upon it will be utterly wrong.

To summ it up: You can not base your decisions on this formula. The formula only gives you the false feeling that you know what you're doing when you're actually making a blind guess. This formula is more like a chant. Snakeoil.

So if you have decided that you will stick with full resolution anyway, what do you use a misleading formula for? You could rather do a filesize prediction with Enc at your preferred setup (constant quantizer) and see whether a 1/4 DVD-R will do or whether you'll have to go for 3/4 DVD-R. It only takes a couple of minutes. And the result is realiable.

Edit: I also implicitly assume something: that quantizer somehow equals quality which is not strictly true but mostly. Putting aside the topic of CQMs at the moment.

[sterlina]

Originally Posted by cool9

You say quality goes up with decreased resolution but details are lost. Isn't quality synonomous with details? Or with compressibility?

yes, that was exactly the question: if small-size have less details but you can encode it better, whereas big-size have much more details but (for fixed bitrate) you cannot encode them all.


I'll try some encoding. My settings:
movie: Arsenio Lupen, chapter 12
software: StaxRip, VirtualDub 1.6.15 (build 24442), XviD 1.1.0, DGIndex 1.8.4b3
type: two pass encoding
bitrate: 1000, 1500, 2000

below the avisynth scripts:

no resize, crop mod16: 704*432
pixel aspect ratio (Xvid Configuration tab) is set to 16/9 PAL

MPEG2Source("D:\Arsenio Lupin\test\VTS_01_1.d2v",info=3)
ColorMatrix(hints=true)
Crop(8,72,-8,-72)

anamorphic resize: 704*288
the crop is done as to have better aspect ratio: 0.21%

MPEG2Source("D:\Arsenio Lupin\test\VTS_01_1.d2v",info=3)
ColorMatrix(hints=true)
Crop(4,76,-4,-76)
BicubicResize(704,288,0,0.5)

anamorphic resize: 640*272
the crop is done as to have better aspect ratio: 0.23%

MPEG2Source("D:\Arsenio Lupin\test\VTS_01_1.d2v",info=3)
ColorMatrix(hints=true)
Crop(14,74,-14,-74)
BicubicResize(640,272,0,0.5)

anamorphic resize: 576*272
the crop is done as to have better aspect ratio: -0.03%

MPEG2Source("D:\Arsenio Lupin\test\VTS_01_1.d2v",info=3)
ColorMatrix(hints=true)
Crop(8,74,-8,-74)
BicubicResize(576,240,0,0.5)

Just wait a couple of days for results... If someone tell me where I can upload some images I'll put them

[Blue_MiSfit]

@teegedeck

Pwn3d. *bows humbly*

Very good points indeed.

~MiSfit

[weaver4]

Ok, here is what I do.

Since I am going to watch the movie on a standard TV I set the horizonal resolution to 640. I set the decoder to a single pass and set the quantizer to 3 for XviD or 4 for DivX. This gives me great results most of the time. Sometimes I am a little shocked by the filesize (like Casablanca) and I will decide if the movie is really worth that many bits, and downsize it if I need to.

See; if you got a movie that has three old women sitting around a table and talking for two hours there are not many bits that change from frame to frame so none of the bits/pixel or kb/s algorthims work for the movie. But take a race-car movie where the background is constantly changing much more bits are needed. So I got tired of trying to figure it out and decided to let the Codec do it.

[Blue_MiSfit]

anything over 512 for horizontal res. I've found to be more than adequate for SDTV over S-Video.

However, these look simply DREADFUL when blown up to 1280 on my CRT, even with Lanczos4. Cant wait until we all have true 720p rips....

[sterlina]

I've finished all 12 compressions. It hasn't take too much, because the chapter lenght 8:29 long, but it was me that hasn't much time...

first thing: compression time. As virtualDub tells only minutes (Job Control Tab) I cannot said how much seconds, minutes only. To be clear, a time of 1:59 minutes became 1 minute, not 2

on my PC (AthlonXP 2400+, 1Gb ram) first pass takes 7 minutes for the first clip (not resized), 8 minutes for all others. So, resizing take more CPU work that a larger image.

that was inverted in second pass: 10 minutes for 704*432 clip, 8 for both 704*288 and 640*272, 7 for 576*272.

Conclusion: first pass takes a bit longer when the clip is resized, but overall compression speed is incrased for lower frame size. I think it is not surprising for everyone, just reporting.


next step: quality

[sterlina]

note: I've choosed Arsenio Lupen chapter 12 because it is well balanced: about a third slow motion and very lighty, followed by an explosion with lots of debris (many details!!), ending more dark, slow motion again.

<someone can tell me where I can upload some images? thanks>

edit:
another request: I'm using VirtualDub, but it doen't say if a frame is a B-frame or I-frame, just K-frames are differenciated. Is there another software that tells me that?



@weaver4
Even if you don't care about filesize a quantizer 3, if I have well understand formulas (the ones Teegedeck hates ) is equal to a "66% quality".
IMHO it is much better to encode two pass 66% quality, you get avarage of quantizer 3 but better balanced for high motion/slow motion scenes.

[Lenny_Nero]

Originally Posted by sterlina

that is interesting and "new" for me, how to calculate "quality". Maybe I had just to read the forum

I have been doing nothing other than reading this forum for over two months and I 'still' have so much more to learn.

[foxyshadis]

sterlina, look at virtualdub.jobs in the vdub folder, it records exactly how long the operation took. Decoding can be a bit tricky though - the two hex numbers have to be joined, subtracted, and converted to decimal with 64-bit arithmetic (windows calc works), then divided by 10 million to get # seconds. (fun!)

avidemux might tell you the real frame type; if not, streameye will, but it's expensive demoware (and bugware).

[weaver4]

Originally Posted by sterlina

@weaver4
Even if you don't care about filesize a quantizer 3, if I have well understand formulas (the ones Teegedeck hates ) is equal to a "66% quality".
IMHO it is much better to encode two pass 66% quality, you get avarage of quantizer 3 but better balanced for high motion/slow motion scenes.

Constant Quality is just that; it uses whatever bits it needs to maintain the quality that you select. So for high motion scenes it uses many more bits than what is needed for low motion scenes. So changing the quantizer is not needed and not prefered. (It will be intresting on what others say about this.)

[sterlina]

TIMING test: I will encode the video again, to be sure not work with computer while encoding... that will make some better timing results

QUALITY TEST (middle bitrate: 1500)
I've watch all four encoding (and whatched and watched some parts of them ) with real time resizing: width resolution (video, not screen) of 1024 and 800.

I found very hard to see differences in high-motion scenes. There are, but all four seems to be good enough for watching (well, I was watching for a short time, maybe a whole movie is different).
There is, instead, a big difference in low-motion scenes. The 576*272 width loose really lot of details and the image look as it it was too much softed. 704*432 and 704*288 looks very good, the first one slightly better but I could spot it only sopping video and looking at still images.

I've tryed to ask my brother, without telling him what were the sources (as I sayd, all was resized) and he is same advice,
704*432 and 704*288 are better than others.


So, for now it seems (to me ) that resolution is better than "quality factor", I mean, with same bitrate the full resolution (with a lower "quality factor") is better that a small resized one (wich has a better "quality factor").


One bad thing: cpu usage while decoding is *a lot* more with bigger sized videos!

I'll have also a look to 2000 bitrate and 1000 bitrate, and encoding timing also.

[xyloy]

with 1500 kbps, XviD sure looks great. No need for a reduced ~75/80% Width resolution such as 576*xxx.

It's at ~800 kbps that the situation is different.

[Teegedeck]

Please; no meaningless bitrate figures. 1500 kbps might be too little, more than enough, or just the right bitrate depending on the source.

Though you are of course right with the general tendency of 'XviD is not good for 1-Cd encodings at full resolution'. I'd sign that sentence.

[xyloy]

I know that my post is only meaningful in this thread's context, of course

I should have said "with 1500 kbps, XviD sure looks great at full DVD resolution"
"It's at approximately 800 kbps that XviD v1.1 starts to be not good at full DVD resolution".
Are you happier dear Teegedeck ? :P

(just kidding ^_^)

[Teegedeck]

/radiant with joy

[sterlina]

Originally Posted by xyloy

with 1500 kbps, XviD sure looks great. No need for a reduced ~75/80% Width resolution such as 576*xxx.

It's at ~800 kbps that the situation is different.

you're probably true, but I was testing for middle,middle-high bitrate. I'll do some encoding at low-bitrate, let say... 800