Mattijs Korpershoek authored 4 months ago and Vishal Mahaveer committed 4 months ago

See: 64021a2e ("TI: add DMABUF_CARVEOUT custom allocator support for decoder")

Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Signed-off-by: Guillaume La Roque <glaroque@baylibre.com>

Mattijs Korpershoek authored 4 months ago and Vishal Mahaveer committed 4 months ago

In 48 bits mode, the wave5 video decoder/encoder has a hardware limitation:

For each memory access, the upper 16 bits of the 48 bit address *must* be
identical.

In order to enforce this addressing limitation, we can use a different dmabuf
heap, named carveout[1].

Add support for the carveout heap allocator in plugin_store and make sure that
this allocator is used by default for all input buffers.

Note: the output allocator still uses gralloc.
This requires a custom gralloc implementation which uses the carveout heap
whenever the GRALLOC_USAGE_HW_VIDEO_{DECODER,ENCODER} flags are used.

To tell the c2 framework that this allocator is available, make sure to set the
c2-poolmask property:

    debug.stagefright.c2-poolmask=0x1f50000

(DMABUF_CARVEOUT is bit 24)

[1] https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/drivers/dma-buf/heaps/carveout-heap.c?h=ti-linux-6.1.y


Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Signed-off-by: Guillaume La Roque <glaroque@baylibre.com>

The client can crash the V4L2EncodeComponent by passing an input with
one buffer where buffer==nullptr:

F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
F DEBUG   : Build fingerprint: 'TI/am62p/am62p:14/UQ1A.240105.002/eng.mkorpe.20240325.115051:userdebug/test-keys'
F DEBUG   : Revision: '0'
F DEBUG   : ABI: 'arm64'
F DEBUG   : Timestamp: 2024-04-09 07:53:02.494446645+0000
F DEBUG   : Process uptime: 8s
F DEBUG   : Cmdline: /vendor/bin/hw/android.hardware.media.c2@1.0-service-v4l2
F DEBUG   : pid: 4949, tid: 4955, name: V4L2EncodeCompo  >>> /vendor/bin/hw/android.hardware.media.c2@1.0-service-v4l2 <<<
F DEBUG   : uid: 1013
F DEBUG   : tagged_addr_ctrl: 0000000000000001 (PR_TAGGED_ADDR_ENABLE)
F DEBUG   : signal 0 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr --------
F DEBUG   : Cause: null pointer dereference
F DEBUG   :     x0  0000000000000000  x1  b400007acbed72e8  x2  b400007a3beda7f0  x3  0000000000000010
F DEBUG   :     x4  020000797bedb2c0  x5  b400007a2bed1878  x6  0000000000000001  x7  7f7f7f7f7f7fff7f
F DEBUG   :     x8  00000078e68d0710  x9  b40000795bed9990  x10 b40000795bed99a0  x11 0000000000000003
F DEBUG   :     x12 0000000000000000  x13 0000000000000004  x14 0000000000000276  x15 0000000000000000
F DEBUG   :     x16 0000007b7c1eac60  x17 0000007b80a6c770  x18 00000078e5aa2000  x19 b400007a0bede5a0
F DEBUG   :     x20 00000078e68d07e0  x21 0000000000000000  x22 0000000000000000  x23 b400007a9bed6210
F DEBUG   :     x24 0000000000000000  x25 00000078e68d1000  x26 0000000000000002  x27 0000007b8a387b88
F DEBUG   :     x28 00000000000fc000  x29 00000078e68d0680
F DEBUG   :     lr  0000007b7c1cbb20  sp  00000078e68d0680  pc  0000007b80a6c778  pst 0000000080000000
F DEBUG   : 12 total frames
F DEBUG   : backtrace:
F DEBUG   :       #00 pc 0000000000069778  /vendor/lib64/libcodec2_vndk.so (C2Buffer::data() const+8) (BuildId: 1d42f8105aac0515945328329706c2e1)
F DEBUG   :       #01 pc 0000000000042b1c  /vendor/lib64/libv4l2_codec2_components.so (android::V4L2EncodeComponent::queueTask(std::__1::unique_ptr<C2Work, std::__1::default_delete<C2Work> >)+348) (BuildId: 2f6128320f05c503e8ee6dc9e05df980)
F DEBUG   :       #02 pc 00000000000470a8  /vendor/lib64/libv4l2_codec2_components.so (base::internal::Invoker<base::internal::BindState<void (android::V4L2EncodeComponent::*)(std::__1::unique_ptr<C2Work, std::__1::default_delete<C2Work> >), base::WeakPtr<android::V4L2EncodeComponent>, std::__1::unique_ptr<C2Work, std::__1::default_delete<C2Work> > >, void ()>::RunOnce(base::internal::BindStateBase*)+120) (BuildId: 2f6128320f05c503e8ee6dc9e05df980)
F DEBUG   :       #03 pc 00000000000acca0  /vendor/lib64/libchrome.so (base::debug::TaskAnnotator::RunTask(char const*, base::PendingTask*)+192) (BuildId: 87e214635dddac0ae594ee401576361a)
F DEBUG   :       #04 pc 00000000000cc9ac  /vendor/lib64/libchrome.so (base::MessageLoop::RunTask(base::PendingTask*)+348) (BuildId: 87e214635dddac0ae594ee401576361a)
F DEBUG   :       #05 pc 00000000000ccd84  /vendor/lib64/libchrome.so (base::MessageLoop::DoWork()+468) (BuildId: 87e214635dddac0ae594ee401576361a)
F DEBUG   :       #06 pc 00000000000ce080  /vendor/lib64/libchrome.so (base::MessagePumpDefault::Run(base::MessagePump::Delegate*)+96) (BuildId: 87e214635dddac0ae594ee401576361a)
F DEBUG   :       #07 pc 00000000000f1fec  /vendor/lib64/libchrome.so (base::RunLoop::Run()+60) (BuildId: 87e214635dddac0ae594ee401576361a)
F DEBUG   :       #08 pc 0000000000111e88  /vendor/lib64/libchrome.so (base::Thread::ThreadMain()+392) (BuildId: 87e214635dddac0ae594ee401576361a)
F DEBUG   :       #09 pc 000000000010f040  /vendor/lib64/libchrome.so (base::(anonymous namespace)::ThreadFunc(void*)+128) (BuildId: 87e214635dddac0ae594ee401576361a)
F DEBUG   :       #10 pc 00000000000d6fb0  /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+208) (BuildId: 218db69eb66aeb253a34d956906a8bba)
F DEBUG   :       #11 pc 000000000006ad90  /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64) (BuildId: 218db69eb66aeb253a34d956906a8bba)

