mod16 encode

[egrimisu]

Hi guys,
a simple question: mod16 resoluton are better compressed thn non mod16?
what to use? nonmod16 encode for 700x480 resoution or use a resize to get to 704x480 witch is mod16. Or it does not mater.

Thanks in advance

[roozhou]

Generally it does not matter.
If you pad black bars for mod16, it gives worse compression than non mod16 w/o black bars.

[LoRd_MuldeR]

Hi guys,
a simple question: mod16 resoluton are better compressed thn non mod16?
what to use? nonmod16 encode for 700x480 resoution or use a resize to get to 704x480 witch is mod16. Or it does not mater.

Thanks in advance

If your source is non-mod16, then I'd prefer cropping it down to the next mod16 resolution, instead of resizing. Resizing effects the entire picture and you'll loose sharpness, while cropping effects (removes) only 15 lines/columns at maximum. Anyway, encoding non-mod16 resolutions is perfectly okay. It's not a big deal at all! Internally non-mod16 resolutions will simply be padded (increased) to the next mod16 resolution and those "padding" pixels will be removed at decoding/playback time. So you pay bits for (padding-)pixels that you'll never see. Therefore encoding non-mod16 resolutions (very slightly) hurts compression efficiency. However the padding is done by the encoder in a "smart" way (it does not simply add "black" pixels, which would result in a sharp border), in order to minimize the additional bit cost. Therefore encoding a non-mod16 resolution (and accepting a minimal loss in compression efficiency) may still be preferable over loosing pixels by cropping or even having to resize the entire picture...

[Die*wrek*show]

Is there any type of helper program available that can calculate mod16, mod8 sizes so I don't have to do it manually?

This comes up *ALL THE TIME* for me, more for images but for video as well.

I mean, I'd like to put in the current resolution, and have it give me the next mod16 slot, both up and down. Or maybe generate a full chart, that would be great.

Right now when I need to resize calculations, I use irfan view's resize window with "keep aspect ratio" checked. Entering one half of the rez gives the other, and keeps aspect ratio but that's a clunky way to do it, and a standalone app might have extra features.

[egrimisu]

Thanks you.

It your source is non-mod16, I'd prefer cropping it down to the next mod16 resolution, instead of resizing. Resizing effects the entire picture and you'll loose sharpness, while cropping effects (removes) only 15 lines/columns at maximum. Anyway, encoding non-mod16 resolutions is perfectly okay. It's not a big deal at all! Internally non-mod16 resolutions will simply be padded (increased) to the next mod16 resolution and those "padding" pixels will be removed at decoding/playback time. So you pay bits for (padding-)pixels that you'll never see. Therefore encoding non-mod16 resolutions (very slightly) hurts compression efficiency. However the padding is done by the encoder in a "smart" way (it does not simply add "black" pixels, which would result in a sharp border), in order to minimize the additional bit cost. Therefore encoding a non-mod16 resolution (and accepting a minimal loss in compression efficiency) may still be preferable over loosing pixels by cropping or even having to resize the entire picture...

[ricardo.santos]

Is there any type of helper program available that can calculate mod16, mod8 sizes so I don't have to do it manually?


this is what i use offline:
http://aspect.fre3.com/

theres an online aspect ratio tool here:
http://www.haku.co.uk/ARCT.html

[Die*wrek*show]

Oh cool. Both of those links are just great.

And the online one is 100% ad free! :thanks:

[2Bdecided]

Non-mod2 (!) is often used on web pages embedded in flash. Yet non-mod2 is a disaster in some players / decoders. AVIsynth isn't very happy with it for YUV sources!

Other than that, unless you're encoding postage stamp size (where 15 extra pixels could be a big deal), I think people get too hung up about this - there are some sizes and some aspect ratios where it's painful to comply with mod16. Answer: don't worry about it.

Cheers,
David.

[LoRd_MuldeR]

Yet non-mod2 is a disaster in some players / decoders. AVIsynth isn't very happy with it for YUV sources!

That's because the YV12 (aka YUV 4:2:0) color format, as commonly used with MPEG-2, H.264 and VC-1, can not exists as non-mod2, in consequence of the Chroma Subsampling (http://en.wikipedia.org/wiki/Chroma_subsampling#Sampling_systems_and_ratios) it uses.

[2Bdecided]

Aye, I know ;) But MPEG etc always have mod16 blocks internally, with the actual usable frame size (which can be anything) specified separately. So mod(1) output is fine - but some players still choke on it - presumably because of the order of chroma upsampling and cropping.

Cheers,
David.

[LoRd_MuldeR]

So mod(1) output is fine...

Mod1 output (well, everything is Mod1, so we better say "Non-Mod2" output) is not possible by definition. At least not if the decoder puts out the video in it's "native" color format, i.e. YV12 (YUV 4:2:0).

Of course the decoder could internally upsample the Chroma by converting the video to YUV 4:4:4 or to RGB24 before cropping it down to a Non-Mod2 resolution. But then the output from the decoder can't be YV12 anymore! Also it would imply that the original source wasn't fed into the encoder as YV12 either. Actually it would imply the encoder got the Non-Mod2 source as YUV 4:4:4 and internally converted it to YV12 after padding to Mod16. But then both, the encoder input and the decoder output, would be YUV 4:4:4, which means we actually don't deal with YV12 content anymore.

[2Bdecided]

LoRd_MuldeR, I get all that - but since this is very common in flash videos (x264 internally), obviously(?) they're decoding the "full" DCT image, upsampling the chroma to 4:4:4, and then cropping.

I'd avoid non-mod2, but you can't say it's "not possible" - clearly it is.

(Though I have no idea how to encode it either).

Cheers,
David.