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

This CL uprevs Codec 2.0 VNDK version 1.2 to take advantage of
asynchronous graphic buffer fetching from buffer queue in following
patches.

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: Icad6d78c3f36d365749af787f2b3bab3edc54d3e

Android encoder framework reuses the same gpu buffers as
inputs and doesn't call lock/unlock explicitly between writes.
If there is format conversion, this is fine since we will
read back what we've written first and then put it in another
buffer. Whenever there is no format conversion, this causes
sync issue on ARCVM since host side buffers never get updated.
Fix this by explicitly calling lock/unlock before sending buffer
to encoder.

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

Mediatranscoder is in /system dir and is in a namespace,
hence it cannot load a library from /vendor. As a one-time
solution for T, this CL makes the allocator plugin to be
built under /system instead of /vendor.

Bug: 238261454
Test: CtsMediaProviderTranscodeTests

Change-Id: I5efbd4690fac98851a208107f6a9ee0d10c35aac

This CL refactors querying capabilities. It eliminates usage of single
instance of V4L2Device for multiple devices by exporting querying
methods to static.

Bug: 251420501
Test: adb shell dumpsys media.player
Test: adb logcat
Change-Id: I0d4ea16d2818a9c3cbde3ae31a99419a457cb1c1
(cherry picked from commit e4b9917003de8c330c91a1cd0a1d55a7e9828e7d)

CL ag/21114313 changed when decoder requests buffers for CAPTURE queue.
It introduced regression because the VideoFramePool was not requested to
supply frame buffers after flush.
This CL address this issue.

Bug: 267993066
Bug: 266883226
Test: android.media.cts.DecoderTest
Test: android.media.cts.MediaCodecTest
Test: android.media.cts.MediaPlayerTest
Change-Id: Iac33ab8aec3aac3f54cba1c4d1d97769bc7a1485

Prior this CL, the decoder continuously requests video frames from the
pool even when the playback will no longer continue. This is problematic
due to changes in Codec 2.0/BufferQueue, that cause the pool to
disconnect from IGBP shortly after playback is done causing pool to
supply nullptr to decoder and switch V4L2Decoder to Error state.

Bug: 238709912
Test: run cts-dev -m CtsMediaDecoderTestCases --module-arg \
        CtsMediaDecoderTestCases:instrumentation-arg:codec-prefix:=c2.v4l2
Change-Id: I7c96ff158e89f41a53eba402c16a2e4558bfb3bc
(cherry picked from commit 5e2df4e31e2891f679ead0743ce36281f62fc07a)

Before this CL the V4L2Decoder used V4L2_MEMORY_MMAP backed buffer for
initial EOS buffer. This was a work around for not yet available IGBP.

With this CL the backing of the buffer will be the same like for all
buffers used by V4L2Decoder.

Bug: 261818131
Test: android.media.cts.DecoderTest
Change-Id: Ic1eaededb16c0bab856583136b45895d4704a3d9
(cherry picked from commit cb8221eeefb8561333c0d8644ebfdb3849ecbc06)

Prior this change the decoder did not initialize output queue (CAPTURE).
For this reason V4L2_DEC_CMD_STOP could not be called and thus there was no
way of initiating a drain request and telling if has finished, before dynamic
resolution change event has been dequeued. This specific issue was
especially problematic for small test streams where a single frame was decoded.

This CL changes how V4L2Decoder is initialized. The output queue is
initialized together with input queue with minimal supported resolution
and minimal number of buffers. A single buffer then is enqueued without
any filled data, and the sole purpose of this buffer to be dequeued
after drain request is finished.

Bug: 230794283
Test: android.media.cts.DecoderTest
Change-Id: Id911fab5f9d14fbc5e20673289115ffb19f43ab0
(cherry picked from commit 39e152d6b67acfc13f2285dcbabe02061945c34e)

Query all supported resolutions and set the biggest
as upper boundary in mSize parameter, default value for
this parameter are also limited to those boundary.

If query is not available default max size is set.

If ther is no supported profile default max size is set.

Bug: 251420501
Test: android.media.cts.DecoderTest
Change-Id: I4cb8d0724b40c705a4bf72224442268b92e4d11d
(cherry picked from commit 4f1bb9b3c47a946e7f2ad4dbaa2179b22ed37ec9)

