The AM62P gralloc implementation defaults to NV12 when the
YCBCR_420_888 format is requested.
This is a requirement for using libcamera.

Make sure we configure the video decoder to use the
same pixel format.

Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>

This adds support for the HEVC/H265 codec to the Android codec2 V4L2
decode component.

Bug: 215043150
Bug: 183217901
Test: ExoPlayer works with HEVC on guybrush w/ codecs added and
corresponding ChromeOS CLs for crosvm/libvda

Change-Id: I3707e9730d245871b74982527edfebe81b484e8a
(cherry picked from commit 05bacef7fa53541f21c85f26f6f8351dcdfd7f0e)

When we allocate V4L2 output buffers, the driver might change the
number of buffers. This CL respects the number of buffers from V4L2
driver, instead of using the original requested number.

Bug: 202923667
Test: pass e2e test

Change-Id: Ic0d8e34014a0e3015bb995026f4b17f50c6b578e

Bug: None
Test: mmm external/v4l2_codec2
Change-Id: I21d5d30ce32279dfb1cbe2b40d435d2e9707f5aa

Currently an FD is stored inside the BitstreamBuffer object. This CL
moves the C2 linear block buffer directly inside the BitstreamBuffer.
This makes management of output buffers in the encoder simpler as we
don't need to manually keep output buffers alive. This is also required
by subsequent CLs that introduce functionality to prepend H.264 SPS and
PPS NAL units to IDR frames in the video stream.

Since both the decoder and encoder make use of the BitstreamBuffer
class and both have different requirements some changes needed to be
made. The decoder uses a 'C2ConstLinearBlock' as bitstream buffers are
used as input and do not need to be modified. The encoder uses a
'std::shared_ptr<C2LinearBlock>' as the encoded output stream will be
written to a bitstream buffer object. To accommodate these requirements
the BitstreamBuffer object is split up into a 'BitstreamBuffer' and
'ConstBitstreamBuffer' object.

BUG: 161495502
Test: arc.VideoEncodeAccel.h264_192p_i420_vm
Change-Id: Icfd0a84ef09cf283510763c51f92fe83bc7166c2

CCodecBufferChannel (CCBC) set the number of output slots to
"output delay + kSmoothnessFactor". CCBC would pause sending input
buffers to the component when all the output slots are filled by
pending decoded buffers.  If the available output buffers are exhausted
at the output slots before CCBC pause sending input buffers, CCodec
would treat this situation as timeout easily. This CL increases the
number of output buffer more than the number of output slots to
prevent this situation from happening.

Note: CCodec measures the elapsed time between CCBC passes a input
buffer to the component and the component returns the corresponding
output buffer back to CCBC. If the elapsed time is greater than a
threshold, then CCodec considers the component stop working.

Bug: 184020290
Test: android.media.cts.VideoEncoderTest#testGoogH264Flex1080p

Change-Id: I38502d77d247499f1fcc5b434f18ad5e6edbfcb9
(cherry picked from commit 5d06eade6f296b88eacb8619e04ba96a9e60deb7)

Originally we always streamon the output queue after flush is done.
However the output queue might not be streaming before flush. In this
case we don't need to streamon the output queue.

Bug: 170199771
Test: android.media.cts.AdaptivePlaybackTest

Change-Id: I94f76a5737b7f6536acc169876cf0f7e9060d5bb

This CL setups the supported pixel format when resolution change.
Currently the supported pixel format is flexible 420 format.

Bug: 170199771
Test: android.media.cts.AdaptivePlaybackTest

Change-Id: Ic1b8f5c23fa5ff14c5dba026e0d927df092a6351

This CL changes the V4L2 decoder and encoder to use the Android Size
structure instead of the one copied from Chrome, the Chrome size.h file
is removed.

Bug: 155138142
Test: arc.VideoEncodeAccel.h264_192p_i420_vm
      arc.VideoDecodeAccel.h264_vm
Change-Id: I8f63e847d8cf4ffd33621706287a44c93a4864fd

This CL changes the V4L2 decoder and encoder to use the Android rect
structure instead of the one copied from Chrome, the Chrome rect.h file
is removed.

Bug: 155138142
Test: arc.VideoEncodeAccel.h264_192p_i420_vm
      arc.VideoDecodeAccel.h264_vm
Change-Id: Ie581deee6b4b43a27c45e48269a6902526727933

This CL reworks the V4L2 device and V4L2 device poller code that was
branched from their Chrome counterparts:
- Adhere to the Android coding style.
- Make use of Android logging mechanisms.
- Make use of Android assert macros.

Bug: 155138142
Test: arc.VideoEncodeAccel.h264_192p_i420_vm
Change-Id: I4842624e7fae9fc3f52d90dc90a5e7c026c63513