This is tested by VtsHalMediaC2V1_0TargetComponentTest#testInputBuffer().

Fix this by guarding against this condition, as done in SimpleC2Component[1]

[1] https://android.googlesource.com/platform/frameworks/av/+/refs/heads/main/media/codec2/components/base/SimpleC2Component.cpp#1141


Test: atest VtsHalMediaC2V1_0TargetComponentTest
Change-Id: I407f8f7fb420bd993a665c0a7cb10ad1e224d0fb
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>

Right now, the reset() operation just calls stop().

When a client calls stop() followed by reset(), reset() returns a
C2_BAD_STATE error. (since we are already STOPPED).

According to the framework documentation (C2Component.h), reset can *only*
return C2_BAD_STATE when the component is in release state.

Test if we are already STOPPPED and if so, do a no-op by returning C2_OK.

Test: atest VtsHalMediaC2V1_0TargetComponentTest
Change-Id: I4095c0a9db43a017d3476224d33534748e2251f5
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>

The user app can provide buffers to the encoder directly via MediaCodec
API (queueInputBuffer) or via InputSurface.

In case the input surface is used, the timestamps of the encoded frames
are automatically generated, as they're being considered as a real-time
traffic (for example - from screen capture session or the camera input).

Also the Component is supposed to dynamically adjust the framerate based
on the input frames timestamps (see b/192419592).

The dynamic framerate calculation may provide extreme framerate values,
which will cause encoder failures because of too high MBPS for the given
profile. One such case was detected by test
android.media.codec.cts.MediaCodecTest#testAbruptStop after OMX removal.

As the CTS test itself can generate such values, the encoder was
updated to calculate the maximum allowed framerate for the input frame
size and output level. Then this value is used to limit the dynamic
framerate calculations. As it can be potentially an app error, the
warning is printed whenever this happens.

Note: this is currently done only for H264. For other codecs the
clamping won't be effective, as the maximum allowed framerate is set to
uint32_t::max().

