Bug: 135133301
Test: I902de3410c45a21cf27b48a02cdc5d514b7ada60
AImageDecoder allows decoding an image multiple times, using different
settings (e.g. color type) each time, using the same underlying SkCodec.
After finishing decoding the image, HeifDecoderImpl discards its
MediaMetadataRetriever in order to clean up resources. Hang onto the
input data, so that if a client attempts to decode again, the Impl can
recreate its MediaMetadataRetriever to perform a second decode.
If the client is using the same output color, no new
MediaMetadataRetriever is needed, since it can continue to use the
original video frame output.
When called from Java, the HeifDecoderImpl will be quickly discarded
anyway, so holding on to the input data until that discard should not be
a problem.
Change-Id: I2ca01a006215c1e6f6472c5e6a4df4e2155a3b11
DrmInitialization only needs to be called on PlayerServiceFileSource
and PlayerServiceMediaHTTP, so just have those initialize the forward
lock engine automatically, which removes the need to have this in the
IDataSource interface.
Test: atest cts/tests/tests/drm/src/android/drm/cts/DRMTest.java
Change-Id: I344f46b65b5c473930b16b9b4041e4897384dc18
This change renames the IMemory raw pointer accessors to
unsecure*() to make it apparent to coders and code reviewers
that the returned buffer may potentially be shared with
untrusted processes, who may, after the fact, attempt to
read and/or modify the contents. This may lead to hard to
find security bugs and hopefully the rename makes it harder
to forget.
The change also attempts to fix all the callsites to make
everything build correctly, but in the processes, wherever the
callsite code was not obviously secure, I added a TODO requesting
the owners to either document why it's secure or to change the
code. Apologies in advance to the owners if there are some false
positives here - I don't have enough context to reason about all
the different callsites.
Test: Completely syntactic change. Made sure code still builds.
Change-Id: I5fb99aa797c488406083178a6b05355d98710d3b
If sample duration is not available, use the average
frame duration of the sequence; if that's not available
default to 30fps.
bug: 120414514
bug: 139815242
test: test some 25fps heif sequence files, the reported
duration should be 40ms instead of the default 33ms.
Change-Id: I5ddf0a6cbfb44021dee2955badf3f2772586bb1e
Add an api to IMediaMetadataRetriever to decode image rect.
It will reuse the same full frame IMemory, and decode only
the requested rect. For now, StagefrightMetadataRetriever
will only allow decoding of rect that's a full row of tiles,
and the requested must be issued sequentially (i.e. no
arbitrary rects). When the extract side is fixed to allow
seeking by tiles, it can be extended to allow arbitrary
rects.
This allows HeifDecoderImpl (on client side) to start
processing the getScanlines in parallel with the decoding.
Test: CTS MediaMetadataRetrieverTest;
Manual testing of HEIF decoding of files with or without tiles;
Manual testing of HEIF thumbnails generation in Downloads app.
bug: 78475896
Change-Id: I820b21cdf33f80593ee6092d8e1ba68b3beb65dd
The display dimensions from MPEG4Extractor is applied on top
of width and height for scaling, it's not for cropping. For
bitmap uses we have to use width and height, the frame from
media server is not scaled.
bug: 73172046
Test: test app in bug; open folders with heif files in Photos.
Change-Id: I3d7f1492d08d48876836ccc05b6eb4de0d0c0f9a
(cherry picked from commit 1a6c11685d)
The display dimensions from MPEG4Extractor is applied on top
of width and height for scaling, it's not for cropping. For
bitmap uses we have to use width and height, the frame from
media server is not scaled.
This required porting over some fixes from master to fix the
display size vs. image size reporting, otherwise images with
grids may show a black border at the bottom or right.
bug: 73172046
Test: test app in bug; open folders with heif files in Photos
and Downloads; CTS MediaMetadataRetrieverTest.
Change-Id: I3d7f1492d08d48876836ccc05b6eb4de0d0c0f9a
Adding support for two new sets of APIs on MediaMetadataRetriever:
- getImageAtIndex() and getPrimaryImage()
- getFrameAtIndex() and getFramesAtIndex()
Outline of changes:
- Proper indexing of all displayable still images, so that they
can be retrieved by getImageAtIndex()
- Exposing still images as "image/x.android.heic" tracks in
MediaExtractor with necessary descriptive keys (such as "grid-*")
- Support to retrieve video frames by absolute index instead
of timestamps, as image use cases mostly are interested in
getting the images and care less about timing.
- Support to retrieve video frames in batches because retrieving
one frame at a time is inefficient.
- Refactor image / frame decoding code into FrameDecoder, and split
still image decoding and video sequence decoding into to sub
classes to facilite future development.
bug: 63633199
test:
cts-tradefed run cts-dev --module CtsMediaTestCases --compatibility:module-arg CtsMediaTestCases:include-annotation:android.platform.test.annotations.RequiresDevice
Change-Id: I2fe8519fb6907f315a8b513921fc1cc7f436e28d
- MediaSource, DataSource and MediaExtractor are moved to
libmediaextractor so that they can be used by extractor
implementations without depending on libmedia and libstagefright.
- XXXFactory classes has been added in order not to expose CreateXXX
methods in libmediaextractor.
- avc_utils is moved to libstagefright_foundation since most of
extractor implementations are relying on that.
Test: build + post submit media CTS tests
Bug: 65851881
Change-Id: I7d5cf18dd25abc10478ac3f6e7d1828ad023e3fb
Extractor dtor on media.extractor side happens asynchronously with the
dtor of StagefrightMetadataRetriever. If the extractor calls back into
the DataSource after mediaserver side released the reference to it, the
binder transaction could get stuck.
Adding an explicity release() and call it before StagefrightMetadataRetriever
continues to destruct the DataSource. Only implement it for MPEG4Extractor
to avoid impacting other extractors at this stage.
Also adding some code to aggressively release the extractor and data
source in HeifDecoderImpl to free up memory.
bug: 65463215
Change-Id: I84c442a1e010dd37a976af5453a353e43f672e22
Also, reuse decoding result if decode is called again. Currently
decode only retrieves primary picture, so there is no point to
go to metadata retriever again.
Bug: 64077740
Change-Id: I9243de396957f4d717c386bbaa8692494d624998
- define platform-independent HeifDecoder interface to be used by
skia to decode heif
- add android implementation of HeifDecoder utilizing media framework
MediaMetadataRetriever.
bug: 64077740
Change-Id: I87d803a16c117ab081adbd7c88c1bdb3c4318d66
Leon Scroggins III
Marco Nelissen
Ytai Ben-Tsvi
Chong Zhang
Sungtak Lee
Dongwon Kang