media/CrOS VD: Create DRM framebuffers using the usable area.
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}
Showing
Please register or sign in to comment