Bug: 295339810
Bug: 362902868
Test: android.media.codec.cts.MediaCodecTest#testAbruptStop
Test: com.google.android.media.gts.RtcVideoCodecTest#testDynamicFramerateChangeVp8
Change-Id: I783493453d762886a10996d0ad9821149cafb014

The allocated buffer size for the encoded bitstream is always set to 1MB
which might not be always accurate. It is possible to exceed it when
high bitrates are used, like 10Mb/s. The encoder might put zeros
to the output buffer to meet required bitstream. Also in case of slow
devices the encoder might put zeros to meet the time constraints.
For the sake of compatibility, set it to the same values as the Chrome
browser does for a 1080p stream.

Bug: 326164993
Test: CtsMediaCodecTestCases
Change-Id: I4c2d06da588d2a12a593bbba3461384d8b3dffca

The original change ag/25539865 was submitted in `main`. Backporting it
to this branch to reduce divergence.

Bug: 314693926
Bug: 314784915
Test: m
Change-Id: I25a226b8eb962138489f30cd0fa1a42c3e599bdf

The upstream includes these headers after declaring android::base
namespace, which resulted in confusing the compiler libchrome's ::base
v.s. android::base

Bug: 314693926
Test: m
Change-Id: I25a226b8eb962138489f30cd0fa1a42c3e599bdf

This CL takes into consideration client request for the
max-input-size. Usually this request was smaller and
component recommended a hardcoded value for
area < 1920*1088 but it proved to be not enough for
some specific case. First the parameter is read and
stored, then we compare this value with the one
calculated as before and we finally set the biggest one.
In this way another hardcoding of arbitrary size
for area between 1920*1080 and 1920*1088 is avoided.

Bug: 280733224
Test: CtsMediaEncoderTestCases
Change-Id: I9486a6d81f9dcdd66ade8bfd10e5b4545ffcaf44

This CL extracts V4L2 related code to a separate build module in order
to move V4L2 dependency for R-container

Bug: 281818034
Bug: 267299128
Test: m
Change-Id: I1fc878b4a41625e61d27bde5a9dcb9d157882758

This CL is decoupling interface class from V4L2Encoder. This is
preparation work for upcoming VEA backed implementation of VideoEncoder
for R-container.

Bug: 281818034
Bug: 267299128
Test: m
Change-Id: I4361d5f91ad985fffbd84b9cee2806c7eda9078e

This CL is decoupling interface class from V4L2Decoder. This is
preparation work for upcoming VD backed implementation of VideoDecoder
for R-container.

Bug: 281818034
Bug: 267299128
Test: m
Change-Id: Iaa8917ac08fb9a3bedcbb9c8a7013c642eca7d7a

This CL extracts V4L2ComponentStore code that will be common with
C2ComponentStore for VD decoder implementation.

Bug: 281818034
Bug: 267299128
Test: m
Change-Id: Ic4e8005b0c8d670f93bcbecc89a0831cb97aeda1

This CL is decoupling interface class from V4L2Device. This is
preparation work for upcoming VD backed implementation of VideoDecoder
for R-container.

Bug: 281818034
Bug: 267299128
Test: m
Change-Id: I64b873c369b3d961c0325406b11c3aba077dad6d

This CL is decoupling interface class from V4L2Device. This is
preparation work for upcoming VD backed implementation of VideoDecoder
for R-container.

Bug: 281818034
Bug: 267299128
Test: m
Change-Id: Iffa4a71c0bd7072427bbfc29abf310c8ec35f8a4

The decoder might held a few frames as a reference for decoding. Since
Android T the Codec2 is more prone to timeout the component if one is not
producing frames. This might especially occur when those frames are held
for reference and playback/decoding is paused. With increased output delay
we inform Codec2 not to timeout the component, if number of frames in
components is less then the number of maximum reference frames that
could be held by decoder.

This CL increases C2_PARAMKEY_OUTPUT_DELAY to maximum number of frames
that VPx specs specifies.

Bug: 277456388
Test: YouTube VP9 video remains paused after pause
Change-Id: I2ba1aa3ef806c0d48888964577287d4c4afc4052

During MediaSyncTest the C2BufferQueueBlockPool can supply the same
frame twice, due to inconsistency of cached GraphicBuffer assigned to
specific buffer queue slots.

Prior this change If our decoder detects that the frame is already
enqueued to decoder device, such frame is ignored and frame fetch is
retried.