New function returns vector of VideoLevels supported for specified codec
based on device driver.

Supported levels are passed to device interface parameters.

Bug: 251420501
Test: android.media.cts.DecoderTest
Change-Id: I6fb896906b2d784b55d2fd54094e5993a1dacefe
(cherry picked from commit 57fd4649b8833ccc48a4c75e23c99c355ebd7477)

Moved IsValidProfileForCodec to Common
and renamed to isValidProfileForCodec.
Query default profiles and pass to device interface parameters.

Bug: 251420501
Test: android.media.cts.DecoderTest
Change-Id: I2b94381c27da1b7f91bc81b3f43b31a04a4372d7
(cherry picked from commit 7ec77b746c63c1c7e8353107874c9a6baff9f5c2)

Replace the use of lowestConfigLevel as a static local variable with
an static attribute of V4L2EncodeInterface to highlight shared data
between all instances of this class and make this information explicit
in class definition.

Test: Build image
Change-Id: Ifee1b81b481e1890c1647b7d287f1111a8a03ba8
(cherry picked from commit 3d8ea4298d992d63cd57ab8a7df15acfafd7a34f)

This CL fixes the crash ocurring when LOG_NDEBUG is defined. The crash
was caused by calling a mClientTaskTunner->RunsTasksInCurrentSequence()
in the ALOG_ASSERT in the startPolling() method which initializes
mClientTaskTunner variable.

Bug: none
Test: a process continues to function after defining LOG_NDEBUG
Change-Id: I3bb5bae4eaaf9ef38136ea16f93c9203c498d03b
(cherry picked from commit a2a4be59542ee0266905a98c9ac7fd4bc04a288c)

This is a reland of commit 63a1df9bdf1c741128a2b090b852037c02f613cb.
The change alone did not cause the regression in b/253993076.

Original change's description:
> This CL changes stalls the drain request until V4L2_EVENT_SOURCE_CHANGE
> is received. It is done by not submitting V4L2_DEC_CMD_STOP if output
> queue is not streaming. When the event is received then we request to
> pump the drain request to device.
>
> Bug: 230794283
> Test: android.media.cts.DecoderTest#testEOSBehaviorVP8
> Change-Id: I834fe4aa705d498d753cfb06be20fa21302450d1

Bug: 230794283
Bug: 253993076
Test: android.media.cts.DecoderTest#testEOSBehaviorVP8
Test: android.video.cts.VideoEncoderDecoderTest
Change-Id: Ie95dd0703eac9b5f2d37b4cde76e72c50586c592
(cherry picked from commit 8c013f5680345df4075586b0460bd548a9c26ede)

This is a reland of commit 8f6a260e89bf1b33b6bcdd2803b653f5361db77a

This version of the CL includes a fix for b/253993076.  The root cause of
the regression was caused by not calling poll again with
POLLIN | POLLOUT | POLLPRI after schedulePoll() was called and
only POLLPRI was dequeued. It was fixed by setting mPollBuffers to true if
it was set to true before the poll and the poll did not yielded that buffers
are pending.

Original change's description:
> This CL changes V4L2DevicePoller behaviour. From now on, V4L2 events are
> polled continuously and schedulePoll will schedule poll for buffer
> related events. V4L2Device::poll method was modified to accept a
> parameter with option to decide if POLLIN | POLLOUT events are enabled
> for poll (POLLERR | POLLPRI are always enabled).
>
> Bug: 230794283
> Test: V4L2_EVENT_SOURCE_CHANGE is received correctly \
>    during android.media.cts.DecoderTest#testEOSBehaviorVP8
> Change-Id: I4f063795bb0d6d27c186aaf8730fef3babd0ef8e

Bug: 230794283
Bug: 253993076
Test: android.media.cts.DecoderTest#testEOSBehaviorVP8
Test: android.video.cts.VideoEncoderDecoderTest
Change-Id: I0578d4ca440736ea858a951e4c048f0ac4e7bbcf
(cherry picked from commit e5de4ffa0524651c97938f310d26ac5b733ebc1f)

