Export video from still image

[eumagga0x2a]

As I said, the only difference was that it was a JPG rather than a PNG, the filters I employed did not change.

Indeed, Avidemux automatically fakes size of loaded JPEG images to make the values even. It doesn't do that for PNG and BMP.

To create the JPG, I merely opened the PNG in Irfanview and then saved it has a 100Q JPG instead, no chroma subsampling.

...which is always converted in Avidemux to 4:2:0.

How can I tell if the resolution was changed? Nothing seems to indicate that it has.

Avidemux prints the complete (or almost complete) x264 configuration, which includes width and height of the input, to the log. Anyway, it is clear now how the things work and why odd dimensions were not a problem with JPEG.

If 1080p is encoded as 1088 for the sake of compressibility, should not all resolutions that are not multiples of 8 be padded first automatically?

Multiples of 16. Yes, indeed, it looks like x264 is doing exactly that, encoding 1280x712 as 1280x720 with the bottom 8 pixels cropped away, so the my claim of adverse effects of a size being not a multiple of 16 is moot.

What kind of padding is applied? I assume it SHOULD duplicate the last line of pixels to achieve that multiple.

Which one? The padding applied by x264? Can't tell without studying the source. Probably zeroed-out memory. The extra line or row resulting from Avidemux making width and height of a loaded JPEG image even contains probably just random noise.

[Cormy1]

In this case, would it be possible for Avidemux to fake PNG dimensions in the future aswell...?
If I have a PNG that isn't a multiple of 16 and want to import it into Avidemux, how should I pad it?

[eumagga0x2a]

Don't pad, add the crop filter (and "add border" if necessary) to the chain instead. Technically it is not mandatory for width and height to be a multiple of 16, they just need to be even, else no joy with x264.