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
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
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
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
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
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
