It won't accept odd input widths or heights - throws an OMX_BadParameter. I'm surprised that the cropping won't either though since the pixel data is technically there, just has to be pulled out of a subsampled region. It seems like it should be able to handle odd sizes though if the stride or slice height is bigger. I had a few jpegs with that case and I just round up the dimension and recrop it after a color space conversion. If the output is an odd size it didn't through an error but the last column had issues. Seems like the output port should reflect the smaller dimension but it didn't seem to do that. Wonder if it checked the output dimension against the RGB color format output I'm using but the actual resize operation operates on the input color format.
My initial test photos were 3024x4032, 4592x3448 or a rotation of one of those two. It was just an album mix from my iPhone and a Sony camera. Later I pulled a bunch from wikimedia commons to try and break it. I ended up doing a decode component, followed by a 1:1 resize to convert to RGB then a resize with whatever scaling and cropping that needs to be done. Eventually I should tunnel those but for now I have them setup as classes handing buffers off to each other trying to catch errors and debug as much as possible. That seemed to have really good results as far as handling most jpegs and crop sizes I threw at it.