Bug: 160110407
Test: m -j32
Change-Id: I6546e851e685eb78e23314d8ad09ad9117fbce6d

The logs of V4L2Decoder are too verbose for debug image. This CL
adjusts the ALOGD log to ALOGV.

Bug: 178665560
Test: m -j32

Change-Id: Id8c94b3e515a43ab90404cc34b9a5ee3e5442469

tryFetchVideoFrame() is used to fetch output buffers from
VideoFramePool. It should be triggered after a buffer is fetched.
But if there is no free V4L2 slot, then we postpone triggering the
method until there is free V4L2 slot (i.e. a buffer is DQBUF from
V4L2 output queue).

However, when getting flush request, we streamoff V4L2 output queue.
All the buffers are dropped, no buffer will be DQBUF from V4L2 output
queue. In this case we should trigger tryFetchVideoFrame() after
flush request is completed.

Bug: 176038223
Test: android.media.cts.DecoderTest#testCodecResetsH264WithoutSurface

Change-Id: I59217dbe25592dcc877430263524382b7f9e17d2

VideoFramePool is used to wrap C2BlockPool and request buffers for
V4L2Decoder. When resolution changes, V4L2Decoder creates a new
VideoFramePool instance to request buffers with new resolution.
Also, C2VdaBqBlockPool is designed to provide buffers with the same
resolution. So there only one VideoFramePool could exist at the same
time.

This CL destroys the previous VideoFramePool before getting the new
one, and checks the buffer format passed to
C2VdaBqBlockPool::fetchGraphicBlock() is the same as the format
requested by requestNewBufferSet().

Also, this CL simplifies the signature of the callback of getting
VideoFramePool. Originally we put the returned value at output
argument because Chromium callback with WeakPtr doesn't support
returned value. But we actually could avoid WeakPtr here because
V4L2Decoder is always destroyed before V4L2DecodeComponent. It's safe
to use ::base::Unretained(this).

Bug: 174287571
Test: android.media.cts.AdaptivePlaybackTest#test{H264,Vp8,Vp9}_*

Change-Id: Ib06855e7ccc3db5508a4a3f6403bceedb9b5f59d

Bug: 160110407
Test: m -j32

Change-Id: If68fa775e2ea88bdbee46d3e6ef7854b5f7fee13

The ASSERT check for |mVideoFramePool| might fail if we fail to get a
new video frame pool when resolution changes, but ServiceDeviceTask()
invokes a new task to tryFetchVideoFrame() prior to resolution
changes.

To avoid the service crash, this CL replaces the assert to a if
statement.

Bug: 168557465
Test: pass android.media.cts.AdaptivePlaybackTest#testVP8_adaptiveDrc
      with related CLs

Change-Id: I8c17ba21f3d72fa1518e482dd70657a5f254fe17

This CL handles the error when we enqueue buffers to V4L2 queues.

Bug: 168557465
Test: pass android.media.cts.AdaptivePlaybackTest#testVP8_eosFlushSeek
      with related CLs

Change-Id: I0e7fc9231e7533ee64d204ed02994f001865b085

If the output buffer dequeued from the V4L2 queue is not used (i.e.
bytesUsed is equal to 0), then we could recycle the buffer back to the
V4L2 queue. This could save the time of fetching the buffer from the
buffer pool.

Bug: 168557465
Test: pass android.media.cts.AdaptivePlaybackTest#testVP8_eosFlushSeek
      with related CLs

Change-Id: I68a2aa620a6ddc9e1994b37113d07695988a71c8

Originally we stop fetching output buffers when drain or flush is
finished, and resume fetching when getting resolution change event.
But the V4L2 driver might not send the event after drain or flush.

This CL changes not to stop fetching output buffers after drain or
flush.

Bug: 168557465
Test: Pass android.media.cts.AdaptivePlaybackTest#testVP8_eosFlushSeek
      with related CLs

Change-Id: I389b85c1718ae82933329a10fe09ca6abbb57f5d

Originally we streamoff both input and output queue when Flush() is
called. We expect the V4L2 driver will send the resolution change
event after the playback resumes. Then the output queue will be
streamon again.

However, the driver might not send the event if the resumed playback
has the same resolution. In this case, the output queue won't be
streamon and the playback is stuck. This CL streamons the output queue
immediately after the output queue is streamoff.

Bug: 168557465
Test: Pass android.media.cts.AdaptivePlaybackTest#testVP8_eosFlushSeek
      with related CLs

Change-Id: I0e3f0bd6445150ed9df2a30aac8ff692ec626137

Originally, VideoFramePool can accept multiple requests in parallel.
However, it increases the code complexity. Also, currently the caller
only request one frame at the same time.

