GitLab

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}