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)

Dynamic framerate based on timestamps can become zero when input frames
are supplied at >1 sec intervals.

Bug: 228828942
Test: android.media.cts.EncodeVirtualDisplayWithCompositionTest#testVirtualDisplayRecycles
Test: com.google.android.media.gts.RtcVideoCodecTest#testDynamicFramerateChangeVp8
Change-Id: I3ceefaad9b420f86e4f0b524e6f0b5649af9997b

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

After the component is destroyed, we cannot use shared_from_this()
because there must be a valid shared_ptr pointing to the component.

This CL changes to use weak_from_this() to get weak_ptr, and locks the
weak_ptr when we need shared_ptr. Also, the parameter of
Component::Listener's methods is weak_ptr, instead of shared_ptr.
This CL also changes to pass weak_ptr to the listener.

Bug: 198215986
Test: android.media.cts.VideoEncoderTest#testOtherH264SurfArbitraryH
Change-Id: I3bae943f211db5f68e3b9a86bc193eee09cba65e

The V4L2 encoder tries to extract SPS and PPS NAL units from H.264
video streams, as this information needs to be provided to the
mediacodec framework.

This CL makes a number of improvements to the extraction code:
- Upon extraction a temporary buffer is allocated using the full size
  of the encoded frame. This is adjusted to only allocate enough data
  to hold the SPS and PPS NAL units.
- The NAL parser currently parses the complete encoded frame data. The
  code is adjusted to stop parsing after both the SPS and PPS NAL units
  are found (which are typicaly located at the start of the frame).

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

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

This CL adds support for the C2_PARAMKEY_BITRATE_MODE parameter to the
v4l2 encoder. This parameter allows configuring the bitrate mode used
to encode a video.

The supported bitrate modes are:
- C2Config::BITRATE_VARIABLE
- C2Config::BITRATE_CONST

Note: Currently the C2 framework does not support configuring the peak
bitrate, which is used when the bitrate mode is set to VBR. Instead we
set the peak bitrate to a multiple of the target bitrate.

Note: Submit after support for V4L2_CID_MPEG_VIDEO_BITRATE_PEAK and
V4L2_CID_MPEG_VIDEO_BITRATE_MODE has been added to the virto encoder in
crrev.com/c/2944506.

BUG: 190336806
BUG: 181514834
Test: arc.VideoEncodeAccel.h264_192p_i420_vm
Change-Id: I95d8f9921c1ba475ea8c65760d3c18e5e2818d5e

The GTS testDynamicFramerateChangeVp8 test expects the VP8 V4L2
encoder to dynamically adjust the framerate based on the frame
timestamps during encoding. This CL makes changes to the V4L2 encoder
to monitor the time difference between subsequent frames and adjust the
framerate accordingly.

BUG: 192419592
Test: media.gts.RtcVideoCodecTest#testDynamicFramerateChangeVp8
Change-Id: Ic2f6d905345d9678765ad9db93e430d4ebddd602

This CL changes the V4L2 encode component to not try to extract H.264
NAL units from an encoded VP8/9 video stream. Parsing for NAL units in
a VP8/9 stream doesn't break encoding as an empty list is returned, but
returning an empty config update to the mediacodec framework makes the
GTS VP8 RtcVideoCodecTest fail.

BUG: 191644279
BUG: 155138243
Test: media.gts.RtcVideoCodecTest#testDynamicBitrateChangeVp8
Change-Id: I789eb0c948afaea29e1595a503d63cd3788baf1b

Originally we use "debug" group to save the configuration. However,
the value should be read-only at run-time. "ro.vendor" is a better
group for the usage case.

Bug: 189059445
Test: android.media.cts.AdaptivePlaybackTest
Change-Id: I04cfd8498b6bafdd0a4ee6ea16d002c9f50bdc0d

This CL reworks the VideoPixelFormat class that was branched
from Chrome:
- Removed all Chrome-specific references from comments
- Removed specific numbering as we don't need compatibility with Chrome
- Removed deprecated formats
- 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: I8387af0b427ebc990ec6374432f18ad732894569

This CL Moves the VideoPixelFormat files to the common code folder. In a
next step these files will be cleaned up and reworked into proper
Android code, but splitting the move into a separate CL makes the review
process a lot easier.

Note: the "accel" folder is now empty, but the folder and Android.bp
      files will be cleaned up in a next CL so we can properly clean
      up all dependencies on the v4l2_accel module.

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

This CL removes all uses of the media::ColorPlaneFormat and
media::VideoFrameLayout types that were copied from Chrome. All uses
of ColorPlaneFormat are changed to the VideoFramePlane type in
Common.h. To replace the Chrome VideoFrameLayout a much simpler type
was introduced in Common.h.

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

