This values won't be configurable from the UI anymore once the
DefaultControlDispatcher is removed.
They can be configured in the Player or by using a ForwardingPlayer.
PiperOrigin-RevId: 385113498
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
Also rename hasPrevious/Next to hasPrevious/NextWindow for consistency.
This makes it clearer what the difference between
seekToPrevious/NextWindow and seekToPrevious/Next is.
PiperOrigin-RevId: 384643373
MediaItem.mediaId used to default to the content URI, but this changed:
cc26a92e07
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.
#minor-release
Issue: #9106
PiperOrigin-RevId: 382763618
The serialization scheme used here is custom, it doesn't need
to be compatible with emsg-v0 or emsg-v1 (since
97183ef558).
This means that C.TIME_UNSET will propagate correctly through the
serialization.
#minor-release
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
Until now, we have stuck with the 3.12 long-term branch so as
to keep support for older API levels. However, this means that
the version we're using is 2.5 years old at this point. The
3.12 branch will stop receiving critical updates in December
2021.
Since use of the OkHttp extension is optional anyway, it seems
preferable to move to a modern version of OkHttp at this point.
PiperOrigin-RevId: 381465269
No-op change that adds the @FallbackType IntDef and changes the signature of getBlacklistDurationMsFor(LoadErrorInfo) to getExclusionDurationMsFor(@FallbackType, LoadErrorInfo).
PiperOrigin-RevId: 381075496
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
#minor-release
PiperOrigin-RevId: 380678388
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
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
#minor-release
PiperOrigin-RevId: 379506261
`SurfaceTexture` provides a transform matrix with each buffer. Previously
gldemo ignored this but it is important to apply it to have the video render
properly.
The transformation matrix from the surface texture includes flipping so this
change removes the hard-coded flipping from `a_texcoord`.
Issue: #8992
#minor-release
PiperOrigin-RevId: 377271389
Add the `needsReconfiguration` API on the `MediaCodecAdapter` interface so that `MediaCodecRenderer` can reconfigure the `MediaCodec` in case a `MediaCodecAdapter` needs to be reconfigured immediately after being obtained from the `MediaCodecAdapter.Factory`.
PiperOrigin-RevId: 376944334
A renderer is disabled (without being reset) in two situations:
* When transitioning into a period that starts with a discontinuity
* When stopping the player with setForegroundMode(true)
Before this change the behaviour of `MediaCodecRenderer` when disabled
(but not reset) depended on whether the content being decoded had an
associated `DrmSession`:
* For content without an associated DRM session the MediaCodec instance
was kept alive.
* For content with an associated DRM session, the MediaCodec instance
was released. This was to prevent the DRM session from staying alive
and continuing to make license refresh network requests while the
player was stopped in 'foreground mode'.
This change removes the second bullet, and keeps MediaCodec instances
alive in both the secure and insecure case. This will result in the
DRM machinery making occasional license refresh network requests (at
a frequency defined by the license policy) while the player is stopped
and in 'foreground mode'. This network usage is considered to be a
'limited resource' as described by the `ExoPlayer#setForegroundMode`
javadoc.
This means that switches between secure content (or between secure and
clear content when `MediaItem.drmConfiguration.sessionForClearTypes`
indicates a secure decoder should be used for clear content) should
keep the same video decoder, thus avoiding the 'black flash' that occurs
on some devices when switching the surface away from a secure decoder.
Issue: #8842
#minor-release
PiperOrigin-RevId: 376825501
This change introduces a third 'state' for `DefaultDrmSessionManager`:
It's been fully released (prepareCount == 0) but at least one of its
sessions is still active.
In this state new acquisitions are rejected (`(pre)acquireSession()`
calls will fail) but the machinery to support the existing sessions
(ExoMediaDrm and MediaDrmHandler) is kept until they're all released.
This change will allow us to remove the TODO in MediaCodecRenderer
that resolves Issue: #8842.
PiperOrigin-RevId: 376193952
Many of the setters are ignored unless others are set - this change:
* Lists these conditions exhaustively.
* Uses more concise language to avoid overshadowing the main details
of what the setter sets.
* Tweaks the language from 'is ignored' to 'shouldn't be called', to
open up the future possibility of throwing an error if these are
called without the 'required' setter also being present (see
Issue: #8957).
#minor-release
PiperOrigin-RevId: 376162385
Authentication sequence in RTSP:
- Server replies "Unauthorized" to our DESCRIBE request, and includes the
necessary information (i.e. realm, digest nonce, etc) in WWW-Authenticate
header
- After `RtspClient` receives the response, we
- Parse the WWW-Authenticate header, stores the auth info. The info is saved
for all further RTSP requests (that all need to carry authorization headers)
- send the second DESCRIBE request with the Authorization header.
#minor-release
PiperOrigin-RevId: 376116302
