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

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

Originally we forced the component into error state if there are any
pending frames when drain is done. That means these frames are either
no-show frames or dropped. It doesn't affect the following decoding.
This CL changes to abandon pending frames instead of reporting error.

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

Change-Id: I18511f14f70579718f434f316701ee1b77c1f6f0

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 expands the simple NALParser to support parsing color aspects
from the SPS NAL unit. The V4L2 decode component is adapted to use this
new NALParser rather than the Chrome parser. This allows us to remove
the Chrome H.264 parser and its associated dependencies in a subsequent
CL, removing a lot of code.

Bug: 155138142
Test: arc.VideoDecodeAccel.* and arc.VideoDecodeAccelPerf.* on hatch
Change-Id: Icbfa63478980ab2b2d1bf2d46697359a0ac92937

This CL polishes the logic of start and stop, including:
1. Remove timeout waiting:
CCodec framework already has timeout for calling component's method,
so we don't need the timeout again.

2. make release() not call stop().
Originally release() calls stop() directly, but release() can skip
some tasks in stop(). Actually release() should do the same clean-up
as destructor does.

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

Change-Id: I7cdb0037115ab308e7038fa95fdcfdf0133ac53e

Originally, the definition of C2BufferQueueBlockPoolData is hidden at
cpp file. C2VdaBqBlockPoolData has to handle the ownership transition
itself with extra workaround.

At ag/13473071, we expose C2BufferQueueBlockPoolData at header file.
This CL makes C2VdaBqBlockPoolData inherit C2BufferQueueBlockPoolData
directly. With this CL, C2VdaBqBlockPoolData could share the same
logic of the ownership transition.

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

Change-Id: Ib73b2f8bc36bbd9724523624415551a7efadda73

Originally V4L2DecodeComponent does nothing when V4L2Decoder reports
aborted decoded request. The corresponding C2Work is not cleared from
|mWorksAtDecoder|.

This CL changes to report the aborted C2Work with adding the flag
C2FrameData::FLAG_DROP_FRAME.

Bug: 177627914
Test: android.media.cts.MediaRandomTest#testPlayerRandomActionH264

Change-Id: I236e434b2df1567bd5cf96511f611a80f8b198b1

|mWorksAtDecoder| is for storing the C2Works that pass to
V4L2Decoder::Decode(). After a work is finished decoding, the
callback will be called, and V4L2DecodeComponent erase the
C2Work from |mWorksAtDecoder|.

Originally, we store C2Work after calling V4L2Decoder::Decode(). So
it's possible that the callback is called before inserting the C2Work
into |mWorksAtDecoder|. This CL fixes this issue.

Bug: 177627914
Test: android.media.cts.MediaRandomTest#testPlayerRandomActionH264

Change-Id: I0e496c8d1e37798a5efe153436d56f343e6ac500

Handle overflow when validating the requested video frame's area.

Bug: 177697115
Test: android.security.cts.StagefrightTest#testStagefright_cve_2016_6712

Change-Id: I3ff9ce21490db542c082edd4372f0824f301e459

Bug: 174530542
Test: android.media.cts.MediaCodecCapabilitiesTest#testGetMaxSupportedInstances

Change-Id: Ie9eaa9422c387460c04632a95cb7d8b7bb1f91b2

The destructor joins mDecoderThread to prevent use-after-free errors.
However, some of the tasks that mDecoderTaskRunner executes try to
call V4L2DecodeComponent::shared_from_this, which can fail because
creating a shared pointer once an object's destructor has already
started running is not safe.

This CL fixes this issue by storing a weak_ptr at mDecoderTaskRunner.
We lock the weak_ptr to get the shared_ptr when the task on
mDecoderTaskRunner needs.

Bug: 172025534
Test: android.media.cts.AdaptivePlaybackTest#testH264_*
Change-Id: Ib35efbdd8e47cbee6455b5673bb8303384fbb086

This CL introduces a new property
"debug.v4l2_codec2.decode.concurrent-instances" used to limit the
maximum concurrent instances of V4L2DecodeComponent.

Bug: 174530542
Test: android.media.cts.MediaCodecCapabilitiesTest#testGetMaxSupportedInstances

Change-Id: I92d6c0637fad3fb96333a2e457a4894218045678

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

This CL removes the duplicate HalPixelFormat and InputCodec types in
common.h that are also present in VideoTypes.h.

VideoTypes.h is moved to the common/ folder so it can also be used by
other classes.

note: Submit together with ag/12467730

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

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

Malicious video playback might set extremely large resolution during
decoding, to exhaust the system memory.

In this CL, V4L2DecodeComponent checks if the resolution of the output
buffers are larger than the maximum supported size 4096x4096. If so,
V4L2DecodeComponent will notify the Codec2 framework that error occurs
and exit gracefully.

Bug: 157113946
Test: pass tast.arc.VideoDecodeAccel.h264_vm
Change-Id: I94a5223d7d3d734ffca06064cf375944e28f68b1

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

The V4L2 stateful API requires the caller pass the same buffers to the
output queue slot. Originally we use C2PooledBlockPool for byte buffer
mode, but C2PooledBlockPool cannot get buffer identifier.

This CL switches to use C2VdaPooledBlockPool, which guarantees to
return a fixed set of buffers and could query the buffer index.

Bug: 161770200
Test: pass e2e test
Change-Id: Ief2bdd9ceb6655cd47627ccf6c239a1e6d73482e

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

Originally VideoFramePool shared the same thread with V4L2Decoder. It
turned out the performance is pretty bad, many frames were dropped.

In this CL, VideoFramePool creates a dedicated thread and fetch
GraphicBlock on this thread.

Bug: 146406514
Test: pass e2e test

Change-Id: I3c51cf1ce1d8e40fb52ad947d779e8c0ad2f754c

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