The player already supports changing durations of periods and ads.
The only thing not yet supported is a change in ad break positions
which changes the duration of clipped content ending in an ad break.
Adding support for this requires updating the end position in
MediaPeriodInfo and changing the clip end position of the respective
ClippingMediaPeriod.
Issue: #5067
PiperOrigin-RevId: 373139724
First intention to support parsing MPEG-H 3D Audio in ExoPlayer is to
take advantage of parsing capability from MediaParser API in AOSP.
Just with this change ExoPlayer does't support decoding MPEG-H 3D Audio
but can support decoding either by adding decoder with an extension or
by using Android OS which has decoder capability with MediaCodec API.
It was originally introduced because it was guaranteed to be non-null
unlike the inherited field. But ExoPlaybackException.cause has been
nullable for some time, so there's no gain in not using the inherited
field.
PiperOrigin-RevId: 372329740
Also make future similar issues less likely by adding isPlaceholder
to the set method of Period (in case forwarding Timeline
implementations use this instead of just updating values selectively)
#minor-release
PiperOrigin-RevId: 372138523
All `add*Listener` and `add*Output` methods are
deprecated in favor of `addListener`.
As for the class themselves `VideoListener` and
`AudioListener` are not used internaly by ExoPlayer,
`VideoRendererEventListener`
and `AudioRendererEventListener` are use in their
place.
As a result `VideoListener` and `AudioListener`
can be deprecated in favor `Listener`.
On the other hand `TextOutput` and `MedataOutput`
are used both in the player interface and internally in
renderers.
This means that those class can't be deprecated.
There usage in the public interface are indirectly
deprecated as their is no way to use them without
using the deprecated `add*Output`.
Thus it's not an issue that the class themselves are
not deprecated.
#minor-release
PiperOrigin-RevId: 371318268
Imported from GitHub PR https://github.com/google/ExoPlayer/pull/8858
Fix bug in text alignment inheritance where child does not correctly inherit ancestor's setting
@icbaker
Merge 70eb4bceb73b3f07e2f8d545b4fa7961189ac52a into 45616f916b28c9187b3e0f0dd18797464a079cdc
COPYBARA_INTEGRATE_REVIEW=https://github.com/google/ExoPlayer/pull/8877 from dlafayet:multirowalign-cue d942b50a40525fea5d11b35a33d3bbc512550960
PiperOrigin-RevId: 371306966
This change adds an API in the ForwardingPlayer to disable commands.
This is affecting what Player.isCommandAvailable() returns as
well as what is being advertised from the
EventListener.onAvailableCommandsChanged() callback.
For the callback case, the ForwardingPlayer needs to intercept the
callback. It does so by wrapping registered EventListener and Listener
instances, which resulted in some boiler-plate code. In addition, there
is logic on the wrapped listeners to avoid triggering a queued callback
if all listeners have been removed in the meantime. This includes the
case where new listeners are added while callbacks scheduled for the
removed listeners are still pending.
PiperOrigin-RevId: 371139703
Move VideoSize in the common module and have the Player return it.
`Listener` and `AnalyticsListener` `onVideoSizeChanged` are updated
with the old method deprecated.
`VideoRendererEventListener.onVideoSizeChanged` was also migrated to
`VideoSize` but the old method is removed, not deprecated.
This is because:
- apps calling/listening to this method is a rare and niche use-case.
- it would introduce hard to diagnostic issues where if only the caller
or the callee is updated to use the new method, the event will be lost.
This doesn't occur with the other 2 listeners as the caller is always
in ExoPlayer library and was updated to call both the old and new methods.
VideoSize is used everywhere except in `Format` as this would lead to
too much refactoring and backward compatibility breakage for little gain.
#minor-release
PiperOrigin-RevId: 371087419
Rating class should be in the same module as MediaMetadata.
Tested:
$ ./gradlew --stacktrace :exo-library-common:tDUT
$ ./gradlew --stacktrace :media2-session:tDUT
$ ./gradlew --stacktrace :media2-session-vct-current:cAT
PiperOrigin-RevId: 370902917
1. Clarify intention of getAdGroupIndexForPositionUs and
getAdGroupIndexAfterPositionUs. Both methods are used for very
specific but different purposes and encode the logic of which
ads should be played at which time, so it's helpful to clarify
this in the documentation as well.
2. Change one usage getAdGroupIndexForPositionUs to use the already
existing nextAdGroupIndex. This is also more in line with the
intended usage as clarified in step 1.
3. Update MediaPeriodQueueTest for updateQueuedPeriods to only
look for duration changes in future periods, not in the
current one, because that's not handled MediaPeriodQueue for ads
and the test is just passing by chance now. Also remove wrong
advancePlaying() calls that are already implicitly included in
the preceding enqueueNext() call.
4. Fix a minor bug where post-roll ads are not checked whether they
are played already before using them as the next ad group. Also
added a test covering this case.
#minor-release
PiperOrigin-RevId: 370664131
The ForwardingPlayer implements the Player interface and forwards all
operations to another Player instance. Apps will be able to override
methods of ForwardinPlayer in order to modify and/or suppress specific
Player funcionalities.
This commit introduces the ForwardingPlayer which simply forwards all
Player operations to another Player instance. In follow-up changes,
the ForwardingPlayer will be extended so that it eventually reaches the
feature-set offered by ControlDispatcher.
PiperOrigin-RevId: 370653167
Release is a life cycle operation that should only be called when
the player is no longer needed. It's linked to the player lifecycle
and thus very different from prepare/stop.
As a result, it should not be in the same command.
Additionally it's not clear if remote players will ever need to call release,
as the player creator is best candidate to release it.
As a result the release operation doesn't have a use case for a command.
A release command can be added later if a need is identified.
PiperOrigin-RevId: 370649214
