-
Hirokazu Honda authored
An encoder driver may expect extra data size between planes in an input buffer. We currently don't use width and height adjusted by the driver, but a large-enough width and height computed from the buffer size in bytes. Therefore, a VEA client is asked to allocate a larger width/height buffer in the case. A backend for graphics buffer allocation (e.g. minigbm) is able to allocate a buffer that has extra data properly from width and height adjusted by the encoder driver. A client using a backend like minigbm wrongly allocates a buffer unexpected by the encoder driver due to a large width and height requested by VEA. ARC++ encoder hits this issue. This CL resolves the issue by requesting width and height adjusted by the encoder driver if native_input_mode, that is, a client will feed a buffer allocated by a backend like minigbm. Bug: b:144135251 Test: ARC++ encoder on kukui Change-Id: I5bfbd0169bbff2ad3801a4561d546fbfe290902d Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1906864Reviewed-by:
Alexandre Courbot <acourbot@chromium.org> Commit-Queue: Hirokazu Honda <hiroh@chromium.org> Cr-Commit-Position: refs/heads/master@{#714802}
76866c76