Lint somehow complains that the integer resulting from the bit-manipulation shouldn't be passed as an @IntDef parameter.
#cherrypick
PiperOrigin-RevId: 648687698
(cherry picked from commit afe3826d7c4b79acfe0fd165ac1940261a147040)
This change extends the error replication to a given set of
error codes (not only authentication error), but only
replicates an error if the caller of the service `Callback`
is a legacy controller. It also makes error replication
configurable so that apps can opt-out and report errors
manually instead, or define the error codes for which
replication is enabled.
The change also removes the restriction of `sendError` only
being available for Media3 controllers. Instead, sending an
error to a legacy controller updates the platform playback
state in the same way as sending the error to the media
notification controller.
#cherrypick
PiperOrigin-RevId: 648399237
(cherry picked from commit 70c063905c0831c072cb9e1fa90bfbc1fd70aa68)
Upon track transition of offloaded playback of gapless tracks, the framework will reset the audiotrack frame position. The `AudioTrackPositionTracker`'s `AudioTimestampPoller` must be made to expect the reset and cache accumulated sum of `AudioTimestamp.framePosition`.
#cherrypick
PiperOrigin-RevId: 647294360
(cherry picked from commit a58e77a5a63d51c8cb9419fc59a7f0c7459fcafe)
When handling a playback error that originates from a future item in
the playlist, we added support for jumping to that item first,
ensuring the errors 'happen' for the right 'current item'.
See 79b688ef30.
However, when we add this new position discontinuity to the
playback state, there may already be other position discontinuities
pending from other parts of the code that executed before the
error. As we can't control that in this case (because it's part
of a generic try/catch block), we need to send any pending
updates first before handling the new change.
Issue: androidx/media#1483
PiperOrigin-RevId: 646968309
(cherry picked from commit 727645179b3c26e495540f4445216fd035cc7654)
Setting a `null` value doesn't remove the key as expected per the `MediaFormat` API documentation, using the `removeKey` method instead which is only available starting API level 29.
PiperOrigin-RevId: 646462402
(cherry picked from commit 12c42585d25d4c51bc5d022aa282d4d36b8e1ff2)
ExoPlayer used to call `stop()` before `release()`. This was removed in
<unknown commit>.
A framework bug introduced in Android 11 (API 30) resulted in some
DRM -> clear transitions failing during `MediaCodec.configure()`. An
investigation in Issue: google/ExoPlayer#8696 and b/191966399 identified that this was
due to `release()` returning 'too early' and the subsequent
`configure()` call was then trying to re-use a `Surface` that hadn't
been fully detached from the previous codec. This was fixed in
Android 13 (API 33) with http://r.android.com/2094347.
ExoPlayer worked around the framework bug by adding an arbitrary 50ms
sleep after a failed codec initialization, followed by retrying. This
was enough to resolve the problem in the test scenario on a OnePlus
AC2003.
Issue: androidx/media#1497 points out that 50ms might not be the appropriate delay
for all devices, so it's an incomplete fix. They suggested re-adding the
`MediaCodec.stop()` call instead. This also reliably resolves the issue
on the OnePlus AC2003 (with neither workaround in place, the problem
repros almost immediately).
PiperOrigin-RevId: 646461943
(cherry picked from commit 5fcc7433a1f188c9644d4430a828a49d06c993cb)
Extractors should not report additional tracks once they called
ExtractorOutput.endTracks. This causes thread safety issues in
ProgressiveMediaPeriod where the array of sample queues is
extended while the playback thread accesses the arrays.
Detecting this problem early is beneficial to avoid unexplained
exceptions later one. In most cases where this may happen (namely
TS extractors finding new tracks), it's better to ignore the new
tracks instead of failing completely. So this change adds a
warning log message and assigns a placeholder output.
Note: The same workaround already exists in HlsSampleStreamWrapper
and MediaExtractorCompat.
Issue: androidx/media#1476
#cherrypick
PiperOrigin-RevId: 646427213
(cherry picked from commit 18e631ff790e0e9b3630ea8e36efb468474d0877)
The two arrays need to have the same length and the selection
must match in their nullness (unless for TYPE_NONE
renderers). Clarify this more clearly in the docs and add
new asssertions for it. This avoids that the player is failing
in obscure ways much later.
Issue: androidx/media#1473
#cherrypick
PiperOrigin-RevId: 646086833
(cherry picked from commit 71ef848ec3fa4409f3cdf797226c2a51ecd15da6)
The test is flaky because the decoding process in the renderer
depends on some timing from MediaCodec beyond our control and
the new keyframe added in the test is sometimes 'dropped' when
it arrives too late.
We can fix this by controlling the test progress a bit more
tightly: first rendering with the same current time until the
key frame is processed and then start increasing the time
until we've reached the end.
#cherrypick
PiperOrigin-RevId: 646064352
(cherry picked from commit ada4dc982fac32a57db069341f1f51c6a3bb6cc5)
Previously we assumed that `surfaceSyncGroupV34` was always non-null on
API 34, but this isn't true in edit mode. Instead we add an explicit
null-check before accessing it. We don't need to null-check it at the
other usage site because we are already null-checking `surfaceView` (via
`instanceof` check).
Issue: androidx/media#1237
#cherrypick
PiperOrigin-RevId: 645008049
(cherry picked from commit 99803066ea6d375f5527e0953aad4ecd91fbac3c)
Some cases are not handled correctly at the moment:
- Pausing during suppressed playback should not clear the
suppression state.
- Transient focus loss while paused should be reported as
a playback suppression.
Issue: androidx/media#1436
#cherrypick
PiperOrigin-RevId: 644971218
(cherry picked from commit e84bb0d21cd114c5b726c6c3d799b194df068a14)
Sometimes the reason for the current state may change. If we don't
report this again, users have no way of knowing that the reason
changed.
Also adjust ExoPlayerImpl and MediaControllerImplBase accordingly.
SimpleBasePlayer already adheres to this logic.
#cherrypick
PiperOrigin-RevId: 644970236
(cherry picked from commit 1d26d1891e6e3cd49a4b479723b8aba7be746c1c)
This helps to keep the reason always together with the state it
is referring to, avoiding any side channels and making sure there
are no accidental inconsistencies.
#cherrypick
PiperOrigin-RevId: 644969317
(cherry picked from commit c0abd6f91ec62bc5347561c3f3174b3a660a7ba6)
This workaround is only applied on API 34, because the problem isn't
present on API 33 and it is fixed in the platform for API 35 onwards.
Issue: androidx/media#1237
#cherrypick
PiperOrigin-RevId: 644729909
(cherry picked from commit 968f72fec6d5452a34976824ac822782eeeb8f45)
In the case of a legacy session app providing an error
code different to `ERROR_UNKNOWN` without an error
message, a localized fallback message is provided
instead of ignoring the error.
#cherrypick
PiperOrigin-RevId: 644704680
(cherry picked from commit 6cc6444dd9be34ea3a40d2bb296247178ee86b1d)
The 'player commands' returned to ExoPlayerImpl instruct the
player on how to treat the current audio focus state.
The current return value when playWhenReady==false is misleading
because it implies we are definitely not allowed to play as if
we've lost focus. Instead, we should return the actual player
command corresponding to the focus state we are in.
This has no practical effect in ExoPlayerImpl as we already
ignore the 'player command' completely when playWhenReady=false.
To facilitate this change, we also introduce a new internal
state for FOCUS_NOT_REQUESTED to distinguish it from the state
in which we lost focus.
#cherrypick
PiperOrigin-RevId: 644416586
(cherry picked from commit 66c19390e2b31106a2a467366f7945c37a273fc6)
There are a lot of tests for AudioFocusManager in isolation,
but almost none for the handling in ExoPlayer.
Add test coverage for all the common cases, including some
currently broken behavior that is indicated by TODOs.
PiperOrigin-RevId: 644319251
(cherry picked from commit e20e94fde277a8e9e9a09e502a5760772e9eb006)
This is done by reserving some space for moov box at the start of the file and writing it there if it fits. If it doesn't fit, then it is written at the end of the file.
PiperOrigin-RevId: 643944698
Images are rendered into an ImageView (on top of the video shutter).
The image view is set to the images emitted by ExoPlayer's ImageOutput
and cleared when there is no longer a selected image track.
In order to keep the existing behavior of video tracks to only clear
the old output once the new first frame is rendered (avoiding short
periods of black between playlist items), we have to reorder this code
slightly to make it work for video and images. Both are treated in the
same way. If both are enabled, video takes precedence.
As the UI module only depends on the common module, we can't direcly
add the ImageOutput to ExoPlayer. This is done via reflection if
the provided Player is an ExoPlayer.
#cherrypick
PiperOrigin-RevId: 643320666
This value is used in a follow-up change to re-order SEI messages
containing CEA-6/708 data from decode order to presentation order.
PiperOrigin-RevId: 643296338
This change introduces a new class in Media3 `MediaExtractorCompat`, designed to be a drop-in replacement for platform `MediaExtractor`. While not all APIs are currently supported, the core functionality for the most common use cases of `MediaExtractor` is now available. Full API compatibility will be achieved in the future.
PiperOrigin-RevId: 643045429
This CL is a pure refactor of the existing tests, iterative changes
will be done in follow-ups.
The only logic change is having all MP4 assets have the presentaton of
height=360. The old code had some with height 480.
PiperOrigin-RevId: 643020773
Muxer never uses latest output position but always writes to
a specific location, so restoring its position does not add any
value.
PiperOrigin-RevId: 642996941
Previously, if renderFramesAutomatically = false, DefaultVideoFrameProcessor
may call onInputStreamProcessedListener after all frames have been
onOutputFrameAvailableForRendering, but before they had all been rendered and
freed.
Delay onInputStreamProcessedListener being called and subsequent DVFP
reconfiguration of effects, until all frames are rendered.
Tested using exoplayer setVideoEffects demo with playlist
PiperOrigin-RevId: 642963100
Determine `nextMediaSequence` and `nextPartIndex` based on the last `SegmentBaseHolder` instance, as it can update `mediaSequence` and `partIndex` depending on whether the HLS playlist has trailing parts or not.
Issue: androidx/media#1395
PiperOrigin-RevId: 642961141
When deselecting the single sample track and later re-selecting this
track, the current shortcuts in ProgressiveMediaPeriod don't handle
this case correctly and cause assertion failures.
In particular, this change fixes 3 issues:
1. When re-selecting the single sample track, we have cleared the
SampleQueue and need to reload the sample. The existing shortcut
should only be applied to avoid the reload when starting from a
non-zero position.
2. When de-selecting the track, ProgressiveMediaPeriod is left in
an inconsistent state where the sample queues are empty but
loadingFinished is still true. Fix this by resetting
loadingFinished to false.
3. When seeking, we avoid reloading the stream if we can keep
inside the existing samples. This logic assumes that all
remaining samples will continue to be loaded in the queue.
This condition isn't true though for single sample tracks
that have been de-selected. They appear to support the seek
inside the queue (=no seek necessary, always supported), but
still require a new load if there is no ongoing one to load
the sample. Fix this by checking this implicit assumption
(still loading, or loading finished).
PiperOrigin-RevId: 642650248
Also move the track selection header strings to the demo app
as they are only used there (except for audio, which stays in UI)
PiperOrigin-RevId: 642616037
