If outBuffer is specificed, displayStride is the stride of the
outBuffer (line 595). Then, the "Output buffer too small" check
ends up comparing a buffer's width to the buffer's own stride
which effectively requires that a buffer's width is equal to it's stride.
Bug: 155485791
Test: cts -t android.media.cts.DecoderTest
Change-Id: Ia66591f816aac0d8aad5c1b5b9a0aeff2cc80185
Merged-In: Ia66591f816aac0d8aad5c1b5b9a0aeff2cc80185
If outBuffer is specificed, displayStride is the stride of the
outBuffer (line 526 for avc and line 521 for hevc). Then, the
"Output buffer too small" check ends up comparing a buffer's width
to the buffer's own stride which effectively requires that a
buffer's width is equal to it's stride.
For android.media.cts.DecoderTest#testCodecBasicHEVC, the test
has an outBuffer with width 720 and stride 768 which fails the
check.
Bug: b/146515640
Test: cts -t android.media.cts.DecoderTest
Change-Id: I732f77445cad5390895c8e43f46d11c423c9b2e4
Instead of assuming stride to be a multiple of 64, use the value
returned by graphic view.
These codecs require chroma stride to be half of luma, hence the luma stride
should be a multiple of 32. Hence request for stride that is multiple of
32, then use returned stride.
This is needed where allcoated buffer has a stride that is multiple of
128.
Test: atest android.media.cts.DecoderTest
Test: Test decoding clips with dimensions that are not multiples of 16
Bug: 144190181
Change-Id: I08912396e495326fca787e8ae0b47256505210ca
Merged-In: I08912396e495326fca787e8ae0b47256505210ca
In order to support signalling lower levels, default dimensions
and frame rate are set to smaller values, such that minimum level
calculations done with default values still stay at lowest level
supported
Bug: 149360064
Bug: 151423508
Test: atest android.media.cts.MediaRecorderTest#\
testProfileAvcBaselineLevel1
Change-Id: Ic86e5d728d99652ea4e4a46df4f46b3ff3b357ac
Merged-In: Ic86e5d728d99652ea4e4a46df4f46b3ff3b357ac
C2 plugin for avc decoder is now updated to appropriately
handle both types of interlaced content, i.e. sent as one
field per one input buffer and sent as two fields per one
input
- Allow bytes consumed to be returned as zero to handle dangling fields
- Do not ignore trailing bytes after decode call as that data may
contain next field
- Ensure input buffer contains at least 4 bytes
- After signalling new output delay, do not feed the input again
Bug: 135146280
Bug: 152087140
Test: poc in bugs
Test: atest android.media.cts.DecoderTest
Change-Id: I1f6a12878eeebb604a16f8e9edcdf3d631ef5afc
Merged-In: I1f6a12878eeebb604a16f8e9edcdf3d631ef5afc
Bug: 135515629
Test: set forceGoogleEncoder to true in VideoCodecTestBase.java
Test: atest android.media.cts.VideoCodecTes.testSyncFrameHEVCCBR
Change-Id: I869506d13d695b90a280d9bcd42c307043269b74
CHECK() for color format has been replaced with appropriate error
handling.
Bug: 117625412
Bug: 152070124
Test: stagefright -s -S /sdcard/cformat.webm
Test: stagefright -s -S /sdcard/crowd_640x360p50f32_frmPar_1x1.webm
Change-Id: I1fe0be54f9910fd98ff4db9240b4dcfd09888ffb
Merged-In: I1fe0be54f9910fd98ff4db9240b4dcfd09888ffb
Codec2 Vorbis codec was dynamically linking with libvorbisidec.
By linking statically instead, unused code can be stripped, reducing
size and improving relative coverage.
Test: CTS
Bug: 149042245
Change-Id: If1203ecf2d488bd285cb469f786a14a0eb64a7f4
(cherry picked from commit 048d7c3229170a9a0cc4f72c2a47584d93dc9551)
For MPEG-D DRC the default value of the boost and attenuation
factors is 127. For MPEG-4 DRC the default value is 0. In the
current DRC presentation mode wrapper, setting boost or attenuation
factor to 0 doesn't work for MPEG-DRC, use value -1 instead.
Fix Target Reference Level set to -1 as a valid value for disabling
loudness normalization.
Bug: 148385721
Test: atest DecoderTestXheAac DecoderTestAacDrc
Change-Id: I33479072c508b5700c0b35f389802dc17b2b4536
Root Cause:
Google C2 H264/H265 decoder request 64-aligned stride from graphic block; but ARM GPU would return
with 128-aligned stride when input height ONLY satisfies 2-aligned (e.g. 130).
Solution:
Revise stride alignment from 64 to 128 of C2 H264/H265 decoder
Bug: 142924202
Test: Build C2 Codec
Test:
run cts -m CtsMediaTestCases -t android.media.cts.ImageReaderDecoderTest#testGoogH264Image
run cts -m CtsMediaTestCases -t android.media.cts.ImageReaderDecoderTest#testGoogH264ImageReader
run cts -m CtsMediaTestCases -t android.media.cts.ImageReaderDecoderTest#testGoogH265Image
run cts -m CtsMediaTestCases -t android.media.cts.ImageReaderDecoderTest#testGoogH265ImageReader
Change-Id: I6eaff1b858e031b64744bc67d8aee5cc51cfd92d
Root Cause:
Google C2 H264/H265 decoder request 64-aligned stride from graphic block; but ARM GPU would return
with 128-aligned stride when input height ONLY satisfies 2-aligned (e.g. 130).
Solution:
Revise stride alignment from 64 to 128 of C2 H264/H265 decoder
Bug: 142924202
Test: Build C2 Codec
Test:
run cts -m CtsMediaTestCases -t android.media.cts.ImageReaderDecoderTest#testGoogH264Image
run cts -m CtsMediaTestCases -t android.media.cts.ImageReaderDecoderTest#testGoogH264ImageReader
run cts -m CtsMediaTestCases -t android.media.cts.ImageReaderDecoderTest#testGoogH265Image
run cts -m CtsMediaTestCases -t android.media.cts.ImageReaderDecoderTest#testGoogH265ImageReader
Change-Id: I6eaff1b858e031b64744bc67d8aee5cc51cfd92d
Instead of allocating a fixed size output buffer, allocate it as per
width and height of the input being encoded. To ensure for very low
resolutions, this size doesn't become too small, use a minimum size of
512K Bytes.
Bug: 144928581
Test: h264 related tests in android.media.cts.VideoEncoderTest
Change-Id: I01c1aa03456043824354005f1708f07b3268d97e
mpeg4 encoder doesn't support a stride that is not equal to align(width, 16)
In such cases copy the input to an intermediate buffer and use that for
encoding
Bug: 143506888
Bug: 136962421
Bug: 139921039
Test: tested few nv12 and i420 encoding
Change-Id: I5a8adfc48aff79f52852be94bb46c10e7f9a0469
(cherry picked from commit a6dfef8a44)