View Full Version : 2,4,8,16 modulus
vrpatilisl
27th November 2011, 13:32
hi in Anamorphic customs setting there are 2,4,8,16 modulus . which of them is best, what is different role of them?
talking about handbreak/vidcoder
thanxs
LoRd_MuldeR
27th November 2011, 13:37
A resolution is said to be "modulus X" or "modX", iff the width and height (in pixels) is a multiple of X.
For example, mod16 means that both, the width and height, are multiples of 16.
Most video formats internally work with macroblocks of 16x16 pixels. That's why it sometimes is recommended to encode mod16 resolutions.
Anyway, modern video encoders, such as x264, support non-mod16 resolutions just fine and with minimum overhead...
(Also, if not obvious yet, note that mod16 implies mod8, mod4 and mod2. Mod8 implies mod4 and mod2. And mod4 implies mod2.)
vrpatilisl
27th November 2011, 15:06
Hi, nice explanation no1 given me such nice explanation. I want to ask that is mod means 2x2 macroblock or macroblock are always 16x16 not less than that.
Thanxs
LoRd_MuldeR
27th November 2011, 15:22
For almost any video format commonly used (including h.264) the macroblock size is fixed at 16x16 pixels. Although the encoder may further subdivide the "blocks" into smaller "partitions".
Nevertheless, if the video resolution is not mod16 yet, then the video will be padded to the next mod16 resolution internally. These "additional" pixels will be cropped off again later, i.e. at playback time.
That's why non-mod16 resolutions cause some overhead. You will encode some pixels that you never get to see. But: If the encoder does the padding in a smart way, that overhead is negligible!
To cut a long story short: You shouldn't worry about non-mod16 resolutions too much. Do not resize to a "sub-optimal" resolution, only too make it mod16. Try to avoid resizing altogether, if possible ;)
(BTW: When working in the YUV 4:2:0 (http://en.wikipedia.org/wiki/Chroma_subsampling#Sampling_systems_and_ratios) color-space, which you almost always will do, then the video can only be mod2 or higher. That's because the "raw" pixel data already uses 2x2 blocks)
vrpatilisl
27th November 2011, 15:49
oh thats why you always recomended overcrop to mod 16,cause we wasting our time and some space that our player never gona show us. Still further which is best if i dont want to lose any thing from video.
LoRd_MuldeR
27th November 2011, 16:04
oh thats why you always recomended overcrop to mod 16,cause we wasting our time and some space that our player never gona show us. Still further which is best if i dont want to lose any thing from video.
As said before: Yes, encoding non-mod16 resolutions unavoidably involves some padding. In the worst case, your video is only mod2, so 14 "rows" or "columns" would need to be padded.
But, as also said before, the overhead caused by adding these pixels - measured as "bit cost" - is negligible. That's because the encoder can pad the pixels in a "smart" way in order to minimize the additional bit cost.
So the way to go is: Crop the video as desired. And, if you really have to resize, then simply resize to the desired resolution. If the final outcome is not mod16, don't worry too much about it! :)
LoRd_MuldeR
27th November 2011, 16:29
By the way: x264 used to spit out a warning when encoding non-mod16 resolutions.
At some point this has been removed, because it scared people ;)
commit b1ad8d06bcff3f14ddfc6e550d4d50f2d4847a96 r1306
Author: Jason Garrett-Glaser <darkshikari@gmail.com>
Date: Fri Oct 23 02:34:49 2009 -0700
Remove non-mod16 warning
Compression only "suffers" by an extremely marginal amount and too many people misinterpret the warning.
http://git.videolan.org/gitweb.cgi?p=x264.git;a=commitdiff;h=b1ad8d06bcff3f14ddfc6e550d4d50f2d4847a96;hp=b89ca0413c5a7114111ba0c76bcd7e52eb0ede93
DJ-1
29th October 2015, 22:39
Just to clarify, I thought modulus was based on if resolution H*W (total number of pixels) = if mod evenly divides into it?
Or is it that eg 720=div by mod? & 480=div by mod? 'separately' of each other?
Thanks.
littleD
29th October 2015, 22:54
1. No way
2. Yes, that kind.
vBulletin® v3.8.11, Copyright ©2000-2025, vBulletin Solutions Inc.