Bug: 275020404
Test: CtsMediaMiscTestCases android.media.misc.cts.MediaSyncTest
Test: CtsMediaDecoderTestCases
Change-Id: I3ed10476f8c4bf4ede68787a55d423b712716e48

This reverts commit 7b45fc08.

Reason for revert: Introduces regresssion in CtsMediaEncoderTestCases

Bug: 277013634
Test: CtsMediaEncoderTestCases
Change-Id: Ic75d1795e2d4bcbea008020b16711172081d0d47

This reverts commit 65874cb2.

Reason for revert: Introduces regresssion in CtsMediaEncoderTestCases

Bug: 277013634
Test: CtsMediaEncoderTestCases
Change-Id: I2b2bc139cb0461f8cf19021b53fae1f5cda62bbe

This reverts commit e51ec9cd.

Reason for revert: Breaks seek

Bug: 278171137
Bug: 249679443
Change-Id: I4f524f8e71f669419aab5e510cbafa49209b0cd0

The C2BqBuffer has a warning log if there are 6 or more dequeue failures
in a row. Increase the initial delay and backoff rate when scheduling
dequeue retries. The new parameters sum to ~60ms before we start getting
warnings.

Bug: None
Test: Play a YouTube video

Change-Id: I685f830d4005a844b615503148ddf9de7d0a1d78

Try to detect null fences to avoid spinning on the buffer queue.

Bug: 278015757
Test: Inspect perfetto trace of YouTube playback

Change-Id: If95299e41c9fcc75cccbf3aa4a0a7058836eb6b7

This CL switches to output allocator to C2PlatformAllocatorStore::GRALLOC
that enforces use of C2PooledBufferPool without need of allocating a
separate allocator ID. For this reason V4L2AllocatorId::V4L2_BUFFERPOOL
is no longer used and is removed in this change.

Bug: 268301611
Bug: 268305422
Bug: 270329448
Bug: 238710012
Bug: 238390060
Bug: 270331759
Bug: 238709912
Test: CtsMediaCodecTestCases
Test: CtsMediaDecoderTestCases
Test: CtsMediaV2TestCases
Test: GtsExoPlayerTestCases com.google.android.exoplayer.gts.CommonEncryptionDrmTest#cencSchemeTypeV*
Change-Id: Ife2fbb6ac4ff2dc25e006792f8dad2d8ec6f4ac4
(cherry picked from commit 210185e4)

This CL removes unused source code files, since classes inside of them
are no longer used in the component.

Removed classes are:
 * C2VdaBqBlockPool
 * C2VdaPooledBlockPool
 * H2BGraphicBufferProducer

Bug: 268301611
Bug: 268305422
Bug: 270329448
Bug: 238710012
Bug: 238390060
Bug: 270331759
Bug: 238709912
Test: CtsMediaCodecTestCases
Test: CtsMediaDecoderTestCases
Test: CtsMediaV2TestCases
Test: GtsExoPlayerTestCases com.google.android.exoplayer.gts.CommonEncryptionDrmTest#cencSchemeTypeV*

Change-Id: I0fc53c942ecb44bde246fca72234a176acb47122
(cherry picked from commit 347ef462)

This CL removes requestNewBufferSet and setNotifyBlockAvailableCb
methods, that became unused after switch to C2BufferQueueBlockPool and
C2PooledBlockPool.

Bug: 268301611
Bug: 268305422
Bug: 270329448
Bug: 238710012
Bug: 238390060
Bug: 270331759
Bug: 238709912
Test: CtsMediaCodecTestCases
Test: CtsMediaDecoderTestCases
Test: CtsMediaV2TestCases
Test: GtsExoPlayerTestCases com.google.android.exoplayer.gts.CommonEncryptionDrmTest#cencSchemeTypeV*
Change-Id: I6085cb7d5a7118d2b81d1f6d9d533b98fc978fa1
(cherry picked from commit d73cbf57)

With implementation of limitation of number of fetched buffers inside
VideoFramePool, there is no need to use C2VdaPooledBlockPool, hence
switching to C2PooledBlockPool.

Bug: 268301611
Bug: 268305422
Bug: 270329448
Bug: 238710012
Bug: 238390060
Bug: 270331759
Bug: 238709912
Test: CtsMediaCodecTestCases
Test: CtsMediaDecoderTestCases
Test: CtsMediaV2TestCases
Test: GtsExoPlayerTestCases com.google.android.exoplayer.gts.CommonEncryptionDrmTest#cencSchemeTypeV*

