GitLab

crrev.com/c/2628069 introduced to the V4L2VideoDecoder a limitation
on the maximum number of decoder instances at a given time, making it
behave like the legacy V4L2VideoDecodeAccelerator.

That provision avoided the OOM observed on MS Teams (see bug). But
the max number of instances (10) is too restrictive. A deeper look
showed that every instance allocates all the necessary input buffers
(i.e. those for the encoded chunks that go into the v4l OUTPUT q).
V4L2VideoDecoder allocates 16 [1] whereas the legacy one only 8 [2].
FTR each buffer is relatively large: 4MB for platforms that support
more than 1080p decoding, 1MB otherwise; MS Teams can successfully
allocate 32 decoders on kukui, which gives us 32 * 16 * 1MB = 512MB
of allocated memory; on trogdor this would be 2GB (!!).

This CL tweaks a bit ToT numbers so we can allocate more decoder
instances (32, good for kukui) and have a smaller number of input
buffers allocated, aligning V4L2VideoDecoder with the legacy.

[1] https://source.chromium.org/chromium/chromium/src/+/master:media/gpu/v4l2/v4l2_video_decoder.cc;l=34;drc=1bba741f920278b78341175ef888c19a6affd664
[2] https://source.chromium.org/chromium/chromium/src/+/master:media/gpu/v4l2/v4l2_video_decode_accelerator.h;l=145;drc=82e2036e3aadce02f587769c7ab6fc644953e008


Bug: b/170870476
Change-Id: If610ffe7c339ae3d883d893e41c92cc725e6fdaf
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2633784Reviewed-by: Fritz Koenig <frkoenig@chromium.org>
Commit-Queue: Miguel Casas <mcasas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#844951}