This CL changes all uses of the media::VideoCodecProfile type that was
copied from Chrome to their respective C2 profile counterparts. This
removes the additional conversion between C2 profiles,
VideoCodecProfile and V4L2 profiles. The video_codecs.h/cc files are
removed.

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

This CL changes the V4L2 encoder component to use the newly introduced
C2Config::PROFILE_VP8_0 profile. This profile was initially not
present, complicating code dealing with VP8.

Note: Submit after ag/13976507

Bug: 155138142
Test: arc.VideoEncodeAccel.vp8_192p_i420_vm
Change-Id: I4256a4871221d3f417b5f1a003cc9fcfdb3dcd0e

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 performs a small bit of cleanup, using std::find_if to locate
eos buffers in the work queue.

Bug: 143333813
Test: arc.VideoEncodeAccel.h264_192p_i420_vm
Change-Id: I521374dee4629ec155f0052de9bdd1549e0b51b9

This CL splits the V4L2EncodeComponent in a codec2 component and a V4L2
encoder part. This improves the encapsulation and flexibility of the
encoder and makes maintenance easier.

As a lot of the encode/drain/flush logic has been affected by the
split, various changes needed to be made:
- The drain/flush flows have been reworked.
- Various changes have been made to the input/output buffer flows to
  match the new requirements and restrictions.
- The BitstreamBuffer class is used for output, to avoid having Codec2
  logic in the V4L2 encoder class.
- A queue was introduced for work waiting for input format conversion.
- Some outdated comments have been removed.

Bug: 143333813
Test: arc.VideoEncodeAcel.* and various CTS tests
Change-Id: Ie782b74daa3662a1ce1d441b5ba5e48eaa1057d3

This CL adds support for the VP8 and VP9 codecs to the Android codec2
V4L2 encode component.

note: VP8 is currently disabled on most Intel devices due to
      b/158655609

Bug: 155138243
Test: tast run DUT arc.VideoEncodeAccel.vp8_1080p_i420 on hatch
      tast run DUT arc.VideoEncodeAccel.vp9_1080p_i420 on rammus
Change-Id: Ic3d58d711633b4ffb481813b3016d7c369a9f8f0

The codec framework initializes the output block pool in
CCodecBufferChannel::start. This change delays creation of output
buffers until after that method has had a chance to run, so that we
don't end up using the unoptimized BASIC_LINEAR pool that doesn't reuse
buffers.

Bug: 175515099
Test: Higher fps on arc.VideoEncodeAccelPerf.h264_1080p_i420_vm

Change-Id: I8657ed12a351b9f06f4c7d358aad5b433c5824b6

This CL introduces the "debug.v4l2_codec2.encode.concurrent-instances"
property which can be used to limit the maximum number of concurrent
V4L2 encoder instances, similar to ag/13168744 for the decoder.

Bug: 174530542
Test: android.media.cts.MediaCodecCapabilitiesTest#testGetMaxSupportedInstances
Change-Id: Id4cab506f783af62e68fa591db5f41d2b73a574b

This CL treats failed force keyframe requests as errors, since support
for the V4L2_CID_MPEG_VIDEO_FORCE_KEY_FRAME control was added to the
virtio encoder.

Note: don't submit before crrev.com/c/2578517

Bug: 161498590
Bug: 174444769
Test: arc.VideoEncodeAccel.h264_192p_i420_vm
Change-Id: I58ea8e9827e274be691a4f35a729894d5517c6ea

The H.264 levels currently requested by the C2 V4L2 encoder are H.264
IDC levels rather than the required V4L2 levels. This CL changes the
encoder to request the correct levels.

Bug: 174967472
Test: android.media.cts.MediaRecorderTest#testProfileAvcBaselineLevel1

Change-Id: Ic05a919a4f8a8dd1d0b0acc6577951c88c229469

This CL makes changes to treat failed framerate change requests as
errors, since VIDIOC_S_PARM is now supported in crosvm.

Bug: 173668157
Test: tast run DUT arc.VideoEncodeAccel.h264_192p_i420_vm on hatch
Change-Id: Ia7a9b94930c8faacb90b0a934e12481c2bf16d3c

When allocating input buffers the gralloc allocator talks to minigbm
which uses a stride of 64. This causes QBUF failures when queuing
buffers on the input queue as the stride does not match with what the
virtio video driver expects.

This CL makes changes to communicate the actual stride to the virtio
encoder using v4l2_pix_format.bytesperline.

Bug: 173083834
Bug: 173666696
Test: android.video.cts.VideoEncoderDecoderTest.testAvcOther0Perf0720x0480

Change-Id: I798d0bc694f5d52f19fb7056523baccdf04f91a2

When stopping the encoder the input format convertor is currently
not cleared, which triggers an assert when the encoder is restarted.

