After removing the deprecated call to player.stop(/* reset= */ true) and instead using two calls to the player, overridding stop in a ForwardingPlayer does not help to avoid clearing the player. To remove the deprecation we need an option so that users who want not to clear the player have a way to do so.
PiperOrigin-RevId: 411518090
The player will not play ads in final states (played, skipped, error)
again. To allow ads loader customizations to play ads again, we can
add a method that resets the state back to available or unavailable
(depending on whether we have the URI for the ad).
Issue: google/ExoPlayer#9615
PiperOrigin-RevId: 411042842
Currently, DrmSessionManager takes player specific values (= the
playback looper) through (pre)acquireSession calls and requires
the caller to pass in the same values every time.
Instead, we can configure the DrmSessionManager for playback with
a player once before it's being used. We can't simply extend the
prepare() method as prepare may be called before the player is
created to prewarm the DrmSessionManager.
The new method also takes a PlayerId which is bound to the lifetime
of the player similar to the playback looper.
To avoid breakage of custom MediaSources with DRM, we can keep the
old the SampleQueue.createWithDrm method as deprecated.
PiperOrigin-RevId: 410998240
Populate ICY headers into MediaMetadata so that they can
propagate to the app via AnalyticsListener#onMediaMetadataChanged().
This change copies IcyHeaders.name into MediaMetadata.description
and IcyHeaders.genre into MediaMetadata.genre.
Note: MediaItem.metadata maintain their precedence and overwrite any
ICY headers parsed.
Issue: google/ExoPlayer#9677
#minor-release
PiperOrigin-RevId: 410495676
We already parse essential and supplemental properties from the
Representation, but don't add them to our Representation class so that
they can be accessed by users.
Issue: google/ExoPlayer#9579
PiperOrigin-RevId: 409961990
When we have multiple overrides for TrackGroups associated with
one renderer, we need to look at all of them to find the non-empty
one. Empty ones should only be used to remove previously selected
tracks for this group and otherwise be ignored.
Currently this is broken because the first override (no matter if
it's empty or not) is used as the final selection for this renderer.
Issue: google/ExoPlayer#9649
#minor-release
PiperOrigin-RevId: 407792330
Add protected method DefaultRenderersFactory.getCodecAdapter(), so that
subclasses of DefaultRenderersFactory that override
buildVideoRenderers() or buildAudioRenderers() can access the
DefaultRenderersFactory codec adapter factory and pass it to
MediaCodecRenderer instances they may create.
#minor-release
PiperOrigin-RevId: 407345431
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
Test file produced with:
$ MP4Box -add "sample.mp4#video:colr=nclc,1,1,1" -new sample_18byte_nclx_colr.mp4
And then manually changing the `nclc` bytes to `nclx`.
This produces an 18-byte `colr` box with type `nclx`. The bitstream of
this file does not contain HDR content, so the file itself is invalid
for playback with a real decoder, but adding the box is enough to test
the extractor change in this commit.
(aside: MP4Box will let you pass `nclx`, but it requires 4 parameters, i.e. it
requires the full_range_flag to be set, resulting in a valid 19-byte colr box)
#minor-release
Issue: #9332
PiperOrigin-RevId: 405842520
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