This CL changes the VideoFramePool to accept one request at the same
time.

Bug: 166072201
Test: pass tast.arc.VideoDecodeAccel.h264_vm

Change-Id: I16811e1d004dcaf8baeb70efb4a1cb5d2a3daacf

This CL removes the use of ::base::ScopedFD in the VideoFrame and
BitstreamBuffer classes. The use of ScopedFD forces us to duplicate
the file descriptor, while this is not necessary.

Bug: 143333813
Test: tast run $HOST arc.VideoDecodeAccel.h264_vm on hatch-arc-r
Change-Id: I7e6fccbd142889f779f409947784568d89f0d13e

This reduces the verbosity of logs that appear very often during
execution of the c2_e2e_test.

Bug: 166401871
Test: Run c2_e2e_test and verify there is no logspam

Change-Id: Ie21c54f50b52c6062f8e7b6c9bc02ef226d3451d

|mFrameAtDevice| is to track the buffers enqueued in the V4L2 output
queue. When we streamoff the V4L2 queue, all of the enqueued buffers
are dropped immediately. Therefore we should also clear
|mFrameAtDevice| at the same time.

Bug: 166072201
Test: Run gts.DashTest#testWidevineVp9AdaptiveWithRendererDisabling
      and check the error message added by this CL doesn't appear.
Change-Id: Ibda5949710e66e78a6f49c80c57e94c93fe69afc

We should only fetch buffers when there are free V4L2 output slots.
This CL adds the check to avoid unnecessary buffer fetching.

Bug: 160110407
Test: Run e2e test and confirm that buffer fetching is skipped
      when no free V4L2 slot
Change-Id: If50752964155ba65d8cc7ec0805507c053716294

This CL extracts and moves the BitstreamBuffer class into
BitstreamBuffer.h, to allow it to be reused.

Bug: 143333813
Test: tast run $HOST arc.VideoEncodeAccel.h264_vm on hatch-arc-r
Change-Id: I3c8e1054929878bd5a0a3d3a894c0e766874a532

Block IDs can be arbitrarily large, but we only have a limited number of
V4L2 buffers. Keep an association between the block IDs received from
VideoFramePool and a V4L2 buffer slot to use with them instead of
assuming that block IDs can be used as valid V4L2 buffer indices.

Bug: 161323057
Test: arc.VideoDecodeAccel.h264_vm fully passes on Kukui.
Change-Id: Id6a1013795d85cc08e3dca9308442db4921ddae0

Originally we pass arbitrary output buffers to V4L2 Queue. However,
the V4L2 stateful API requires the caller pass the same buffers to the
output queue slot. This CL implement this requirement.

Bug: 161770200
Bug: 161323057
Test: arc.VideoDecodeAccel.h264_vm runs first test successfully.
Change-Id: I8f6c8871997f310425571b3983ae86f05c0c37c6

In this CL, V4L2DecodeComponent supports the protected playback by
using C2VdaBqBlockPool. To use C2VdaBqBlockPool, there are 2 specific
requirements compared to a normal C2BlockPool:
1. Call C2VdaBqBlockPool::requestNewBufferSet() before fetching blocks
2. Call MarkBlockPoolDataAsShared() after creating C2ConstGraphicBlock

Bug: 153608694
Test: Run ExoPlayer Demo apk: Widevine dash policy tests

Change-Id: Idce298d13cb2fb7f9dd88ae43cd4c8f0cb18dffb

This CL adds or fixes some information at logging, not changing the
code logic.

Bug: 160110407
Test: m -j32

Change-Id: I97d2cd43a526e56000abcc16886b1f0f6e0f6b71

This CL implements V4L2DecodeComponent, a decode C2Component via V4L2
API. It mainly contains these parts:

- VideoDecoder:
  An interface for video decoding, similar to media::VideoDecoder at
Chromium project.
- V4L2Decoder:
  An implementation of VideoDecoder via V4L2 stateful API. We wrap all
  V4L2-related logic in this class

- VideoFrame
  The data structure to represent the output buffer of VideoDecoder.
  It encapsulates a C2GraphicBlock and only exposes the essential
  information of physical buffers.
- VideoFramePool:
  The buffer pool used by VideoDecoder. It encapsulates C2BlockPool
  and provides asynchronous method to fetch buffers.

- V4L2DecodeComponent, V4L2DecodeInterface:
  The C2Component implementation that delegates the decode request to
  V4L2Decoder.
- V4L2ComponentFactory:
  The C2ComponentFactory that creates V4L2DecodeComponent.

Bug: 152714603
Test: mmm external/v4l2_codec2/
Test: Run e2e test and make sure the V4L2DecodeComponent is running

Change-Id: I23e9b3553b62dd6c83d943d7787297305372c37d