patch: avoid lying about mp4 dimensions

[jicama]

An MP4 file encoded via HandBrake will often have a height or width that's not a multiple of 8, due to automatic cropping.  Using Avidemux 2.6 to cut a section out of such a file results in a blocky section at the bottom and/or right side of the screen that wasn't there in the input.  This turns out to be because even though the MP4 accurately describes its own dimensions, Avidemux is rounding the dimensions up to be a multiple of 8, and so playback needs to guess about what those added pixels might be.

This patch removes that rounding.

[Agent_007]

Bump this thread in next 5 days if nobody comments this thread. (so I remember to ticket this)

[nibbles]

Jicama I thought most codecs and color spaces dealt with 8x8 blocks of pixels, doing math on their similarities, and compressing them.  If you remove part of that 8x8 block, it can't compress along that edge, and the result is undefined.  Did I miss something interesting?

[jicama]

I don't know how the codecs work, but I'd guess that when the size isn't a multiple of 8 they pad out the block with imaginary pixels for compression purposes without changing the reported size.
In any case, HandBrake is perfectly happy to create MP4s with such sizes, and players are happy to show them.

[mean]

i'll merge that when i'm back
thank!

indeed they padd the video

[nibbles]

I'm coming from a point of view where the addition of black borders to fill in a few missing pixels to make the height a multiple of 8 is a poor practice, because it yields a macroblock of 8x8 that contains a solid black bar mixed with normal video.  That doesn't compress well, and the result is chromatic aberration along the edge.

In this, case, what I was thinking about doesn't apply.  Handbrake is cropping at non-multiples of 8 and their encoder is not padding the output.  Avidemux wrongly figures things will be multiples of 8, even though they probably should be.  Thank you for crafting a patch.