Change-Id: Iaac647c0ddbeba1e820bb2daf63e94894eb2b424
(cherry picked from commit db98c8b0)

Due to move to Codec 2.0 VNDK 1.2 and implementation of asynchronous
graphic buffer fetching, there is no need to use C2VdaBqBlockPool.
Limitation of number of fetched buffers is done by C2SurfaceSyncMemory
and VideoFramePool. For this reason switching to C2BufferQueueBlockPool.

This moves unblocks a dozen of tests failures on Android T.

Bug: 268301611
Bug: 268305422
Bug: 270329448
Bug: 238710012
Bug: 238390060
Bug: 270331759
Bug: 238709912
Test: CtsMediaCodecTestCases
Test: CtsMediaDecoderTestCases
Test: CtsMediaV2TestCases
Test: GtsExoPlayerTestCases com.google.android.exoplayer.gts.CommonEncryptionDrmTest#cencSchemeTypeV*
Change-Id: Ia36a290146860f68c611da4746cd0375225adc99
(cherry picked from commit c53b55c4)

This CL moves limitation logic from C2VdaPooledBufferPool to
VideoFramePool. This will allow removal of C2VdaPooledBufferPool.

Bug: 268301611
Bug: 268305422
Bug: 270329448
Bug: 238710012
Bug: 238390060
Bug: 270331759
Bug: 238709912
Test: CtsMediaCodecTestCases
Test: CtsMediaDecoderTestCases
Test: CtsMediaV2TestCases
Test: GtsExoPlayerTestCases com.google.android.exoplayer.gts.CommonEncryptionDrmTest#cencSchemeTypeV*
Change-Id: I78abfdbcda6f9b3de2a6d5bcfd705a7028490f9b
(cherry picked from commit b9a66ded)

This CL adds asynchronous frame fetching to VideoFramePool that relies
on new API introduced in Codec 2.0. When a buffer is not available the
new version of fetchGraphicBlock returns a C2_BLOCKING together fence
that will be signaled once the call should be retried.

Bug: 268301611
Bug: 268305422
Bug: 270329448
Bug: 238710012
Bug: 238390060
Bug: 270331759
Bug: 238709912
Test: CtsMediaCodecTestCases
Test: CtsMediaDecoderTestCases
Test: CtsMediaV2TestCases
Test: GtsExoPlayerTestCases com.google.android.exoplayer.gts.CommonEncryptionDrmTest#cencSchemeTypeV*
Change-Id: Id470113e2037ec2c69ed1ccbf2fe15a4facf80ce
(cherry picked from commit cb4034b1)

This CL adds mapping from buffer id to C2GraphicBlock to extend its
underlying allocation lifetime. It is to prevent preemptive removal of
protected buffer shadowing.

Bug: 274597070
Bug: 277016520
Test: Widevine playback in ExoPlayer demo app
Change-Id: I92768dddd4e6b7abcbef0d0b39f3427019c6b675

Since V4L2 codec already supports Baseline and Main Profiles
we can safely indicate support for Constrained Baseline Profile.
Current implementaion of virtio-video driver does not support
query for decoder profiles so this patch updates only default
cabalilities at C2Codec layer.

Bug: 238390060
Test: CtsMediaV2TestCases

Change-Id: Id6843b931774d8065d38397c787582d38ee7366c
Signed-off-by: Slawomir Rosek <srosek@google.com>

The VP9 decoder does not support and does not need the Codec Specific Data (CSD):
https://www.webmproject.org/docs/container/#vp9-codec-feature-metadata-codecprivate

.
The most of its content (profile, level, bit depth and chroma subsampling)
can be extracted directly from VP9 bitstream. Ignore CSD if it was passed.

Bug: 238390060
Test: CtsMediaV2TestCases
Change-Id: I4373940113abb78a426a5658bfb21b66b2f4a74f
Signed-off-by: Slawomir Rosek <srosek@google.com>

Prior this patch V4L2DecodeInterface reported support for decoding
color-aspect from stream unconditionally. However at this moment v4l2_codec2
support decoding this information only for unprotected H264 and both
protected and unprotected HEVC. This CL fixes this.

Bug: 271992107
Test: CtsMediaV2TestCases android.mediav2.cts.DecoderColorAspectsTest
Change-Id: I4ba626c7766cf3cdb21757207ecac69eef0852c5

Thanks Yiwei pointed out the buggy code which doesn't do error handling
and also we should only sync CPU writable buffer.

