"width or height not divisible by 16, compression will suffer" -- should I worry?

[Morte66]

I've been running some encodes from 1080p lately and seeing a lot of this x264 warning. I've always added 8 lines of black to placate it. Lately, I've seen a few posts that "sort of maybe" imply that if I feed x264 a 1080 line file it will pad it internally, and crop its internal version to give me back a 1080 line encode. In other words, it might not matter.

My display is 1920x1200, so 1088 is ok right now. But I'd quite like to make 1080 line encodes to reduce possible compatibility issues in future, e.g. if I get some sort of 1080p home theatre display.

So, could you x264 experts give us the benefit of your wisdom on this?

[nm]

I've been running some encodes from 1080p lately and seeing a lot of this x264 warning. I've always added 8 lines of black to placate it. Lately, I've seen a few posts that "sort of maybe" imply that if I feed x264 a 1080 line file it will pad it internally, and crop its internal version to give me back a 1080 line encode. In other words, it might not matter.
That's right. By adding black padding, you're actually just making things worse.

[bond]

the 1080 source is actually also 1088 with fake 8 pixels added at the bottom, which get removed by the decoder

[lovelove]

so the bottom line is ... either ignore the warning or crop accordingly, right?
and why is 1080p so popular if it's no divisible by 16 and therefore a bad choice compression-wise ?

[tph]

so the bottom line is ... either ignore the warning or crop accordingly, right?
and why is 1080p so popular if it's no divisible by 16 and therefore a bad choice compression-wise ?
The warning was removed a while ago because it was confusing. x264 will pad the video to mod16 internally anyway by copying the last row of pixels (and setting crop flags in the header so that your video player will not display them at playback). The bits wasted on those padded rows is very small compared to the rest of the video so just ignore it.

But yes, designing a digital video standard that is not evenly divisible by the most common macroblock size was a bit stupid.

[lovelove]

thank you for your information.

The warning was removed a while ago because it was confusing.
sorry, I missed that. My x264 just told me "width or height not divisible by 2" so I was sure that "by 16" would still exist, too.

But yes, designing a digital video standard that is not evenly divisible by the most common macroblock size was a bit stupid.
thanks for confirming.

The bits wasted on those padded rows is very small compared to the rest of the video so just ignore it. If you don't care about the cropped (lost) pixels, then I guess cropping to mod16 would be better compression-wise than keeping the odd resolution, right?

[lovelove]

Oddly enough, I found only a single thread on doom9 for "width or height not divisible by 2".
Several answers were given there, but my instinct tells me that crop by 1 pixel would still be the best solution, right ?

[tph]

If you don't care about the cropped (lost) pixels, then I guess cropping to mod16 would be better compression-wise than keeping the odd resolution, right?
Correct, but the difference is small.

my instinct tells me that crop by 1 pixel would still be the best solution, right ?
Yes.

[lovelove]

many thanks

[mariush]

I think x264 duplicates the last horizontal line 8 times or as much as it needs to get a multiple of 16, it doesn't add black pixels as these would hurt compression more than just duplicating lines.

With some material (the Home (http://www.youtube.com/watch?v=jqxENMKaeCU) documentary but 1080p) using MPC-HC and DXVA decoder those 8 duplicated lines of pixels were visible and a bit annoying. With recent 1080p this no longer happens so it may have been a video driver issue.

[Underground78]

With some material (the Home (http://www.youtube.com/watch?v=jqxENMKaeCU) documentary but 1080p) using MPC-HC and DXVA decoder those 8 duplicated lines of pixels were visible and a bit annoying. With recent 1080p this no longer happens so it may have been a video driver issue.

Something likes that have already been reported to mpc-hc devs : http://sourceforge.net/apps/trac/mpc-hc/ticket/77 ...

[JohnPeterson]

using MPC-HC and DXVA decoder those 8 duplicated lines of pixels were visible and a bit annoying.

The same thing happen in the latest mpc-hc 2010 revision too with all outputs except VMR-9. But VMR-9 (windowed) produce major tearing in both windowed and fullscreen mode and I also feel that VMR-9 (renderless) gives occasional tearing both in window and fullscreen mode. But other than that I have no problems with it. And I can control its color settings from the nvidia control panel. The most important thing is to get the full 0-255 color range so that you can get real black and real white.