Test: Non-mod16 resolutions and encoding efficiency

[Brother John]

Hey, mates!

I had a little free time and got some testing work done...

With anamorphic MPEG-4 DVD backups there’s frequently a cropping problem. To get one of those nice and clean mod16 resolutions you either have to keep small black bars or crop away a lot of active picture area. For me this happens at least with every second DVD: quite annoying. That’s why I wanted to know: How bad are non-mod16 resolutions really in terms of lost encoding efficiency? And which of the various possibilities should I prefer? Because the only thing floating around is the gut feeling »use mod16 or at least mod8«. The only way to really find out was a test.

It took some time to figure out an appropriate method to calculate the results. If you’re interested and understand German: read this Gleitz thread (http://forum.gleitz.info/showthread.php?t=34216) (including the final results presented here).


== Setup ==

I took five samples from various DVDs. 10000 frames long each in progressive PAL. Encoded to Xvid using Koepi’s Xvid 1.1.2 build with Xvid_Encraw 2007-02-03. Decoding and frameserving by DGDecode 1.4.9 final and AviSynth 2.5.7. Nothing in the scripts but cropping and trimming to exactly 10000 frames.

Hypothesis
Lost efficiency is mainly dependent on the number of pixel lines the encoder has to add internally to reach the next mod16 res. Thus non-mod16s that are only slightly below a mod16 should give best results.

Tested resolutions
References: a properly cropped mod16 resolution and its larger mod16 neighbour (still properly cropped). See below for more details on why two mod16s. Non-mod16: mod8, mod4+, mod4–, mod2+, mod 2–.
Mod8 should be self explanatory. With above hypthesis for mod4 and mod2 two cases each must be taken into account. Mod4+ means a resolution that is 4 pixels larger than mod16 (e.g. 432+4=436): the encoder has to add 12 internal pixel lines. Mod4– means a resolution that is 4 pixels smaller than mod16 (e.g. 432–4=428): this means 4 added internal pixel lines. Same thing for mod2+ and mod2–.

Difficulties
Biggest problem for a test like this are the necessarily different resolutions that make any comparison rather tricky. To keep the differences in picture area small from the start only vertical res was changed. Horizontal res was always fixed to mod16. Also mod2 wouldn’t have been possible to test otherwise because YV12 requires mod4 horizontally.

My idea for further compensating the res difference was this: Take two neighbouring (and both properly cropped) mod16 resolutions and encode them with constant quant (e.g. 704×416 and 704×432).
Assumption: File size difference is due to the 16 added pixel lines.
If you divide the size difference by 16, you get a good idea of how many bytes one line of pixels needs.
Then encode all non-mod16 resolutions so that they have a resolution in between small and large mod16.
Taking the additional pixel lines compared to the small mod16 it is possible to calculate an expected file size for each non-mod16 res.
I chose this approach to avoid simpler calculations that (wrongly) assume a linear connection between resolution and bitrate for the whole frame. My idea limits this assumption to the 16-lines area at the frame edges and starts with a real file size difference. I have no idea if all this is good enough to reliably measure the size of the efficiency loss. But at least it should be enough to get a good idea about how the non-mod16s compare to each other.

Encoder setup
I took Teegedeck’s 58% HQ preset and adjusted it for CQ 3.
xvid_encraw -i "Sample 1 Mod 16.avs" -avi "Sample 1 Mod 16.avi" -cq 3 -qtype 1 -qmatrix C:\Encoding\Matrizen\SixOfNine.xcm -qpel -bquant_ratio 162 -bquant_offset 0 -zones 0,w,1,O -vhqmode 4 -bvhq -progress 25 > "Sample 1 Mod 16.stats"
Note that I switched to VHQ 2 after Sample 1 to speed things up. My computer isn’t the fastest anymore...


== Results ==

First, here is the frame type distribution for each sample. Differences between the resolutions were there, but insignificant.

Sample 1: I 1%, P 35%, B 64%
Sample 3: I 2%, P 42%, B 56%
Sample 4: I 1%, P 43%, B 56%
Sample 5: I 3%, P 65%, B 32%
Sample 6: I 1%, P 47%, B 52%

And now the main calculations. See the explanations below the tables.

http://brother-john.net/files/mod-test_xvid_s1_en.png

http://brother-john.net/files/mod-test_xvid_s3_en.png

http://brother-john.net/files/mod-test_xvid_s4_en.png

http://brother-john.net/files/mod-test_xvid_s5_en.png

http://brother-john.net/files/mod-test_xvid_s6_en.png

Explanations:
Dev. px: Deviation of frame size compared to small mod16.
Size bytes: Actual encoded file size.
Dev. bytes: Raw file size deviation to small mod16.
Dev. ln: Deviation of pixel lines compared to small mod16.
Expected bytes: Expected file size when calculating with the added lines compared to small mod16.
E = small mod16 size + (bytes per line * dev. ln)
exp. %: Expected file size difference in percent compared to small mod16.
real %: Actual file size difference in percent compared to small mod16.
Eff. loss: Lost encoding efficiency calculated as real% – exp%. Note that positive numbers mean lost efficiency and negative numbers mean gained efficiency.
rank: Ranking of non-mod16 resolutions from small to large efficiency loss.


== Discussion ==

There’s a clear tendency:
-> mod2– and mod4– are best
-> mod2+ and mod4+ are worst
-> mod8 is somewhere in between.
This supports the hypothesis that the most important influence on efficiency loss is the number of pixel lines the encoder must add internally. It goes against the usual recommendation: »Use mod16 whenever possible and mod8 if not. Avoid anything else«. The recommendation should rather be: »If mod16 is not possible, try to get as near as possible below mod16.« Because then the encoder has to add only very few internal lines which is good for efficiency.

On the whole efficiency loss seems to be higher for action sequences, or more generally speaking for sequences with a lot of motion throughout the frame. Afaik Xvid just duplicates the last line as often as necessary (correct?). This seems to work better with static frame edges.

Efficiency loss on the whole seems to be acceptable at least for high quality, low quantizer encodings. The loss only once exceeds 4% (S6, mod8). But of course the question arises: how reliably do the number measure the size of the loss?

To be honest: Right now I’m too tangled up in all those numbers to do more serious interpreting. But there’s so many knowledgeable people around the forums that posting this test should definitely help. :)

P.S.1: I attached the OpenDocument spreadsheet with the tables to this post. Don’t know if it’s useful for anyone, but you never know.
P.S.2: I plan to do a similar test with x264. Could be interesting how macroblock partitions affect the results.

[plugh]

Since nobody else has said it...

That's a great bit of work and neat presentation!

:thanks:

[sN1b]

Great job, looking forward to the x264 test.

[akupenguin]

If mod8 doesn't help xvid (which has 8x8 partitions), I don't see how h264's extra partition options could make it any more sensitive.

Some old results from a similar test: graph1 (http://akuvian.org/src/mplayer/lavc_tests/scale_graph1.png), graph2 (http://akuvian.org/src/mplayer/lavc_tests/scale_graph2.png)

Comments on your methodology: you can't just compare bitrate at a constant quantizer, because constant quantizer is not constant quality. If you measured PSNR or some other metric and found it to be not affected by the cropping then say so, but in general it can vary.

[sysKin]

Hi ce work Brother John :)

Hypothesis
Lost efficiency is mainly dependent on the number of pixel lines the encoder has to add internally to reach the next mod16 res. Thus non-mod16s that are only slightly below a mod16 should give best results.

Technically it's something different that matters: how much last row and column of macroblocks is distorted by pixels which encoder had to add. These added pixels are not ignored by motion estimation (or even intra coding, which could be fixed) and therefore entire macroblock is influenced by them, often at the cost of coding the visible pixels correctly.

But your hypothesis is pretty much an equivalent of that.

It goes against the usual recommendation: »Use mod16 whenever possible and mod8 if not. Avoid anything else«.
This recommendation comes from the fact that many video cards fail to render a non-mod8 overlay. I suppose it's not really an issue these days.
There might also be a speed impact from processing data which doesn't fit in mmx blocks (which are 8 bytes wide).

[akupenguin]

What speed impact? Padding the invisible pixels in the encoder? Odd-sized memcpy from the decoder to the video card? I don't see anything that can't be done in mmx.

[Brother John]

@akupenguin
I’m aware that constant quant is not necessarily constant quality. But I’m not measuring quality, just efficiency. The test doesn’t say anything about how those two are connected. That the numbers should be small enough to not affect the quality of an HQ encoding significantly is only a guess. Would you go as far as saying that »the nearer below mod16 the better« can’t be concluded from this test?

Providing some additional metrics shouldn’t be a problem. Is Compare() the proper function for PSNR calculations in AviSynth? Then I could add both PSNR and SSIM to the pile of numbers.

For the x264 test I assume you recommend CRF, don’t you? Gut feeling wants to tell me this should introduce another level of uncertainty. But you’re the expert on x264 and if you say it won’t, that’s good enough for me.

Btw: I got offered help from someone with lots of CPU power. Testing different partition settings (maybe even different number of refs?) shouldn’t be a problem now. :)

@syskin
No, we really don’t need a modern equivalent of the mod32 restriction. I’m confident for the PC, but this could potentially be another one of those standalone problems. Well, at least on my machine with a Radeon 9600 everything works fine. And that’s the only playback device I own.

[Caroliano]

I prefer the quality loss distributed over the whole frame than concentrated on an row or a column. So I wold preffer mod8 over mod2-.