x264 [warning]: width or height not divisible by 16

[asarian]

I just got this message in my x264 log again:

"x264 [warning]: width or height not divisible by 16 (1080x818), compression will suffer."

I've seen it before, but I'd like to know what it means exactly, 'compression will suffer.' Using CRF, will just the final filesize suffer? Or the quality too? Also, 1080 isn't cleanly divisible by 16, either, of course (1088 is; I guess that's the reason for the whole 8-lines overscan business?).

In my case, am I better off padding the source? Like:

video=AddBorders(video, 0, 7, 0, 7)

To pad the source to 832. Will that make the endresult more efficient?

Thanks

[Audionut]

Discussed before. A few times IIRC.

Use search.

[LoRd_MuldeR]

Video compression uses blocks of 16x16. If the resolution isn't mod16, it will be padded (internally) to the next mod16 resolution and cropped back at playback time.
Hence you pay bits for parts of the image you'll never see. So in CRF mode you have to expect a bigger file, in 2-Pass mode you have to expect worse quality at a given bitrate.
However with x264 the cost for none-mod16 is pretty low. Wouldn't worry too much!

Also: Padding yourself is a bad idea, especially adding black border. x264 will pad it internally in a more "smart" way to keep the additional bit cost small.
Cropping down your source video to the next mod16 resolution would be a good idea though...

[asarian]

Video compression uses blocks of 16x16. If the resolution isn't mod16, it will be padded (internally) to the next mod16 resolution and cropped back at playback time.
Hence you pay bits for parts of the image you'll never see. So in CRF mode you have to expect a bigger file, in 2-Pass mode you have to expect worse quality at a given bitrate.
However with x264 the cost for none-mod16 is pretty low. Wouldn't worry too much!

Also: Padding yourself is a bad idea, especially adding black border. x264 will pad it internally in a more "smart" way to keep the additional bit cost small.
Cropping down your source video to the next mod16 resolution would be a good idea though...

Okay, clear and useful answer. :) Thanks.

[nakTT]

Video compression uses blocks of 16x16. If the resolution isn't mod16, it will be padded (internally) to the next mod16 resolution and cropped back at playback time.
Hence you pay bits for parts of the image you'll never see. So in CRF mode you have to expect a bigger file, in 2-Pass mode you have to expect worse quality at a given bitrate.
However with x264 the cost for none-mod16 is pretty low. Wouldn't worry too much!

Also: Padding yourself is a bad idea, especially adding black border. x264 will pad it internally in a more "smart" way to keep the additional bit cost small.
Cropping down your source video to the next mod16 resolution would be a good idea though...
Anyone know by how much low? Is it < 5%? Or is it < 3%? Or any other figure.

:thanks:

[J_Darnley]

The loss won't be greater than the %age of pixels added. In the OP's example, I would expect the extra pixels to cost him less than than the 2.5% of the picture area they comprise. This is because the padding is just the last row and column duplicated which makes it (somewhat) easy to compress.

The only way to see the cost is to test by over-cropping to a multiple of 16 because there is no way to disable the padding.

[nakTT]

The loss won't be greater than the %age of pixels added. In the OP's example, I would expect the extra pixels to cost him less than than the 2.5% of the picture area they comprise. This is because the padding is just the last row and column duplicated which makes it (somewhat) easy to compress.
I see, thanks mate.

:thanks: