GitLab

Problem:

Videos that are decoded using the new direct VD and that get promoted to
a hardware overlay are displayed with non-visible data. This is because
we currently use the coded size to create the DRM framebuffer.

Solution:

This CL simply makes it so that the DRM framebuffer is created using the
"usable area." For most videos, this is simply the size of the visible
rectangle. However, some H.264 videos specify a visible rectangle that
doesn't start at (0, 0). For these videos, the usable area needs to
include everything from (0, 0) to the bottom-right corner of the visible
rectangle: the client is expected to setup the hardware overlay's crop
rectangle in order to exclude the non-visible area on the left and on
the top of the visible area (this seems to be currently broken though).

This change also means that we need to update the way we detect whether
the frames in the pool have to be re-allocated: if the DRM framebuffer
will change after a configuration change, the frames should be
re-allocated. The unit tests are expanded to more extensively cover this
re-allocation logic.

Bug: b:162880731
Test: video.Contents.h264_360p_hw on nami
Change-Id: I6ed36b9685329fe5f675503c2a9a0b580d6ae696
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2340115
Commit-Queue: Andres Calderon Jaramillo <andrescj@chromium.org>
Reviewed-by: Miguel Casas <mcasas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#799510}