View Full Version : Resizing and Mod16
rtjnyoface
18th September 2009, 05:20
I've completed a search for specifics but found relatively little. First, when is it appropriate to resize? From what I've read you aren't supposed to if you have a pure source such as a dvd as it will interfere with the quality of the encode.
Secondly (and stupidly), does mod16 essentially mean that it must be divisible by 16 (i.e. when cropping say...48 it's divided by 16 three times?)
Please, for those of you who see this as a pointless, nooberific question I did try the search function. Even the megui guide doesn't give an answer to what I'm asking.
creamyhorror
18th September 2009, 07:16
Resizing degrades image quality, generally (leaving aside whole-number resize ratios).
If you're encoding DVD sources with x264, you should probably not resize. Just make sure you crop off all the black borders as well as any dirty or darkened rows of pixels, then encode.
Secondly (and stupidly), does mod16 essentially mean that it must be divisible by 16 (i.e. when cropping say...48 it's divided by 16 three times?)
You should not go by cropping, but by the resulting resolution. A resolution is mod16 if both the height and width are wholly divisible by 16. 720x480, 720x576, 1280x720, 1920x1080, 640x480 are all mod16.
mod16 resolutions are the most efficient to encode at with x264, but there's no real point resizing specifically to reach them.
(x264 actually pads the frame to reach a mod16 resolution, but you don't see the padding during playback. The padding is very efficient, probably more efficient than plain black borders.)
roozhou
18th September 2009, 07:23
720x480, 720x576, 1280x720, 1920x1080, 640x480 are all mod16.
1080 / 16 = 67.5
juGGaKNot
18th September 2009, 07:42
I use
LoadPlugin("autocrop.dll")
AutoCrop(0, 16, 16, threshold=0)
cuz i encode to divx264 to and its mod8 only
setarip_old
18th September 2009, 08:03
@rtjnyofaceSecondly (and stupidly), does mod16 essentially mean that it must be divisible by 16Yes.
And as far as searching, look for the full word, "modulo"...
10L23r
18th September 2009, 08:07
@creamy I thought x264 used black borders to pad.
for the most part, upsizing before encoding is a waste.
downsizing is mostly used when filesize or CPU resources is limited. however this is becoming less popular as both hardware and software improve.
roozhou
18th September 2009, 09:10
I thought x264 used black borders to pad.
x264 uses last row/column to pad.
Gavino
18th September 2009, 14:12
Resizing degrades image quality, generally (leaving aside whole-number resize ratios).
When resizing with Avisynth's built-in resizers (which maintain the position of the image centre), only odd-number resize ratios preserve quality (in the sense of being losslessly reversible). For all other ratios, some blending of the original pixels is required.
noee
18th September 2009, 15:15
I hope this isn't OT, but if I have a DVD SD source (720x480, movie AR=2.35) and I issue this to crop the top and bottom borders:
LanczosResize(720,352,0,62,-0,-66)
Is it true that because after the crop, the movie dimensions equal my resize dimensions, that there will actually not be a resize in this case?
Keiyakusha
18th September 2009, 15:39
I hope this isn't OT, but if I have a DVD SD source (720x480, movie AR=2.35) and I issue this to crop the top and bottom borders:
LanczosResize(720,352,0,62,-0,-66)
Is it true that because after the crop, the movie dimensions equal my resize dimensions, that there will actually not be a resize in this case?
Not really understand what do you mean, but you resizing to 720x352, which is not 2.35. Should be something like 720x306, or 720x304 (mod16)
Gavino
18th September 2009, 17:28
Is it true that because after the crop, the movie dimensions equal my resize dimensions, that there will actually not be a resize in this case?
That's correct - what you have written is completely equivalent to Crop(0,62,-0,-66) (and is internally implemented this way), since this directly gives a resolution of 720x352, needing no resizing.
(As Keiyakusha points out, this is not 2.35:1, but the answer to your actual question is "Yes".)
noee
18th September 2009, 18:05
Thank you, that is what I thought, but I needed verification and yes, my mistake, the movie is actually 2.42.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.