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

Currently the C2Config::LEVEL_AVC_4_2 level is not advertised as
supported value for the C2_PARAMKEY_PROFILE_LEVEL parameter. This
causes the V4L2 encoder to use the next supported level LEVEL_AVC_5,
making the EncoderProfileLevelTest#testValidateProfileLevel CTS test
fail.

BUG: 188415875
Test: EncoderProfileLevelTest#testValidateProfileLevel
Change-Id: Ifd5caa6d70c592a7379260876600b075432ac7d8

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

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 removes a workaround that was added to tackle a quality issue
in b/114332827. This workaround causes the android.mediav2.cts.
EncoderProfileLevelTest#testValidateProfileLevel[6(video/avc)]
test to fail.

It's not clear whether the issue is still present so some quality check
CTS tests might start failing, but we should tackle these issues at the
source.

Bug: 184015100
Test: android.mediav2.cts.EncoderProfileLevelTest
Change-Id: I55f275af4a421509a776e39bed669365159ba2ee

This CL removes all uses of the media::VideoCodec type that was copied
from Chrome, in favor of the VideoCodec definition in
common/VideoTypes.h. The media::VideoCodec type is removed.

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

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 cleans up the video_encode_accelerator.h/cc and
video_decode_accelerator.h/cc files. These files were copied from
Chrome to help with the development of the V4L2 encoder and decoder,
but most off their functionality has already been removed in a previous
CL. The remaining functionality is integrated into the V4L2Device so
these files can be removed now.

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

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

This CL Move the V4L2 device and V4L2 device poller 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.

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

This CL adds C2_PARAMKEY_COMPONENT_KIND parameter for both decode and
encode components.

Bug: 183910489
Test: android.media.cts.AdaptivePlaybackTest#testH264_adaptiveDrc

Change-Id: I8a90ed95aefa7d6dd018ead3ec0dfa79d4960ee9

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

This CL removes the BufferUsage::VIDEO_ENCODER flag from input buffers.
Currently the format convertor is always enabled as the encoder on
Chrome side only supports the NV12 format. This means it's not useful
to add the VIDEO_ENCODER buffer flag to input buffers. Currently
zero-copy is not supported yet, so when using that flag an additional
buffer will be allocated on host side and a copy will be performed
between the guest and host buffer to keep them in sync. This is
wasteful as the buffer is only used on guest side by the format
convertor which converts and copies the buffer into another buffer.

Additionally this causes issues on hatch as the YV12 format is used
which is not supported by minigbm on hatch. (see b/162796596)

Bug: 162796596
Test: tast run $HOST arc.VideoEncodeAccel.h264_360p_i420_vm on
      hatch-arc-r and verified encoded video
Change-Id: Iffcaafbe12fa1f9af53ac7c4e88ee98ec40aedec

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 introduces the first version of the new codec2 V4L2 encoder.
The V4L2EncodeComponent currently only supports H264, support for
additional formats will introduced later.

The encode component is developed and tested on ARC++ and the initial
version is not functional yet on ARCVM. The changes required to fully
enable the encoder on ARCVM (such as support for DMABufs) will be
introduced in follow-up CLs.

Currently the component makes heavy use of Chromium helpers as it's
based on the Chromium V4L2VideoEncodeAccelerator, but in the future
the amount of dependencies will be reduced.

The new V4L2 encoder is currently not enabled by default, which requires
additional changes in media_codecs_c2.xml.

Bug: 143333813
Test: mmm external/v4l2_codec2
Change-Id: I59ba52e8f85aa40c8d23a451fb2842a7a421412a

This CL performs minor cleanup in the C2EncoderInterface class.

Bug: 147457498
Test: arcvideoencoder_test_arm on hana
Change-Id: I888d9e3a4605dfebf3330d771ea42062c6c5b41b

This CL moves the interface defined in C2VEAComponent::IntfImpl to a
dedicated C2EncoderInterface, so it can be reused by the new
C2V4L2EncoderComponent.

Bug: 147457498
Test: m -j32
Change-Id: I67409c4c655a572da713d677d99bdc79d6847943