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
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
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.
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.
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
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
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
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
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
PiperOrigin-RevId: 379506261
In Android 12 mutability flags have to be set on PendingIntents. If they
are not, and the app targets Android 12, then the app will be crashed by
the system.
PiperOrigin-RevId: 373427591
The size of rtspLoaderWrappers must match the number of tracks exposed by the
RTSP session (a track is exposed if its media description entry appears in
DESCRIBE's SDP response).
When retrying with TCP, the old code will start loading all exposed RTSP
tracks, regardless of whether they are selected.
The fixed code will only start loading selected tracks.
#minor-release
PiperOrigin-RevId: 377931030
The current code does not catch the IAE thrown when building a MediaDescription
or SessionDescription. This CL catches the IAE and propagates it as a
ParserException.
Issue: #9014.
PiperOrigin-RevId: 377544439
The old version's retry logic will not work if using authentication.
Specifically, we use the same authentication parameters from the previous
session, and the RTSP server will reject such parameter.
In this fix, we reset the authentication info on retry. Further, we retry the
last request on receiving a 401 Unauthorized, rather than sending out another
DESCRIBE request.
#minor-release
PiperOrigin-RevId: 377539711
Related to Issue: #8941.
RTSP message body's format is not regulated by the RTSP spec, meaning it can
use either CRLF or LF as its line terminator. The old code assumes every line
ends with CRLF (RTSP message and the message body); the new code will rely on
the Content-Length information to receive the bytes for the message body.
#minor-release
PiperOrigin-RevId: 377475565
`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
Related to: Issue: #9010
Profile-level-id (Format.codecs) can be generated from SPS if SDP does not
include it.
#minor-release
PiperOrigin-RevId: 377251211