Bug: 173084485
Test: android.media.cts.MediaCodecTest#testReconfigureWithoutSurface

Change-Id: I0a9a3ef9a945597b4cd6e9ba7b505af20e51cf61

This CL makes changes to properly clear the output queue on flushing
the encoder.

Bug: 173085269
Test: android.media.cts.MediaCodecTest#testReleaseAfterFlush

Change-Id: I9225cc3652fe7dc7c5cf7577e0d599b371e55e8d

This CL removes an incorrect assert when scheduling the next encode
operation. The assert assumes the input queue will never be empty at
this point, but it's possible a prior scheduled flush operation cleared
the queue.

Bug: 173085269
Test: android.media.cts.MediaCodecTest#testReleaseAfterFlush

Change-Id: I3d9f5f7362ae59aa31a2f380ebfda7e8ab47974a

This CL makes changes to stop encoding and report an error when queuing
a buffer on the V4L2 device input queue fails.

Bug: 168276883,173083834
Test: android.video.cts.VideoEncoderDecoderTest#testAvcOther0Perf0720x0480

Change-Id: I5ccd0a001d89084e1f97c0dd7741e5ea852647d4

This CL makes changes to treat failed bitrate change requests as
errors, since support for changing the bitrate was added to the latest
version of crosvm.

Bug: 162799179
Test: tast run DUT arc.VideoEncodeAccel.h264_1080p_i420_vm on hatch
Change-Id: Iee5a8f744180775a178c1549367505a2e4be8877

This CL removes an outdated comment referring to eliminating an output
buffer copy, which was removed in ag/12208262.

Bug: 147458351
Test: tast run DUT arc.VideoEncodeAccel.h264_1080p_i420_vm on hatch
Change-Id: I33af58fe9a8a777f5a214de52fcaa7b6a6d3426a

When configuring the input format the output buffer size might be
adjusted. This CL makes changes to properly update the output buffer
size.

Bug: 162804477
Test: tast run DUT arc.VideoEncodeAccel.h264_1080p_i420_vm on hatch
Change-Id: I60de6b451eda93c1a68315b9f4dd0e7bb40a6251

This CL replaces our custom V4L2_CID_MPEG_VIDEO_H264_SPS_PPS_BEFORE_IDR
control with the V4L2_CID_MPEG_VIDEO_PREPEND_SPSPPS_TO_IDR control that
is available upstream, similar to crrev.com/c/2409058.

The V4L2_CID_MPEG_VIDEO_H264_SPS_PPS_BEFORE_IDR control is currently
not reported as supported yet by the virtio encode driver, even though
the underlying encoder will always prepend SPS and PPS to each IDR. But
this won't break anything currently as only a warning will be reported.

Bug: 162796596
Test: tast run $HOST arc.VideoEncodeAccel.h264_192p_i420_vm on hatch-arc-r
Change-Id: I11fcf06ae0dfaf72fcf10a3f4639af00e4e90973

This CL reduces the verbosity of some log statements, makes some log
statements more descriptive, and fixes an incorrect log statement.

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

The V4L2EncodeComponent expects all buffers queued on the v4l2 device
input queue to be returned before an EOS is received. This is however
not always the case, so this CL makes changes to the encoder to
account for this fact.

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

This CL adds the BufferUsage::VIDEO_ENCODER flag to the
V4L2EncodeComponent's input and output buffers so they are properly
synced between the encoder and crosvm.

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

This CL adapts the V4L2VideEncodeComponent to import output buffers
directly as V4L2_MEMORY_DMABUF into the v4l2 output queue, rather than
using V4L2_MEMORY_USERPTR. This eliminates a copy of the encoded output
data as we encode directly into the DMAbuf.

Bug: 143333813
Test: tast run $HOST arc.VideoEncodeAccel.h264_192p_i420_vm
Change-Id: I4d60a943869566362a55cd47d0bb9e1f7a97cf28

This CL removes the code that prepends SPS/PPS to IDR frames, as this
is already handled by the Chrome video encoder.

Note: When we upstream this code we might want this functionality, but
as ag/12208262 makes changes that would require us to rewrite this
logic we can reintroduce it when we decide it's necessary.

Bug: 143333813
Test: tast run $HOST arc.VideoEncodeAccel.h264_192p_i420_vm
Change-Id: Ib0f7fac6ac23fca1b88c3a026989338ca2aaf95f

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 CL adapts the V4L2VideEncodeComponent to import input buffers
directly as V4L2_MEMORY_DMABUF into the v4l2 input queue, rather than
using V4L2_MEMORY_USERPTR.

Bug: 143333813
Test: tast run $HOST arc.VideoEncodeAccel.h264_192p_i420_vm
Change-Id: I5efe9cdf50505a74e1fc97a8b48c94870e224e38