We create an empty CueGroup in many places as default or
where none is needed. Instead, we can define a constant
for this purpose and reuse it.
PiperOrigin-RevId: 467944841
(cherry picked from commit 29208ec1ed4d78fa86af33b81a2b32f3151b9004)
`TextRenderer` is updated to output `CueGroup`, which contains the presentation time of the cues, in microseconds.
PiperOrigin-RevId: 456531399
(cherry picked from commit bf11a8a83148f0d68c82cf22a5f978b1e6a5e299)
Leaving the media item that has been passed in unchanged, ensures that the
media item in the timeline is equal to the media item that the user has
passed into the player. The value of the tag is the uid of the window,
meaning this is redundant information.
#minor-release
PiperOrigin-RevId: 460542246
(cherry picked from commit 9d87c0db78f899ff05e8a26a3e6b4a9667fa81d2)
I don't think it's useful to keep these in numerical order, it makes
more sense to keep them grouped into a 'logical' ordering.
#minor-release
PiperOrigin-RevId: 460453464
(cherry picked from commit 1b1e0f890da4de6055491730595f72afdde0811a)
The media item needs to be assigned to `Window.mediaItem` in `CastTimeline.setWindow`. For this the `MediaItem` needs to be available in the timeline.
When a `MediaItem` is passed to the `set/addMediaItems` method, we can't yet know the Cast `MediaQueueItem.itemId` that is generated on the device and arrives with an async update of the `RemoteMediaClient` state. Hence in the `CastTimelineTracker`, we need to store the `MediaItem` by Casts's `MediaItem.contentId`. When we then receive the updated queue, we look the media item up by the content ID to augment the `ItemData` that is available in the `CastTimeline`.
Issue: androidx/media#25
Issue: google/ExoPlayer#8212
#minor-release
PiperOrigin-RevId: 460325235
(cherry picked from commit 02e1484ebc14a97829c9f5836333412c01205f57)
This is to be consistent with what cast `QueueMediaItem` is doing. If a contentId is
not available the contentUrl is used as the ID.
#minor-release
PiperOrigin-RevId: 459133323
(cherry picked from commit 84c801a723f56c9c0fcdf10ab8bbab35bfd9f333)
Some Player implementations have no playlist capability but can still
set a MediaItem for playback. Examples are a MediaController connected
to a legacy MediaSession, ExoPlayer up to 2.12 or MediaPlayer.
To indicate this capability, we need an allowed command in addition
to COMMAND_CHANGE_MEDIA_ITEMS that just allows to set a single item
that replaces everything that is currently played.
#minor-release
PiperOrigin-RevId: 453879626
(cherry picked from commit 2056152824512bcd8f2f09b2f7c1a752e913feac)
We need to pass timestamp for the list of cues so we are defining a new class CueGroup which will store both cues and timestamp.
PiperOrigin-RevId: 449212054
getCurrentTrackGroups and getCurrentTrackSelections are
retained for now, but moved from Player to ExoPlayer, to
ease the transition for some application code that currently
uses these methods.
PiperOrigin-RevId: 430036355
The track type is derived solely from the content. It does
not depend on any runtime properties such as the player's
capabilities of user track selection. Hence it belongs in
TrackGroup rather than TrackGroupInfo.
Note that this avoids TrackSelectionOverride from having to
re-derive the track type internally.
PiperOrigin-RevId: 429303312
We need TracksInfo.hasTracksOfType to determine which tabs to
display in TrackSelectionDialog.
We need TrackGroupInfo.isAdaptiveSupported to determine whether
to allow multiple selection (check boxes) or not (radio buttons).
PiperOrigin-RevId: 428793739
This change adds more standard metadata fields to Cast metadata including the artwork URL that makes the cast device show the artwork in the Cast route dialog (https://screenshot.googleplex.com/uj4n4Jqd7it9bob) and the Cast device.
This change also discriminates between media with an audio MIME type and others. For audio MIME type the Cast metadata is set to MEDIA_TYPE_MUSIC_TRACK which changes the layout and shows artwork and additional audio meta data to be displayed (https://screenshot.googleplex.com/ASy3KDcsTdJDM2T).
Issue: google/ExoPlayer#9663
PiperOrigin-RevId: 422589957
When sending a MediaItem to a MediaSession with a Media3 MediaController important information is removed for privacy reason. To look up the fully populated MediaItem the mediaId is used as a key. Hence having the mediaId marhalled to the JSON representation that is sent to a Cast device enables app developers to use the same look up facilities.
#minor-release
PiperOrigin-RevId: 420022868
Before this change we checked whether the playback state and playWhenReady have changed when the state from the cast device arrived. If we detected such a change we called the listener callback `onIsPlayingChanged`. However, in the case when `setPlayWhenReady(boolean)` is called on 'CastPlayer', we mask the change in `playWhenReady`, then send the play/pause request to the cast device and when the state from the cast device arrives we never detect a change because we have already masked `playWhenReady`.
This change now moves the check for `isPlaying` to the same place where the state and playWhenReady is updated, so we call the `onIsPlayingChanged` callback in either case, when masking or when a changed state from the server arrives.
Issue: google/ExoPlayer#9792
PiperOrigin-RevId: 418483509
This allows to give TrackGroups an identifier. The underlying goal is
to provide a way to make otherwise identical TrackGroups
distinguishable.
Also set this id in all internal sources that may produce identical
TrackGroups in certain edge cases.
Issue: google/ExoPlayer#9718
PiperOrigin-RevId: 413430719
This inheritance is really confusing because ExoPlayerImpl is not
a full Player interface implementation. It also claims to be an
ExoPlayer implementation in the Javadoc which isn't true in its
current state.
Removing the inheritance also allows to clean up some unused methods.
PiperOrigin-RevId: 411756963
Where this introduced an inconsistency (e.g. assigning to something
called `windowIndex`), I generally renamed the transitive closure of
identifiers to maintain consistency (meaning this change is quite
large). The exception is code that interacts with Timeline and Window
directly, where sometimes I kept the 'window' nomenclature.
#minor-release
PiperOrigin-RevId: 407040052
Only deprecated references remain.
Usages of the deprecated methods will be migrated in a follow-up change.
#minor-release
PiperOrigin-RevId: 405927141
TracksInfo is very similar to
`MappingTrackSelector.MappedTracksInfo` with some
fields removed to simplify the Player API,
notably it doesn't expose the renderer concept.
A significant difference is the addition of a `selected` boolean
field which avoids having a separate `getCurrentTrackSelection`
API.
This cl is a part of the bigger track selection change,
splitted for ease of review.
In particular, the MediaSession implementation and UI usage
have been slitted in child cls.
Find all cls with the tag:
#player-track-selection
PiperOrigin-RevId: 400937124
It calls through to a deprecated method, which is unusual for a
convenience method, and the deprecated method has various
implementations. This allows for a smoother removal of stop(boolean)
and removes an obstacle for the ExoPlayer-SimpleExoPlayer merge.
Adds missing @Deprecated tags to some Players.
PiperOrigin-RevId: 400213422
Both license and provisioning requests could be considered 'DRM
requests', and these headers are only sent on license requests, so
rename them to reflect that.
The old field remains deprecated for backwards compatibility.
PiperOrigin-RevId: 397980021
The type is already UUID so there's no need to duplicate that info in
the field name, and 'scheme' is a widely used term throughout both
ExoPlayer and android.os.MediaDrm documentation.
The old field remains deprecated for backwards compatibility.
The MediaItem.DrmConfiguration.Builder#setUuid method is renamed
directly (without deprecation) because it's not yet part of a released
ExoPlayer version.
PiperOrigin-RevId: 397961553
