What are the drawbacks of encoding to non-MOD16 resolutions?

[Chainmax]

I am going to start encoding videos to my PSP, most of which are 4:3. Its screen has a 480x272 resolution, but unfortunately 384x288 is not supported yet. Therefore, it seems the choice is either encoding at 320x240 or use a non-MOD16 4:3 resolution.

If I recall correctly, when encoding non-MOD16 the 16x16 blocks get (rendered?encoded?). Is that right? If so, would encoding at, say, 360x272 but assigning it the bitrate of a 384x288 encode be enough or are there more pitfalls to be taken into account?

[Shinigami-Sama]

none mod-16 means that that part of image thats overflowing the macroblock is wasted bitrate

as in

--------------
| |
| |
| |
| |
| | <- end of full mod-16 pixels
| | <- start of partial macoblock
| | <- end of image
|-------------| <- wasted parts of the block = wasted bitrate
|-------------|
|-------------|
|-------------|
---------------

bad example, but thats the easiest way I can think of explain it

also I think its actually mod-8 that you you don't want to go under, atleast for AVC, ASP I'm can't remember if it was 16 or 8

[check]

it's mod16. x264 will pad the video until the dimensions are mod16 if the input is not. Therefore there is a quality loss. With a small video like this, I'd just advise not actually caring about the AR error and encoding to largest supported resolution that is at least mostly close.

[Shinigami-Sama]

it's mod16. x264 will pad the video until the dimensions are mod16 if the input is not. Therefore there is a quality loss. With a small video like this, I'd just advise not actually caring about the AR error and encoding to largest supported resolution that is at least mostly close.

I thought it supported 8x8 4x4 8x4 and 4x8
but those just might be DCT blocks

[Dark Shikari]

I thought it supported 8x8 4x4 8x4 and 4x8
but those just might be DCT blocksThose are partitions; macroblocks are all the same size.

[Shinigami-Sama]

Those are partitions; macroblocks are all the same size.

ahh, thanks for clearing that up

[foxyshadis]

If 8x8 DCT (16x16 chroma) isn't enabled, everything's 4x4 though (8x8 chroma), so only an 8x8 warning would be strictly necessary for main/baseline. Still a good idea to have it, since some players or filters behave badly when given non-mod-16 video.

[akupenguin]

Back in mpeg4asp, mod8 was better than nothing. But with h264's extra partitions and smaller dct and so on, that makes no difference. If you can't get mod16, the only thing that matters is how many pixels the codec has to pad to make mod16. (res%16)==14 is better than (res%16)==8, just because there are fewer wasted pixels, despite the former being only a multiple of 2.

[yesgrey]

Sorry it it's a dumb question, but if I want to convert a MPEG2 HD video using x264, could I use 1920x1080 or should I use 1920x1088?

Thanks.

[hristoff2]

Sorry it it's a dumb question, but if I want to convert a MPEG2 HD video using x264, could I use 1920x1080 or should I use 1920x1088?

Thanks.

At these resolutions you don't need to care.
(x264 will pad it to 1920x1088 anyway)

[Chainmax]

Back in mpeg4asp, mod8 was better than nothing. But with h264's extra partitions and smaller dct and so on, that makes no difference. If you can't get mod16, the only thing that matters is how many pixels the codec has to pad to make mod16. (res%16)==14 is better than (res%16)==8, just because there are fewer wasted pixels, despite the former being only a multiple of 2.

So, for 4:3 content 362x272 would be better than 360x272, right?

[yesgrey]

At these resolutions you don't need to care.
(x264 will pad it to 1920x1088 anyway)

What do you mean with this?
1-x264 uses 1920x1088 internally but create a 1920x1080 file
or
2-x264 creates a 1920x1088 file

Thanks.

[Shinigami-Sama]

What do you mean with this?
1-x264 uses 1920x1088 internally but create a 1920x1080 file
or
2-x264 creates a 1920x1088 file

Thanks.

#2
but its auto-cropped to 1080 by the decoder