SDK / exoplayer

This URL no longer resolves.

#minor-release

Issue: #9205
PiperOrigin-RevId: 385772688

PiperOrigin-RevId: 385736588

Issue: #9037
#minor-release
PiperOrigin-RevId: 385630065

PiperOrigin-RevId: 385595264

Before this fix, if DefaultDrmSessionManager.release() was called while
there was at least one 'external' session reference still active (i.e.
session.referenceCount > 1) then the manager will release it's reference
immediately but when the session's reference count subsequently drops to
1 (due to external references being released) the manager will schedule
a task to release its internal reference *again*.

This change fixes the problem by only scheduling the timed release if
the manager is unreleased. This ensures that the internal references
are only released once.

Issue: #9193

PiperOrigin-RevId: 385580741

* Add release note for `RtspMediaSource.Factory.setTimeoutMs()`
* Remove mention of what we don't support (any such list is necessarily non-exhaustive)
* Remove markdown quote character ('>')

PiperOrigin-RevId: 385143574

#minor-release
Issue: #9100
PiperOrigin-RevId: 384962258

Issue: #9183

RFC2326 Section C.1.1 specifies that the URI to identify a track can be either
absolute (like rtsp://example.com/path) or relative (like "path"). Currently
we don't handle absolute URI, and this CL is to add the support.

Note though, we don't currently use the Content-Base or Content-Location
headers for the session URI.

PiperOrigin-RevId: 384649818

Applications may need to pass a non-visual context when creating
a DefaultTrackSelector (e.g., because they're audio-only or are
creating the selector in a background service).

Obtaining the default display via DisplayManager avoids the strict
mode violation that occurs when retrieving it via WindowManager.

#minor-release

PiperOrigin-RevId: 384487363

Most of the super-interfaces are deprecated, but the intention is that
only the types are deprecated and the methods themselves shouldn't be.
In order to reflect this in javadoc we override all the methods in
`Player.Listener` in order to 'cancel' the deprecation.

This change deliberately doesn't override methods that are explicitly
deprecated with documented replacements (like
`Player.EventListener#onPlayerStateChanged`) - these should contine to
be marked as deprecated in javadoc.

PiperOrigin-RevId: 384253725

Android doc:https://developer.android.com/reference/android/app/Notification.Builder#setOnlyAlertOnce(boolean)

PiperOrigin-RevId: 384227580

#minor-release
Issue:#9158
PiperOrigin-RevId: 383660258

Issue: #9005
PiperOrigin-RevId: 382765045

MediaItem.mediaId used to default to the content URI, but this changed:
https://github.com/google/ExoPlayer/commit/cc26a92e070db8963738beed423bb4699762877f

Before the mediaId change linked above, a playlist of different content
all with the same ad URI would play the ads for every item. After the
change the ad would only play once (because mediaId == "" for every
item, so they're all the same). This change restores roughly the
original behaviour by always considering both mediaId and the content
URI.

Issue: #9106
PiperOrigin-RevId: 382763618

PiperOrigin-RevId: 382763308

The serialization scheme used here is custom, it doesn't need
to be compatible with emsg-v0 or emsg-v1 (since
https://github.com/google/ExoPlayer/commit/97183ef55866170807910cd626264d82d41d46d4).

This means that C.TIME_UNSET will propagate correctly through the
serialization.

Issue: #9123
PiperOrigin-RevId: 382762873

Without this annotation it seems that `SimpleExoPlayer` effectively
'un-deprecates' the method, specifically:
* A usage of these methods isn't flagged by Android Studio if the
  declared type is `SimpleExoPlayer` (up-casting to e.g.
  `ExoPlayer.VideoComponent` results in the warning showing up).
* The `SimpleExoPlayer` javadoc doesn't mention this method is
  deprecated:
  https://exoplayer.dev/doc/reference/com/google/android/exoplayer2/SimpleExoPlayer.html#addVideoListener(com.google.android.exoplayer2.video.VideoListener)
* The Metalava API output for `SimpleExoPlayer` doesn't show these
  methods as deprecated.

PiperOrigin-RevId: 382756174

PiperOrigin-RevId: 382139109

Issue:#7608
PiperOrigin-RevId: 382081687

PiperOrigin-RevId: 381852972

PiperOrigin-RevId: 381833313

Previously, a SocketTimeourException is used to signal the end of the stream
that is caused by "no RTP packets received for a while". However, such
signaling is inappropriate under TransferRtpDataChannel, or FakeRtpDataChannel
in RtspPlaybackTests.

Hence, the signaling of end of stream is changed to use RESULT_END_OF_INPUT.
The RtpDataChannel implementations will Still block until a set timeout, but
will return a C.RESULT_END_OF_INPUT should a timeout occur, instead of
throwing a nested SocketTimeoutException.

This also allowed customization of the timeout amount, in
RtspMediaSource.Factory

PiperOrigin-RevId: 380981534

Amend release note for https://github.com/google/ExoPlayer/commit/46bc49a4f6e8194ddb28e7b17eb775157c3e241d.

PiperOrigin-RevId: 380766548

Issue: #9086
PiperOrigin-RevId: 380756562

The problem occurs when the primary media playlist URL switches
from one whose latest snapshot has not yet got the ended tag, to
one whose latest snapshot already has the ended tag. In this case:

- We trigger a redundant load of the ended playlist.
- When the redundant load completes,
  MediaPlaylistBundle.processLoadedPlaylist detects that the
  playlist is unchanged from the one it already has, and so
  doesn't call onPlaylistUpdated.
- PrimaryPlaylistListener.onPrimaryPlaylistRefreshed is never
  called with the new primary. Hence the externally visible primary
  is still the one that hasn't ended. HlsMediaSource therefore thinks
  the event hasn't ended, which in turn prevents the player from
  transitioning to the ended state.

This commit detects when the new primary already has the ended tag.
In this case, we call onPrimaryPlaylistRefreshed directly and remove
the unnecessary playlist load.

Issue: #9067
#minor-release
PiperOrigin-RevId: 380680532

The glitches were introduced in:
https://github.com/google/ExoPlayer/commit/6c31e34528

The problem is that Listener.onEvents is called in a later looper iteration
than the listener methods that were previously used. This created a gap on
the main thread between the UI component dispatching a seek operation to the
player, and onEvents being called to update the progress bar's position.

At the start of this gap the progress bar is rendering the new position,
but its position member variable is still set to the old position. If the
progress bar is re-drawn by another message on the main thread within the
gap, it will briefly show the old position until onEvents is called.

There are multiple possible fixes to this, and the best one is probably to
modify ListenerSet to remove the gap. That's high risk though, so for now we
fix the flicker by always updating the progress immediately after the seek
is dispatched, in addition to when onEvents is called.

Issue: #9049
PiperOrigin-RevId: 380678388

#minor-release

PiperOrigin-RevId: 380655806

Issue: #9061
PiperOrigin-RevId: 380640601

This softens the language around suppressing individual test methods.
There are some legitimate cases where this is needed, e.g.
ByteArrayDataSourceContractTest has to suppress all the tests related
to non-existent resources because it's not possible to simulate that
case.

#minor-release

PiperOrigin-RevId: 380570017

Some server will wrongly insert duplicated attributes. We used to treat this as
a unrecoverable error, but it is better to treat the duplicated attributes in
an "over-writable" fashion like HashMaps.

Issue: #9080,
Issue: #9014
PiperOrigin-RevId: 380547079

#minor-release

PiperOrigin-RevId: 380531272

Also change to explicitly track the provisioning session, which makes
the code easier to reason about than always using the zero'th element
of the list.

PiperOrigin-RevId: 380181453

PiperOrigin-RevId: 379935363

Issue: #8960

PiperOrigin-RevId: 379922704

#minor-release

PiperOrigin-RevId: 379913814

Issue: #9004
PiperOrigin-RevId: 379516815

Note that this removes a workaround for malformed content, in which the
track_ID is set incorrectly. It's unclear there was sufficient reason to
implement that workaround, and so it's preferable to remove it, rather
than implementing the concept of unrecognized tracks, which would be
needed to keep it and to also fix this issue.

Issue: #9056
PiperOrigin-RevId: 379506261

The Widevine H264 samples in the demo app now log this from the EventLogger:
```
[X] Track:0, id=1, mimeType=video/avc, bitrate=772315, codecs=avc1.42c01e, drm=[widevine,cenc], res=320x142, fps=24.0, supported=YES
```

And the VP9 ones log:
```
[X] Track:0, id=1, mimeType=video/x-vnd.on2.vp9, bitrate=588256, codecs=vp9, drm=[widevine], res=320x142, fps=23.809525, supported=YES
```

#minor-release

PiperOrigin-RevId: 379498332

PiperOrigin-RevId: 379440699

PiperOrigin-RevId: 378895355