The static and dynamic metadata now build up in a list, such that when
the MediaMetadata is built, they are applied in an event order. This
means that newer/fresher values will overwrite older ones. The MediaItem
values are then applied at the end, as they take priority over any other.
#minor-release
PiperOrigin-RevId: 405383177
Issue: #9392 reports occasional IllegalStateExceptions from release()
in crashlytics,`with no way to reproduce locally. It seems likely there
is a bug somewhere in DRM handling, and ideally we would find that and
fix it.
However we haven't been able to find the problem, and in the meantime
these exceptions cause the entire app to crash. Although this is
arguably useful from a debugging perspective, it's obviously a poor
experience for developers and users, since all we're actually trying to
do is release the session, so maybe we shouldn't strictly care that it's
already released?
This change replaces the exception with an error log, which might be a
useful debugging hint if we see other DRM unexpected behaviour due to
references to released sessions being held for too long.
PiperOrigin-RevId: 403942546
The possibilities to set a ControlDispatcher have been removed in
<unknown commit> so that the ControlDispatcher is always a
DefaultControlDispatcher.
PiperOrigin-RevId: 403327092
*** Original commit ***
Rollback of 8ed6c9fcf5
*** Original commit ***
Fix capitalization of language in track selector
Issue: #9452
***
***
PiperOrigin-RevId: 400942287
This change makes asynchronous queueing non-experimental, it enables the
feature by default on devices with API level >= 31 (Android 12+) and
exposes APIs for apps to either fully opt-in or opt-out from the
feature.
The choice to use or not asynchronous queueing is moved out of
MediaCodecRenderer to a new MediaCodecAdapter factory, the
DefaultMediaCodecAdapterFactory. This is because, at the moment,
if an app passes a custom adapter factory to a MediaCodecRenderer and
then enables asynchronous queueing on it, the custom
adapter factory is not used but this is not visible to the user.
The default behavior of DefaultMediaCodecAdapterFactory is to create
asynchronous MediaCodec adapters for devices with API level >= 31
(Android 12+), and synchronous MediaCodec adapters on devices with older
API versions.
DefaultMediaCodecAdapterFactory exposes methods to force enable or force
disable the use of asynchronous adapters so that applications can enable
asynchronous queueing on devices with API versions before 31 (but not
before 23), or fully disable the feature. For applications that build
MediaCodecRenderers directly, they will need to create a
DefaultMediaCodecAdapterFactory and pass it to the renderer constructor.
For applications that rely on the DefaultRenderersFactory, additional
methods have been added on the DefaultRenderersFactory to control
enabling/disabling asynchronous queueing.
Issue: #6348
PiperOrigin-RevId: 400733506
The fix for Issue: #8776 was to release and null-out dummySurface if
it doesn't match the security level of the decoder. But it's possible
that this.surface is already set to this.dummySurface, in which case we
must also null out this.surface otherwise we will later try and re-use
the old, released DummySurface instance.
This logic already exists in MCVR#onReset, so I pulled it into a
releaseDummySurface() helper function.
Issue: #9476
#minor-release
PiperOrigin-RevId: 399420476
- If DownloadService is configured to run as a foreground service,
it will remain started and in the foreground when downloads are
waiting for requirements to be met, with a suitable "waiting for
XYZ" message in the notification. This is necessary because new
foreground service restrictions in Android 12 prevent to service
from being restarted from the background.
- Cases where requirements are not supported by the Scheduler will
be handled in the same way, even on earlier versions of Android.
So will cases where a Scheduler is not provided.
- The Scheduler will still be used on earlier versions of Android
where possible.
Note: We could technically continue to use the old behavior on
Android 12 in cases where the containing application still has a
targetSdkVersion corresponding to Android 11 or earlier. However,
in practice, there seems to be little value in doing this.
PiperOrigin-RevId: 398720114
Issue: #9430
The current supported SDP (RFC2327) spec only allows for alpha-numeric
characters in the attribute-field. RFC4566 (section 9, token type) allowed
extra characters, and this CL adds the support.
PiperOrigin-RevId: 397301173
The deprecated `Player.addListener(EventListener)`
is moved out of Player into its subclasses
(CastPlayer and ExoPlayer).
This is unlikely to break users because:
- the method has been deprecated in the last major version
- the method is still present in the major implementations
If an users is affected, they can either:
- use ExoPlayer instead of Player
- (recommended) switch to Player.Listener.
Additionally update the threading guarantees that did not
reflect the current implementation.
PiperOrigin-RevId: 397272144
This was originally reported on #9390. There was a bug that when HLS
loads failed, the player would endlessly retry and never fail with a
player error.
This change fixes a bug in HlsSampleStreamWrapper.onPlaylistError()
which would return true for a playlist whose load encountered an error
but could not be excluded, whereas the method should return false.
Issue: #9390
#minor-release
PiperOrigin-RevId: 397045802
*** Original commit ***
Ensure MediaSourceFactory instances can be re-used
This fixes DefaultDrmSessionManager so it can be used by a new Player
instance (by nulling out its reference to the playback thread, which is
unique per-Player instance). This only works if the
DefaultDrmSessionManager is 'fully released' before being used by the
second Player instance, meaning that the reference count of the manager
and all its sessions is zero.
#exofixit
Issue: #9099
***
PiperOrigin-RevId: 396861138
Previously the released preacquired sessions would start their keepalive
timeout, and so no additional resources would be freed in time for the
manager to retry the session acquisition.
This change adds an additional purge of keepalive sessions *after* the
preacquired sessions are released, which fixes the problem.
#exofixit
#minor-release
PiperOrigin-RevId: 396613352
This is a candidate fix for #8906. As mentioned in that issue,
negative positions within windows might be (kind of) valid in
live streaming scenarios, where the window starts at some
non-zero position within the period. However, negative positions
within periods are definitely not valid. Neither are positions
that exceed the period duration.
There was already logic in ExoPlayerImplInternal to prevent a
resolved seek position from exceeding the period duration. This
fix adds the equivalent constraint for the start of the period.
It also moves the application of the constraints into Timeline.
This has the advantage that the constraints are applied as part
of state masking in ExoPlayerImpl.seekTo, removing any UI flicker
where the invalid seek position is temporarily visible.
Issue: #8906
PiperOrigin-RevId: 395917413
Instead of selecting the base URL initially or when a load error occurs, it is now selected when a chunk or initialization chunk is created. The selected base URL is then assigned to `RepresentationHolder.lastUsedBaseUrl` that is excluded in case of a load error. For a next chunk another base URL will be selected by using the `BaseUrlExclusionList`.
#minor-release #exo-fixit
PiperOrigin-RevId: 395721221
This fixes DefaultDrmSessionManager so it can be used by a new Player
instance (by nulling out its reference to the playback thread, which is
unique per-Player instance). This only works if the
DefaultDrmSessionManager is 'fully released' before being used by the
second Player instance, meaning that the reference count of the manager
and all its sessions is zero.
#exofixit
#minor-release
Issue: #9099
PiperOrigin-RevId: 395490506
I think this has been broken since 617267bfcf (which was trying to fix
the same problem).
This change initializes `rootDir` to always be the current project (i.e. ExoPlayer)
directory. From the [Gradle docs](https://docs.gradle.org/current/userguide/working_with_files.html#sec:single_file_paths):
> What happens in the case of multi-project builds? The file() method
> will always turn relative paths into paths that are relative to the
> current project directory, which may be a child project.
We can also then remove exoplayerRoot completely and simplify the local
dependency instructions.
* #minor-release
* #exofixit
* Issue: #9403
PiperOrigin-RevId: 395478121
Some server will send partial URIs in the RTP-Info header, while the RTSP spec
requires absolute URLs.
Issue: #9346
#exofixit
PiperOrigin-RevId: 395452741
- Fix focus when pausing and resuming
- Prevent repeated readout of the playback position when paused
#exofixit
#minor-release
Issue #9111
PiperOrigin-RevId: 395301765
The current detection logic checks that the two byte terminator starts
at an even position in the ID3 data, where-as it should check that it
starts at an even position relative to the start of the string.
#minor-release
#exofixit
Issue: #9087
PiperOrigin-RevId: 395274934