Those elements can be used in other files so moving them to header allows to avoid
duplicating code.

Bug: 251420501
Test: android.media.cts.DecoderTest
Change-Id: Ifaa232746aed1bad5b20f9bcc4768407fcda6c4f
(cherry picked from commit 0e2ae8c2c28b78c2f12edf90b9c3bfd8923406bc)

Maintain a stable mapping between bitstream dma buffers and v4l2 input
buffers when possible, to avoid unnecessary re-importing dma buffers.

Bug: 232531771
Test: CppVideoDecodeTester app from linked bug
Change-Id: I9d52ba5d5cd29b8a68e343b92f1e79500f87a737
(cherry picked from commit e28c5a5ee084b4dc6070b15726139e1a00ea8eff)

Configure the pipeline delay tuning. This lets the core codec2
framework allocate more input buffers before it considers the pipeline
full. This can significantly increase performance for systems with deep
decoder stacks, as it can keep the pipeline saturated.

Bug: 232531771
Test: CppVideoDecodeTester app from linked bug
Change-Id: I1092e38732733a3fe2444a48d7db9e4f5d98bf13
(cherry picked from commit e882e68a6038a16dbe71a2bbf955bd72554ac31d)

Argument numFormats is not needed because vector can return it's size.
Operating on vector is more convenient and allows to avoid problems with
incorrect size and exceeding array boundaries.

Bug: 251420501
Test: android.media.cts.DecoderTest
Change-Id: I059cdf60741c39c8a6de4428420d17cbdec3c223
(cherry picked from commit f16288b60b880e314722a795fd32e5ca4f34631c)

This CL adds debug stream id to multiple classes in order to allow
splitting traces tracks for better profiling multiple streams
scenarios.

Bug: 217825939
Bug: 217827216
Bug: 232531771
Test: recorded a perfetto trace
Change-Id: I64bae73f33819bc37807744eebfc4481876b2976
(cherry picked from commit 587bcc8cd6f78c906032935275eb39df23d8d880)

This patch fixes a v4l2_codec2 crash when V4L2EncodeComponent's destructor
is called unexpectedly. The crash was caused by
ALOG_ASSERT(mTaskRunner->RunsTasksInCurrentSequence()) in the
V4L2Encoder destructor.

Test: Manually kill android.media.cts process while encoding no longer
crashes the v4l2_codec2 process.
Bug: None

Change-Id: I97074ae6d11672ebd3a7b15b8ced38aca2263ac9
(cherry picked from commit 942c518217e4488993d4c46c0eba85a844f3d874)

This Cl introduces a delivery time statistics for c2_e2e_test
performance tests. The metric was inspired from tast
video.ChromeStackDecoderLegacyPerf.h264_1080p_60fps. It reports
statistics of times between frames.

Bug: 217825939
Bug: 217827216
Bug: 232531771
Test: c2_e2e_test C2VideoDecoderSurfaceNoRenderE2ETest.TestFPS
Change-Id: I1519f2400be241fe8fdd0ba73d9b81c8763db7ad
(cherry picked from commit 8bcd1bc8130ccaa54dcb296c3bd5ac631ee1bd5d)

With this change We additional tracing for tracking enqueued buffers,
queues' statistics and execution time of various method.

Bug: 217825939
Bug: 217827216
Bug: 232531771
Test: recorded a perfetto trace
Change-Id: I74af9e8edaf22ad96236067deb55a194bf4986d6
(cherry picked from commit 2fcad72436260ccf484439b56672ffcf3e48de2f)

This is required in order to pass the CTS test
android.media.cts.DecoderTest#testH265ColorAspects. There was similar
logic existing for H264 already. This creates a new NalParser abstract
class which then has H264/HEVC subclasses for parsing H264/HEVC
bitstreams.

Bug: b:236242073
Test: CTS android.media.cts.DecoderTest passes

Change-Id: I2a72e1903d28173db5a179c2ab55118fe394c52e
(cherry picked from commit 2cde4ce830a55437905bca9f9f7a5d9aae87b990)

