All other AndroidX libraries have already increased their min SDK to
21.
This change renames private symbols to remove `V21` suffixes and
similar, but doesn't change public or protected symbols with similar
names, to avoid needless breakages/churn on users of the library.
Some of the dead code removal is more complex, so I've split it out
into follow-up changes to make it easier to review.
PiperOrigin-RevId: 651776556
Also promote all H.265 constants to be public in `NalUnitUtil` with
`H265_` prefixes, for consistency.
A lot of these names are used in h.265 too (and `NalUnitUtil` handles
both), but with different values, so this rename aims to avoid
accidentally using an h.264 value in an h.265 context.
PiperOrigin-RevId: 651774188
MediaCodecRenderer might not be able to determine whether a sample
is last in time. Do not use decoder input skipping optimization
for buffers close to media end duration in order to ensure
last frame is rendered.
PiperOrigin-RevId: 651757814
This is because the force EOS workaround for videos is longer than the original
muxer timeout. This way the apps depending on Transformer won't have to manually
set the muxer timeout on emulators.
PiperOrigin-RevId: 651355755
The integration with `SubtitleTranscodingExtractorOutput` has been
moved inside the relevant `Extractor` implementations instead.
PiperOrigin-RevId: 651213564
When testing locally it seemed that upgrading KGP to `1.9.20` resolved
this, but testing again confirms this was incorrect, so the problem
was reintroduced in 00d1e70a34.
This change reverts back to KGP `1.9.0` (since upgrading didn't help)
and instead implements the workaround suggested in
https://issuetracker.google.com/278545487. The workaround is now in
the `lib-common` `build.gradle` file, which is transitively depended
on by all modules (and therefore all apps that use this library), so
there's no need for any developer action, and so the release note is
removed.
Issue: androidx/media#1262
PiperOrigin-RevId: 651066418
VideoSink.registerInputFrame is now called for every input frame (not
only the ones that should be rendered to the input surface) because it's
the VideoSink that decides whether it wants the frame to be rendered.
PiperOrigin-RevId: 651049851
In order for DASH playback to benefit from
FLAG_READ_WITHIN_GOP_SAMPLE_DEPENDENCIES, the fMP4 extractor flag
must be set. The smallest API change that allows this is to add an
experimental method to BundledChunkExtractor.
Add a dash end-to-end test to verify that video frames are skipped at
decoder input.
PiperOrigin-RevId: 651046676
As reported in Issue: androidx/media#1493 we already use `HEADSETHOOK` to start
waiting for a double-tap, but we don't consider it for the second tap.
Similarly, we previously considered `PLAY` for the second tap, but not the first.
Only `HEADSETHOOK` and `PLAY_PAUSE` are
[documented](https://developer.android.com/reference/androidx/media3/session/MediaSession#media-key-events-mapping)
to transform double-tap to `seekToNext`. So this change removes the
`PLAY` detection from the second tap.
#cherrypick
PiperOrigin-RevId: 651017522
Stereo view information is stored in the 3D reference displays information SEI and the optional vexu box. Parsing of the SEI and vexu box is added, and based on the parsed info, proper mapping of primary/secondary view to left/right eye is determined.
PiperOrigin-RevId: 651002190
Add support for MPEG4 codec to enable muxing video encoded with the mp4v-es codec. Use esdsBox method to generate esds box required for Mp4v box.
PiperOrigin-RevId: 651000744
Some external media files have CodecSpecificData greater than 128 bytes. Currently, that size
isn't fitting in one byte. Hence, added support to store large CodecSpecificDataSize, as per
ISO standard, by extending to more than one byte as required.
PiperOrigin-RevId: 650972472
The operation almost always acquires resources straight-away,
for example a new thread or file access. This means starting
many metadata retrievals in parallel easily causes resource
contention. This problem can be alleviated by limiting the
maximum number of parallel retrievals.
Local testing showed a 20% speedup for local file retrievals
when limited to 5 in parallel. Any more parallel retrievals
did not show any improvement or started getting slower again
the more operations are allowed.
PiperOrigin-RevId: 650674685
MetadataRetriever is often used in a loop to retrieve data about many
items in a directory for example. In such cases, it's wasteful to
start a new 'playback' thread for each retrieval, in particular since
this thread is doing almost nothing (just triggering loads and handling
events). This change re-uses an existing thread if one exists already.
PiperOrigin-RevId: 650633343
During a seek, or when playing a media with clipped start,
MCVR encounters preroll decode-only buffers that are not rendered.
Use C.BUFFER_FLAG_NO_OTHER_SAMPLE_DEPENDS_ON_THIS to determine
whether a decode-only buffer is unused as reference.
These buffers can be dropped before the decoder.
When this optimization is triggered, increment
decoderCounters.skippedInputBufferCount.
Tested in ExoPlayer demo app on "One hour frame counter (MP4)"
after enabling extractorsFactory.setMp4ExtractorFlags(
FLAG_READ_WITHIN_GOP_SAMPLE_DEPENDENCIES);
Observe: "sib" increases on each seek.
PiperOrigin-RevId: 650566216
Changes to FragmentedMp4Extractor to parse additional sample dependency
information and mark output samples as "no other samples depend on this".
Only applies to H.264 tracks.
Controlled by new fMP4 flag: FLAG_READ_WITHIN_GOP_SAMPLE_DEPENDENCIES
PiperOrigin-RevId: 650538377
The idea was to not even write any samples to SampleQueues as
they are not needed during the metadata extraction process.
However, this is not easily possible as long as we use our
existing Extractors and MediaSource/Periods for loading given
how deeply ingrained the extraction of samples is in these
classes. For most common formats like MP4, no samples will be
extracted anyway as they can finish the prepare step without
reading any samples.
PiperOrigin-RevId: 650529371
Leb128 is a little-endian long of variable byte length. The format is used during the extraction of the size of the OBU configuration for the iacb configuration box.
PiperOrigin-RevId: 650295002
Once a service is started as a foreground service, it must
be started into the foreground. This means an app can not
suppress a play command arriving from the `MediaButtonReceiver`
once the receiver has started the service.
This change adds a method to the `MediaButtonReceiver` that
allows app to suppress starting the service to not get into
this situation of wanting to suppress the play command after
the service is already started.
Issue: androidx/media#1528
PiperOrigin-RevId: 650280025
We now depend on Kotlin from both `annotation` and
`annotation-experimental`, so it's not really possible to avoid
depending on it from any module now.
PiperOrigin-RevId: 650251094
Upon the call of `PreloadMediaSource.preload`, the source will periodically check the source refresh or period loading error, and trigger `PreloadMediaSource.PreloadControl.onPreloadError`. For now, the `DefaultPreloadManager` will skip the problematic source and continue to preload the next source. The checking of the error will be terminated when the source stops preloading or releases.
PiperOrigin-RevId: 650195817
This utility helps apps to forward to another Player while overriding
selected behavior or state values. The advantage to a ForwardingPlayer
is that the SimpleBasePlayer base class keeps ensuring correctness,
listener handling etc.
The default forwarding logic tries to stay as close as possible to the
original method calls, even if not strictly required by the Player
interface (e.g. calling single item addMediaItem instead of
addMediaItems if only one item is added).
Issue: androidx/media#1183
PiperOrigin-RevId: 650155924
Since the muxer supported only AAC audio codec, the esdsBox was unconditionally created within the audioSampleEntry. This CL refactors the box creation logic by moving it to the codecSpecificBox method. This is to make adding support for new audio codecs easier.
PiperOrigin-RevId: 650130935
The Timeline, Tracks and MediaMetadata are currently provided
with a list of MediaItemData objects, that are a declarative
version of these classes. This works well for cases where
SimpleBasePlayer is used for external systems or custom players
that don't have a Timeline object available already. However,
this makes it really hard to provide the data if the app already
has a Timeline, currently requiring to convert it back and forth
to a list of MediaItemData.
This change adds an override for `State.Builder.setPlaylist`
that allows to set these 3 objects directly without going
through MediaItemData. The conversion only happens when needed
(e.g. when modifying the playlist).
PiperOrigin-RevId: 649667983
The value is basically a duplicate of the information stored
in the timeline field. Reducing the source of truth to the
single Timeline also allows acceptance of other Timelines in the
future that don't necessarily have the helper structure of
the playlist.
To allow apps to retrieve the current playlist as it is, we
add a getter instead.
PiperOrigin-RevId: 649667281
Changes to Mp4Extractor to parse additional sample dependency information
and mark output samples as "no other sample depend on this".
Only applies to H.264 tracks.
Controlled by new mp4 flag: FLAG_READ_WITHIN_GOP_SAMPLE_DEPENDENCIES
PiperOrigin-RevId: 649640184