Bug: 268317650
Test: atest com.google.android.media.gts.RtcVideoCodecTest#testDynamicBitrateChangeVp8
Change-Id: I3c1019fb0d56180ef8460625843cf8e98301ddce

Thanks Yiwei pointed out the buggy code which doesn't do error handling
and also we should only sync CPU writable buffer.

Bug: 268317650
Test: atest com.google.android.media.gts.RtcVideoCodecTest#testDynamicBitrateChangeVp8
Change-Id: I3c1019fb0d56180ef8460625843cf8e98301ddce

This CL switches to output allocator to C2PlatformAllocatorStore::GRALLOC
that enforces use of C2PooledBufferPool without need of allocating a
separate allocator ID. For this reason V4L2AllocatorId::V4L2_BUFFERPOOL
is no longer used and is removed in this change.

Bug: 268301611
Bug: 268305422
Bug: 270329448
Bug: 238710012
Bug: 238390060
Bug: 270331759
Bug: 238709912
Test: CtsMediaCodecTestCases
Test: CtsMediaDecoderTestCases
Test: CtsMediaV2TestCases
Test: GtsExoPlayerTestCases com.google.android.exoplayer.gts.CommonEncryptionDrmTest#cencSchemeTypeV*
Change-Id: Ife2fbb6ac4ff2dc25e006792f8dad2d8ec6f4ac4

This CL removes unused source code files, since classes inside of them
are no longer used in the component.

Removed classes are:
 * C2VdaBqBlockPool
 * C2VdaPooledBlockPool
 * H2BGraphicBufferProducer

Bug: 268301611
Bug: 268305422
Bug: 270329448
Bug: 238710012
Bug: 238390060
Bug: 270331759
Bug: 238709912
Test: CtsMediaCodecTestCases
Test: CtsMediaDecoderTestCases
Test: CtsMediaV2TestCases
Test: GtsExoPlayerTestCases com.google.android.exoplayer.gts.CommonEncryptionDrmTest#cencSchemeTypeV*

Change-Id: I0fc53c942ecb44bde246fca72234a176acb47122

This CL removes requestNewBufferSet and setNotifyBlockAvailableCb
methods, that became unused after switch to C2BufferQueueBlockPool and
C2PooledBlockPool.

Bug: 268301611
Bug: 268305422
Bug: 270329448
Bug: 238710012
Bug: 238390060
Bug: 270331759
Bug: 238709912
Test: CtsMediaCodecTestCases
Test: CtsMediaDecoderTestCases
Test: CtsMediaV2TestCases
Test: GtsExoPlayerTestCases com.google.android.exoplayer.gts.CommonEncryptionDrmTest#cencSchemeTypeV*
Change-Id: I6085cb7d5a7118d2b81d1f6d9d533b98fc978fa1

With implementation of limitation of number of fetched buffers inside
VideoFramePool, there is no need to use C2VdaPooledBlockPool, hence
switching to C2PooledBlockPool.

Bug: 268301611
Bug: 268305422
Bug: 270329448
Bug: 238710012
Bug: 238390060
Bug: 270331759
Bug: 238709912
Test: CtsMediaCodecTestCases
Test: CtsMediaDecoderTestCases
Test: CtsMediaV2TestCases
Test: GtsExoPlayerTestCases com.google.android.exoplayer.gts.CommonEncryptionDrmTest#cencSchemeTypeV*

Change-Id: Iaac647c0ddbeba1e820bb2daf63e94894eb2b424

Due to move to Codec 2.0 VNDK 1.2 and implementation of asynchronous
graphic buffer fetching, there is no need to use C2VdaBqBlockPool.
Limitation of number of fetched buffers is done by C2SurfaceSyncMemory
and VideoFramePool. For this reason switching to C2BufferQueueBlockPool.

This moves unblocks a dozen of tests failures on Android T.

Bug: 268301611
Bug: 268305422
Bug: 270329448
Bug: 238710012
Bug: 238390060
Bug: 270331759
Bug: 238709912
Test: CtsMediaCodecTestCases
Test: CtsMediaDecoderTestCases
Test: CtsMediaV2TestCases
Test: GtsExoPlayerTestCases com.google.android.exoplayer.gts.CommonEncryptionDrmTest#cencSchemeTypeV*
Change-Id: Ia36a290146860f68c611da4746cd0375225adc99