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 45616f916b
COPYBARA_INTEGRATE_REVIEW=https://github.com/google/ExoPlayer/pull/8877 from dlafayet:multirowalign-cue d942b50a40525fea5d11b35a33d3bbc512550960
PiperOrigin-RevId: 371306966
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
Session pre-fetching caused this ordering assertion to no longer be
always true. It should have been removed in
795ddfee40
#minor-release
PiperOrigin-RevId: 370880530
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
Previously loadingFinished will never be set to true because it started in
false, and we are and'ing it with `canceled`.
#minor-release
PiperOrigin-RevId: 370662456
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
We remove other source related listeners if a MediaSource is
removed from the playlist or the player/source is released.
This isn't currently done for the DRM listener.
#minor-release
PiperOrigin-RevId: 370482571
MediaCodecRenderer is calling its protected methods
resetCodecStateForRelease() and resetCodecStateForFlush() from its
constructor. Classess that override the methods (eg.
DebugMediaCodecVideoRenderer) need to checks if the methods
are called from the superclass constructor thus their members are not
initialized yet.
With this change, the MCR constructor does not call the two
methods and sets the respective state directly on its fields.
PiperOrigin-RevId: 370445978
Remove references to deprecated methods. I didn't replace the DRM info
with references to non-deprecated methods because I'm not sure it
belongs at class level. The methods themselves are already documented
in detail.
PiperOrigin-RevId: 370421087
* @Nullable is not a TYPE_USE annotation, so should appear before any modifiers and after Javadocs.
(see go/java-style#s4.8.5-annotations)
This CL looks good? Just LGTM and Approve it!
This CL doesn’t look good? This is what you can do:
* Suggest a fix on the CL (go/how-to-suggest-fix).
* Revert this CL, by replying "REVERT: <provide reason>"
* File a bug under go/error-prone-bug for category ErrorProneStyle if the change looks generally problematic.
* Revert this CL and not get a CL that cleans up these paths in the future by
replying "BLOCKLIST: <provide reason>". This is not reversible! We recommend to
opt out the respective paths in your CL Robot configuration instead:
go/clrobot-opt-out.
This CL was generated by CL Robot - a tool that cleans up code findings
(go/clrobot). The affected code paths have been enabled for CL Robot in //depot/google3/java/com/google/android/libraries/exoplayer/METADATA which is reachable following include_presubmits from //depot/google3/third_party/java_src/android_libs/media/METADATA.
Anything wrong with the signup? File a bug at go/clrobot-bug.
#codehealth
PiperOrigin-RevId: 370377751
Add method getAvailableCommands() in Player interface to return
the available commands. Method isCommandAvailable() moved to
BasePlayer since it can be implelented by calling
getAvailableCommands().
PiperOrigin-RevId: 370059328
A subsequent change will make the UI module access
SphericalGLSurfaceView and VideoDecoderGLSurfaceView
using reflection, now we're at the point where we only
need to reflect the constructors.
PiperOrigin-RevId: 369630102
*** Original commit ***
Rollback of e60609e344
*** Original commit ***
Prevent creation of new sessions if the Timeline is empty.
We currently create sessions based on the placeholder window
index. This shouldn't be needed as we now set a non-empty
timeline as soon as the first MediaItem...
***
PiperOrigin-RevId: 369609523
The protected visibility causes problems in Kotlin (Issue: #8830) and
also prevents a subclass of AdaptiveTrackSelection.Factory that isn't
nested inside a subclass of AdaptiveTrackSelection (in both Java and
Kotlin).
#minor-release
PiperOrigin-RevId: 369468841
*** Original commit ***
Prevent creation of new sessions if the Timeline is empty.
We currently create sessions based on the placeholder window
index. This shouldn't be needed as we now set a non-empty
timeline as soon as the first MediaItem is added to the playlist.
Once this check is part of the session manager, we can also remove
the equivalent workarounds from the various code integrations.
***
PiperOrigin-RevId: 369452067
This method shouldn't be used anymore since the thread enforcement
is the default already. We still keep it for now to ease the transition
for apps that use ExoPlayer on multiple threads and want to temporarily
disable the enforcement while the threading problems are fixed.
PiperOrigin-RevId: 369440789
We currently create sessions based on the placeholder window
index. This shouldn't be needed as we now set a non-empty
timeline as soon as the first MediaItem is added to the playlist.
Once this check is part of the session manager, we can also remove
the equivalent workarounds from the various code integrations.
PiperOrigin-RevId: 369432853
The original cl has been fixed by not implementing
VideoListener but Player.Listener in
StyledPlayerView.
VideoFrameMetadataListener and CameraMotionListener are still part
of the Player interface as a good way to break the UI dependency
on them has not yet been finalised.
PiperOrigin-RevId: 369417682
This change moves the responsibility of creating, configuring and starting the MediaCodec from the MediaCodecRender to the MediaCodecAdapter.Factory.
This move allows ExoPlayer's client to decide how and when codecs are created and/or reused.
To allow the move, this CL replaces MediaCodecRenderer.ConfigureCodec with MediaCodecRenderer.getCodecConfiguration
PiperOrigin-RevId: 369273887
*** Original commit ***
Move VideoComponent in ExoPlayer
VideoFrameMetadataListener and CameraMotionListener are still part
of the Player interface as a good way to break the UI dependency
on them has not yet been finalised.
***
PiperOrigin-RevId: 369194309
* Prefer instanceof to getClass when implementing Object#equals.
(see http://go/bugpattern/EqualsGetClass)
This CL looks good? Just LGTM and Approve it!
This CL doesn’t look good? This is what you can do:
* Suggest a fix on the CL (go/how-to-suggest-fix).
* Revert this CL, by replying "REVERT: <provide reason>"
* File a bug under go/error-prone-bug for category ErrorProneFragileCode if the change looks generally problematic.
* Revert this CL and not get a CL that cleans up these paths in the future by
replying "BLOCKLIST: <provide reason>". This is not reversible! We recommend to
opt out the respective paths in your CL Robot configuration instead:
go/clrobot-opt-out.
This CL was generated by CL Robot - a tool that cleans up code findings
(go/clrobot). The affected code paths have been enabled for CL Robot in //depot/google3/java/com/google/android/libraries/exoplayer/METADATA which is reachable following include_presubmits from //depot/google3/third_party/java_src/android_libs/exoplayer/METADATA.
Anything wrong with the signup? File a bug at go/clrobot-bug.
#codehealth
PiperOrigin-RevId: 369180513
VideoFrameMetadataListener and CameraMotionListener are still part
of the Player interface as a good way to break the UI dependency
on them has not yet been finalised.
PiperOrigin-RevId: 368863829
Before this change:
- SimpleExoPlayer.prepare(mediaSource) ended up calling
ExoPlayerImpl.setMediaSourcesInternal() with startWindowIndex=0 and
resetToDefaultPosition=false.
- ExoPlayerImpl.prepare(mediaSource) ended up calling
ExoPlayerImpl.setMediaSourcesInternal() with
startWindowIndex=C.INDEX_UNSET and resetToDefaultPosition=true.
This was functionaly equivalent but a bit confusing.
#minor-release
PiperOrigin-RevId: 368818143
Even when fixed to the US locale (and thus avoiding surprising behaviour
in e.g. Turkish locale with "i" and "I") there are unexpected behaviours
when upper and lower casing non-ASCII characters.
For example it's sometimes not symmetric, e.g.:
"ẞ".toLowerCase() -> "ß"
"ß".toUpperCase() -> "SS"
In all the ExoPlayer usages we are either dealing with known-ASCII
strings (e.g. MIME types) or comparing against ASCII constant strings
anyway, so it seems easier to just use Guava's ASCII-only class in these
cases.
Util.toUpperInvariant() is null-tolerant, while Ascii.toLowercase() is
not. Most usages in this change are clearly non-null. The BandwidthMeter
usages aren't annotated @Nullable, but the current code *would* work if
countryCode was null in both cases. These methods will now throw NPE if
they're passed null.
PiperOrigin-RevId: 368816287
This is necessary to migrate apps which are using
ExoPlayer.Builder.experimentalSetForegroundModeTimeoutMs
from ExoPlayerImpl to SimpleExoPlayer.
PiperOrigin-RevId: 368657557
Discontinuity reasons may not be precisely obtained for remote
player. 'Remote Player' means that playback is owned by another
app or device and the same playback can be controller by other
clients simultaneously. The MediaController is an example.
If the remote playback doesn't provide discontinuity reason, then
player cannot differentiate between automatic playback transition
and seekTo() from another client.
This CL tweaks the discontinuity reason definitions, so reasons
can be obtained without remote playback's support.
This doesn't effect the local Players, such as SimpleExoPlayer.
PiperOrigin-RevId: 368579577
Even when fixed to the US locale (and thus avoiding surprising behaviour
in e.g. Turkish locale with "i" and "I") there are unexpected behaviours
when upper and lower casing non-ASCII characters.
For example it's sometimes not symmetric, e.g.:
"ẞ".toLowerCase() -> "ß"
"ß".toUpperCase() -> "SS"
In all the ExoPlayer usages we are either dealing with known-ASCII
strings (e.g. MIME types) or comparing against ASCII constant strings
anyway, so it seems easier to just use Guava's ASCII-only class in these
cases.
This change also includes some null-twiddling, because
Util.toLowerInvariant() is null tolerant, while Ascii.toLowerCase() is
not. Most of the usages were already non-null, and it was easy enough to
change the remaining ones to be so by simple reordering of statements.
I'll make an equivalent change for Util.toUpperInvariant() next.
PiperOrigin-RevId: 368419813
Previously, we had separate MSG_SET_SURFACE and
MSG_SET_VIDEO_DECODER_OUTPUT_BUFFER_RENDERER messages for
setting different types of supported output. Use of these
constants to switch between outputs during use of a player
was confusing because not all video renderers support both
message types.
To switch from VideoDecoderOutputBufferRenderer to a Surface,
it was sufficient just to send MSG_SET_SURFACE, since all
video renderers support this and clear any other output that
might be set. Conversely, to switch in the opposite direction,
just sending a MSG_SET_VIDEO_DECODER_OUTPUT_BUFFER_RENDERER was
not sufficient, because not all video renderers handle this
message to clear any previous output. Hence it was necessary to
explicitly clear a previously set surface using a separate
MSG_SET_SURFACE message. Passing two messages to switch the
output may prevent renderers from implementing the output switch
efficiently.
This change passes all outputs using a single message type, and
requires that all renderers treat unsupported outputs as though
null were passed (i.e., they clear any existing output). There
are some other miscellaneous improvements:
1. Non-surface outputs are now passed to onRenderedFirstFrame.
This fixes a bug in SimpleExoPlayer's onRenderedFirstFrame,
where previously it could not correctly equality check the
output corresponding to the event to its current output in
the VideoDecoderOutputBufferRenderer case.
2. Fix SimpleExoPlayer to report surface size changes for the
VideoDecoderOutputBufferRenderer case. Even though the
surface is rendered to indirectly in this case, we can still
query (and listen to changes to) the surface's size.
PiperOrigin-RevId: 368215850
If this condition isn't true, the player may enter a cycle of discarding
and reloading the same format. As minDurationToRetainAfterDiscard is a
parameter likely left at its default, and minDurationForQualityIncrease
is likely adjusted more often, we correct the value in the problematic
case and log a warning instead of asserting it outright to prevent
unnecessary app breakages.
Issue: #8807
PiperOrigin-RevId: 368207417
This is the right thing to do, as per the GLSurfaceView documentation.
This adds (previously omitted) calls to VideoDecoderGLSurfaceView.
PiperOrigin-RevId: 368202523
Other properties of SphericalGLSurfaceView (e.g., setDefaultStereoMode)
are not plumbed through the PlayerView components, and it doesn't scale
to plumb through all properties of all of the SurfaceView types.
Applications can instead do:
```
((SphericalGLSurfaceView) playerView.getVideoSurfaceView())
.setUseSensorRotation(useSensorRotation);
```
PiperOrigin-RevId: 368196537
There is no use case left where we couldn't use a better
alternative (either looping in the player, using the Player
playlist API, or ConcatenatingMediaSource for advanced cases)
PiperOrigin-RevId: 367990981
Prior to this change, there were some unrealistic quirks in
our Robolectric tests. For example, onRenderedFirstFrame would
be called when using FakeVideoRenderer, despite no output to
render the frame to ever being set. This change improves the
realism of these tests. These changes are required for some
improvements being made to how outputs are set on video
renderers.
PiperOrigin-RevId: 367652169
This was added in 9609af3c23 as part of a LSC.
The RequiresNonNull annotation doesn't work anymore (it doesn't
recognize the outer class member and instead tries to find
the same variable on the inner class). So instead of suppressing
the warning of the non-fulfilled precondition, we can just
check the non-nullness directly and remove the precondition.
PiperOrigin-RevId: 367593941
The main change here is that VideoDecoderGLSurfaceView now implements
VideoDecoderOutputBufferRenderer directly. This avoids SimpleExoPlayer
having to cast to VideoDecoderGLSurfaceView, which will be necessary
if VideoDecoderGLSurfaceView is moved to the UI module. Instead, the
player can cast directly to VideoDecoderOutputBufferRenderer, which
could be moved to the Common module.
The renderer is also moved to be an inner class, since it's not used
anywhere else and since doing this makes it a little easier to move
things around.
PiperOrigin-RevId: 367398147
We added a source that allows mixed placeholder and non-placeholder
periods, but have no way to denote that in the Timeline because the
placeholder flag only exists on Window level. This causes a bug if
the first item in a concatenation has a window-period offset and the
player can't detect whether it's still a placeholder or not.
Adding this flag to Period allows the player to detect this reliably.
In addition we need to make sure that re-resolving pending positions
only happens for the first placeholder period where the window-offset
can actually change. As all subsequent periods have to start at position
0, so they don't need to be re-resolved (and shouldn't).
PiperOrigin-RevId: 367171518
* @Nullable is not a TYPE_USE annotation, so should appear before any modifiers and after Javadocs.
(see go/java-style#s4.8.5-annotations)
This CL looks good? Just LGTM and Approve it!
This CL doesn’t look good? This is what you can do:
* Suggest a fix on the CL (go/how-to-suggest-fix).
* Revert this CL, by replying "REVERT: <provide reason>"
* File a bug under go/error-prone-bug for category ErrorProneStyle if the change looks generally problematic.
* Revert this CL and not get a CL that cleans up these paths in the future by
replying "BLOCKLIST: <provide reason>". This is not reversible! We recommend to
opt out the respective paths in your CL Robot configuration instead:
go/clrobot-opt-out.
This CL was generated by CL Robot - a tool that cleans up code findings
(go/clrobot). The affected code paths have been enabled for CL Robot in //depot/google3/java/com/google/android/libraries/exoplayer/METADATA which is reachable following include_presubmits from //depot/google3/third_party/java_src/android_libs/exoplayer/METADATA.
Anything wrong with the signup? File a bug at go/clrobot-bug.
#codehealth
PiperOrigin-RevId: 367053059
- Take centerControls padding into account to prevent switching to
minimal mode too soon
- Disable clipping to padding to avoid the edges of controls from
being clipped as the view gets smaller
Issue: #8763
PiperOrigin-RevId: 366966298
This reverts
<unknown commit>
Which was a temporary workaround for Issue: #1874
Also add a loop to ensure we process as many metadata items as
applicable in each render() call.
PiperOrigin-RevId: 366965504
LSC: go/checker-lsc
Tested:
Sample tests for this CL passed, but some tests failed during the TGP run. Test failures are believed to be unrelated to this CL
PiperOrigin-RevId: 366804637
This ensures BUFFER_FLAG_DECODE_ONLY is set on samples that are
before the playback start position, in the case that the queue
is created after the start position is set.
#minor-release
PiperOrigin-RevId: 366249188
The condition is meant to be unblocked whenever the constructor is
left. This should include unchecked exceptions (that may be thrown
due to bugs in the dependent components, or user-inhected factories)
PiperOrigin-RevId: 366235361
The new onPositionDiscontinuity callback contains sufficient information, so
that this former workaround to obtain the position before a seek is no longer
needed.
PiperOrigin-RevId: 365993937
Aims to achieve visibility parity with MediaCodecRenderer#onQueueInputBuffer.
Allows measuring the time when the codec queue the first input buffer in the codec. Which means the Codec has been initialized and is about to start decoding.
It also allows measuring how long it takes for the Codec to render its first frame.
PiperOrigin-RevId: 365906756
If the player is created on a background thread (which is allowed
as the only exception to the access-on-one-thread-only rule), it
may happen that a callback on the main thread tries to access the
player before the constructor even finished. This is dangerous and
can cause exceptions due to uninitialized variables.
To solve this, we can make sure that every player access is blocked
until the constructor finished. Blocking is safe because the
constructor itself is not doing any blocking work or acquiring locks.
The thread verification method is already called on every entry
point to the player, so we can reuse the same method for checking.
PiperOrigin-RevId: 365792949
The extended onPositionDiscontinuity callback can be used to improve some
listener classes:
- Listening to onTimelineChanged to detect discontinuities is no longer needed.
- Listening to onSeekStarted is no longer needed as the start position is part
of the onPositionDiscontinuty callback.
- The exact old position is also useful for media time history logging.
As a side effect, removing onSeekStarted handling from PlaybackStatsListener
fixes Issue: #8675 that was caused by the special EventTime handling for
onSeekStarted.
PiperOrigin-RevId: 365558959
A TrackGroup must contain the same content in all Formats (except for
the quality, encoding etc). Verify that the language and role flags
are the same and log an error if don't match. Don't throw to avoid
breaking existing use cases that just happen to work by chance.
PiperOrigin-RevId: 365539240
The hacky workaround for APIs 29/30 doesn't work on API 31. Instead,
we can use the onDisplayInfoChanged callback, that is accessible from
API 31.
PiperOrigin-RevId: 364997282
The BasePlayer implementation of add/remove
Listener knows about Components.
As those are removed from the Player
interface, the implementation of those
methods needs to be moved down in Player
implementations.
This commit makes no functional change.
PiperOrigin-RevId: 364985291
The exo_controls_background view is supposed to fill its parent,
and so previously used match_parent to do this. However, if the
parent uses wrap_content for its own dimensions, the constraints
being specified become somewhat ambiguous. The parent is supposed
to be sizing itself to wrap its children, and one of the children
is supposed to be sizing itself to match the parent.
Intuitively for this case, you'd hope that the layout logic would
size the parent to wrap its other children, and that the
match_parent child would then fill the parent with its determined
size. That's not what happens, and instead the parent ends up
expanding to occupy all of the space available to it.
This commit sets the exo_controls_background view's dimensions
to be 0dp in the layout, to stop it from influencing the size of
the parent. It's then expanded to fill the parent in code.
Issue: #8726
#minor-release
PiperOrigin-RevId: 364868301