Patch 0fa30254bd7e introduced a type mismatch when building for 32-bit architecture. This error is visible when running "mmm external/v4l2_codec2":

    external/v4l2_codec2/components/V4L2EncodeComponent.cpp:782:32: error: no matching function for call to 'max'
            int64_t newFramerate = std::max(
                                   ^~~~~~~~
    external/libcxx/include/algorithm:2529:1: note: candidate template ignored: deduced conflicting types for parameter '_Tp' ('long' vs. 'long long')
    max(const _Tp& __a, const _Tp& __b)
    ^
    external/libcxx/include/algorithm:2539:1: note: candidate template ignored: could not match 'initializer_list<type-parameter-0-0>' against 'long'
    max(initializer_list<_Tp> __t, _Compare __comp)
    ^
    external/libcxx/include/algorithm:2547:1: note: candidate function template not viable: requires single argument '__t', but 2 arguments were provided
    max(initializer_list<_Tp> __t)
    ^
    external/libcxx/include/algorithm:2521:1: note: candidate function template not viable: requires 3 arguments, but 2 were provided
    max(const _Tp& __a, const _Tp& __b, _Compare __comp)
    ^

Fix this by casting the right member of the cmp operation to int64_t.

Test: mmm external/v4l2_codec2

Change-Id: Id2cc220b9122eec412823f577f07ecd82bad60fc
(cherry picked from commit a0377993b84da09547aad11f2f27560e0bf4dcd5)

This adds support for the HEVC codec to the e2e video decoder tests.

Bug: 215043150
Bug: 183217901
Test: c2_e2e_test APK works for HEVC on guybrush w/ codecs added and
corresponding crosvm/libvda changes

Change-Id: I7b3351cede200f9be406960e2d6507d58acac55c
(cherry picked from commit e43cc425ce63d39c8ba9bdb6bb60fd08c5a3b02a)

Trying to allocate too many hardware decoders can cause a stall due
to mixed binder and hwbinder calls as described in b/35283480. This
works around it by increasing the size of the thread pool.

See a similar mitigation for mediaserver in ag/12046706.

The manual test showed that  without this patch will cause MediaCodec
to be unable to create new HW decoders until logout or reboot.
With this patch, closing the app will allow MediaCodec to create
decoders without logout or reboot.

Bug: 204055006

Test: atest CtsMediaTestCases
Test: manual test as indicated in b/204055006#comment31
Change-Id: Ib47f2b86a9536f6a8c6150e47168b990eb45305a
(cherry picked from commit 24eab8ef68eb87e4b344fd947ef7f5890867d54e)

In the past we avoided using the 'VIDEO_ENCODER' flag on input buffers.
Due to format conversion these buffers would never be sent directly to
the host, and adding the flag would cause an extra shadow buffer to be
allocated on the host. This is no longer the case and no performance
differences can be observed when always adding the 'VIDEO_ENCODER'
flag, so this CL removes the workaround.

Bug: 167640667
Test: arc.VideoEncodeAccel.h264_192p_i420_vm
Change-Id: Id247b62dfe2e6d09bc5dccbf050b0b4fe8cc263f
(cherry picked from commit a354b9103fe6b3eb303fa9eb33ee8cc0d8f36835)

Keeping a const reference to the planes is enough for our purposes.

Bug: None
Test: build succeeds for zork-arc-r.
Change-Id: I2d8ff7100ccc33e066c0924ea942f4ad4faa4bf5
(cherry picked from commit 5aea9e7e9547a65a5d0b577cad71c8ff569cdb8c)

The V4L2 encoder driver currently reports the number of NV12 memory
planes incorrectly: whereas NV12 is a single-buffer format (which
multi-planar counterpart is NV12M), the driver reports as many memory
planes as there are component planes.

We are about to fix this with http://crrev.com/c/3358090, but right now
the V4L2Encoder does not manage single-buffer formats properly: the
detection of such formats is based on the number of planes in the frame
(which will always be the number of color planes), and the V4L2
parameters are not properly set, notably the plane size.

Fix this by using the mMultiPlanar member of the input layout to detect
single-buffer formats, and properly set the V4L2 queue inputs in that
case. This allows the V4L2Encoder to operate successfully both when
http://crrev.com/c/3358090 is applied and when it is not.

Bug: b:212214039
Test: arc.VideoEncodeAccel.h264_192p_i420_vm passes on zork-arc-r without http://crrev.com/c/3358090.
Test: arc.VideoEncodeAccel.h264_192p_i420_vm passes on zork-arc-r with http://crrev.com/c/3358090.

Change-Id: Id79828f570851f8bba8ff16a897617a15dac9a19
(cherry picked from commit cbec391821f95c88ee501c85aa38d0672ad3efd8)

This CL makes a small change to the V4L2 encoder to avoid setting the
framerate denominator (parm.output.timeperframe.denominator) to zero,
which can cause a division by zero in the virtio driver. There is
currently an assert in the V4L2EncodeComponent that checks for valid
frame rates, but this check is compiled out in release builds.

Bug: 203607295
Bug: 208401566
Test: arc.VideoEncodeAccel.h264_192p_i420_vm
Change-Id: Iaeb287f57fd9a050b998fdba1f6189fc03049edd
(cherry picked from commit c036dff1eed55996f398f5dc681c0c6d6df47b93)

ag/16211950 performed cleanup in the format converter used to convert
input video frames to a different pixel format. This inadvertently
broke the functionality for RGB video frames. This CL fixes the
problem.

Bug: 207888705
Test: arc.VideoEncodeAccel.h264_192p_i420_vm
      android.media.cts.DecodeEditEncodeTest#testVideoEdit720p
Change-Id: Idf93f02599d859eb290792f8c7785765fad1294c
(cherry picked from commit ba5e6aeb894d9bdb0751185653bf1a61ed4cef22)

ag/16281471 made changes to cache the input pixel format, rather than
determining it for every single input video frame. Unfortunately when
using an input format converter the input pixel format was cached
before converting a video frame to the correct pixel format, resulting
in the wrong format being reported to the underlying V4L2 device.

Bug: 207888705
Test: arc.VideoEncodeAccel.h264_192p_i420_vm
      android.video.cts.VideoEncoderDecoderTest#testAvcOther0Perf0720x0480
Change-Id: Ia433c6db55e9a5029a99e1ab060265012d822b91
(cherry picked from commit 2d2f8e2a887a3d98bda2ff0328f098defbbc57d0)

The Chrome video encoder only supports frames in the NV12 format. When
frames in a different pixel format are provided to the Android V4L2
encoder the format converter is used to transform these frames to the
NV12 format.

When frames are already in the correct format no conversion is
performed. However the format converter currently always allocates
buffers for conversion, even when zero-copy is used. This CL makes
changes so a format converter will only be created when actually
needed.

Bug: 205203831
Test: arc.VideoEncodeAccel.h264_192p_i420_vm
Change-Id: I3fc89f2b508d7927f2ae8cfafab3284eb2700bb1
(cherry picked from commit 12b2d29d51a5e27cd54a0e57729d28d964ff561e)

The pixel format and layout of input video frames queued in the V4L2
encoder should never change during encoding. This CL makes changes to
cache the input pixel format and layout when the first video frame is
encountered. This avoids us having to lock every input graphic block,
which might negatively affect performance.

Bug: 205203831
Test: arc.VideoEncodeAccel.h264_192p_i420_vm
Change-Id: Ia9bd3078fc71df8d057449382bc1a0bad7b01c83
(cherry picked from commit 985eb31d8b8352644a516d8b96330b252ba57b4c)

This CL renames a function to fix a minor coding style violation in the
format converter.

Bug: 205203831
Test: arc.VideoEncodeAccel.h264_192p_i420_vm
Change-Id: I6524c09b2957deea2528dc0bef4edad080a227ce
(cherry picked from commit def29da9dbc2e896c548e0687ca8c2603c9ac555)

The cleanup in ag/16211950 makes it easy to now support zero-copy in
the format converter for RGB video frames. This is currently not used
as the encoder input format is NV12, but we can support if for future
use cases.

Bug: 205203831
Test: arc.VideoEncodeAccel.h264_192p_i420_vm
Change-Id: I4ccc64f7a5b8f401b8df9f2f3205f091e40bbf06
(cherry picked from commit 19161c4c3531fb78cb688d05e57ce892aa85fff0)