0

I’m encoding a set of JPEGs into mp4 by using the MediaCodec API. The photos could have any resolution, but I adjust all photos to be multiple of 16 to ensure they have a compatible size with MediaCodec, and make sure they are within the supported sizes returned by the codec video capabilities.

I’ve found out that in some old devices using the OMX.qcom.video.encoder.avc codec, some resolutions produce garbled videos, as seen in the next samples with different aspect ratios. The problem does not happen when using standard aspect ratios such as 16:9, 4:3, etc, only when using custom ones.

Original

enter image description here

Result

enter image description here

Original

enter image description here

Result

enter image description here

Investigating the issue, I discovered through another user’s question that this could be related to the fact old Qualcomm devices require the Y plane of the YUV data to be aligned at a 2K boundary. But, I’m not working with YUV data at all directly, instead I’m using an Input Surface and rendering through OpenGL.

My guess is that maybe the Codec underlaying system for the Input Surface works anyway with YUV buffers and the Qualcomm codec handles all the conversion, is just a guess. But if so, then, is there any formula I could use to adjust the resolution and align it to such boundary requirement, even if it will produce some cropping? Or if I am misled about my guess, then what could be causing such issue? See the next accepted answer for the statement about the 2K boundary alignment.

How to get stride and Y plane alignment values for MediaCodec encoder

PerracoLabs
  • 16,449
  • 15
  • 74
  • 127
  • I'm having a hard time seeing how the staggering visible in that thumbnail could be caused by a uniform shift in the YUV data. Can you post a full-resolution image? And, how do you know the garbling didn't occur on decode (rather than encode)? – greeble31 Feb 15 '20 at 14:51
  • I've added more image samples to the question. I'm not sure how can I verify if the encoding is done correctly as I'm using an InputSurface to perform the rendering via OpenGL. But I've verified that the image rendered is correct and presents no problems by performing a glReadPixels after the drawing is done. The issue happens only when using custom aspect ratios. When using a standard aspect ratios such as 16:9, 4:3, etc, there is no problem at all. – PerracoLabs Feb 16 '20 at 11:59
  • I figured you had an .mp4 file that you could test in another player. – greeble31 Feb 16 '20 at 15:29
  • Hmm your second two pictures have different dimensions... related? – greeble31 Feb 16 '20 at 15:35
  • Actually are the same dimensions. I took the screenshots from the device and cropped the images just for this question, so to exclude the navigation bar, status bar, etc. I may have missed a couple of pixels when cropping the images. If you mean that have different dimensions from the first 2 images, is only 2 different test with different aspect ratios, to verify that it produces garbled images in any aspect ratio which isn't standard. – PerracoLabs Feb 16 '20 at 18:59

0 Answers0