GitLab

Problem:

In the new direct VD, we create a SharedImage for the decoded video
frame using the visible size. This is (mostly, see solution below)
correct because we don't want the GPU to sample outside that area
(otherwise, we might get artifacts). However, the coded size of the
VideoFrame sent to the client still contains the non-visible area. This
can cause PaintCanvasVideoRenderer to issue GL commands with incorrect
dimensions thus failing command buffer validation which results in some
videos not being drawn at all on a canvas.

Solution:

The solution implemented by this CL is simple: the coded size of the
VideoFrame that goes out to the client should only include 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 will calculate the UV coordinates to exclude the
non-visible area on the left and on the top of the visible area.

Note that this usable area should also be used to create the SharedImage
because this size is used to import the frame into a graphics API.

Bug: 1092806
Test: tast.video.DrawOnCanvas.* on nami
Change-Id: I25f70a1b21fc9b4ff7037d6fb3b4575ad3dd66e4
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2242834
Commit-Queue: Andres Calderon Jaramillo <andrescj@chromium.org>
Reviewed-by: Miguel Casas <mcasas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#796997}