SDK / exoplayer

PiperOrigin-RevId: 357158075

This behavior is consistent with DefaultControlDispatcher#dispatchNext().

#minor-release

PiperOrigin-RevId: 357145076

It's closely tied to SimpleExoPlayer, so cannot be part of a UI module
that depends only on common.

PiperOrigin-RevId: 357085802

The available end time was accidentally substracted by the start time
of the last period.

To avoid similar time reference confusion in the future, also renaming
many variables and methods to clearly reflect the time reference point.
And to avoid constant conversion, the processManifest method also
attempts to converge to time relative to the start of the window as
quickly as possible.

Issue: #8537
PiperOrigin-RevId: 357001624

If keepalive is disabled the existing code over-eagerly releases
DrmSession instances. This is arguably OK since a (Default)DrmSession
should be released before its (Default)Manager is released
(since the underlying MediaDrm instance might be released when the
manager is released). And if all sessions are released before the
manager is released then `sessions` is empty, so the loop is a no-op.

Issue: #8576
#minor-release
PiperOrigin-RevId: 356955308

The `DrmConfiguration.sessionForClearTypes` property is often used
to ensure a secure decoder is used for clear ads played in encrypted
content. This is because some devices show black frames when switching
decoders.

Before this change the DRM config isn't propagated down when
constructing the ad media source, meaning
`DrmSessionManager.DRM_UNSUPPORTED` is always used, which will
cause playback to switch from secure to clear decoder when transitioning
to an ad break (ignoring the MediaItem `sessionForClearTypes` option.

Issue: #8568

#minor-release

PiperOrigin-RevId: 356951124

Also move out of the mediacodec package into the util package.

PiperOrigin-RevId: 356949401

Issue: #4803

#minor-release

PiperOrigin-RevId: 356923345

It's used by the UI and mediasession modules. We may be able to move
it into the UI module if/when the mediasession module goes away.

PiperOrigin-RevId: 356734939

PiperOrigin-RevId: 356695284

Issue: #8565

#minor-release

PiperOrigin-RevId: 356691251

Without this a new manager is instantiated for every item in a playlist,
meaning the impact of caching improvements to DefaultDrmSessionManager
are reduced (since the cache doesn't persist across playlist items).

With this change, playlists of items with identical DRM config will use
the same manager instance (and thus share existing sessions).

Issue: #8523
#minor-release
PiperOrigin-RevId: 356690852

PiperOrigin-RevId: 356622155

All threads created by ExoPlayer should now have the prefix "ExoPlayer:".

PiperOrigin-RevId: 356518037

PiperOrigin-RevId: 356479682

PiperOrigin-RevId: 356474350

This parameterized test execute a single playback with a variety of
specified network conditions, user country and network types, and then
compares some basic ABR performance data against a dump file to detect
changes.

PiperOrigin-RevId: 356468304

ControlDispatcher and DefaultControlDispatcher also need
to move to common for the UI module. As does PlaybackPreparer,
although that will be removed entirely in a future release.

PiperOrigin-RevId: 356467394

PiperOrigin-RevId: 356456843

Also allow the player's prepared ad media period durations array to exceed the
length of the loaded ad URIs array, as it's possible for the player to buffer
an ad media period fully at the point where it's known that an ad is coming up
but its URI is still unknown.

#minor-release

PiperOrigin-RevId: 356249284

This may happen for HLS live streams without program date time
information.

Issue: #8560

#minor-release

PiperOrigin-RevId: 356227729

#minor-release

PiperOrigin-RevId: 356221487

PiperOrigin-RevId: 356157035

PiperOrigin-RevId: 355896218

We currently block the loading thread until the calculated load
time has past and then unblock again by a message sent from the
playback thread. However, because the loading thread itself is not
using a Looper and runs freely, we don't control when the short
calculations on the loader thread that determine how long we have
to wait are happening, and we also don't control how long it takes
to start and stop this thread.

To solve these problems and to make the playback deterministic we
can
 1. Send a message on the playback thread to block until the loader
    thread has started.
 2. Block the playback thread whenever a loading thread is doing its
    short calculation of wait times. The playback thread knows when it
    can continue because loading either enter a new waiting state for
    a simulated load time or loading is finished completely.
 3. Also wait on the playback thread until the loader has shut down.
    As this is waiting for a message on the playback thread, we can
    achieve this by sending messages to ourselves at the current time
    until the loader is shut down.
All 3 steps together ensure that the loading thread interaction is
compeltely deterministic when simulating bandwidth profiles with the
BandwidthProfileDataSource. As we need to notify the source before and
after the load started/finished, we also need a small wrapper for the
chunk source when running the playback.

PiperOrigin-RevId: 355810408

PiperOrigin-RevId: 355664280

PiperOrigin-RevId: 355659628

The current naming had cause confusinon in b/179369346
and #8545.

PiperOrigin-RevId: 355656404

#minor-release

PiperOrigin-RevId: 355652144

- When throwing a recoverable error from a renderer, it's important to understand
  exactly how the player will attempt recovery. Clarify the documentation to
  make this explicit.
- Rename some methods/constants to make it clear that error recovery is specific
  to renderer errors. The current recovery mechanism only makes sense for
  renderer errors. Making the naming renderer specific avoids reader doubt that
  the implementation doesn't appear to be generic enough for other types of
  errors.

PiperOrigin-RevId: 355650945

PiperOrigin-RevId: 355621265

It's for classes to clearly denote they support bundling and it gives
us a good place to document the best practice to implement fromBundle.

PiperOrigin-RevId: 355609942

Before, the level was set to null in this case.
MediaCodecUtil.getCodecProfileAndLevel() was therefore returning null
and the fallback to AVC/HEVC was not enabled in MediaCodecVideoRenderer.

Issue:#8530
#minor-release
PiperOrigin-RevId: 355574499

PiperOrigin-RevId: 355508621

In both cases it's deliberate that all excluded constants should use
the default branch. Furthermore, there are quite a lot of excluded
constants missing, so it's probably better to suppress the warning
than to include them all.

#minor-release

PiperOrigin-RevId: 355426749

This resolves the following constraint resolution issue when running our release script:

> Cannot find a version of 'org.chromium.net:cronet-api' that satisfies the version constraints:
    Dependency path 'com.google.android.exoplayer:extension-cronet:unspecified' --> 'com.google.android.gms:play-services-cronet:17.0.0' --> 'org.chromium.net:cronet-api:72.3626.96'
    Constraint path 'com.google.android.exoplayer:extension-cronet:unspecified' --> 'org.chromium.net:cronet-api:{strictly 72.3626.96}' because of the following reason: debugRuntimeClasspath uses version 72.3626.96
    Dependency path 'com.google.android.exoplayer:extension-cronet:unspecified' --> 'org.chromium.net:cronet-embedded:76.3809.111' --> 'org.chromium.net:cronet-common:76.3809.111' --> 'org.chromium.net:cronet-api:76.3809.111'

#minor-release

PiperOrigin-RevId: 355414968

Issue: #8427
PiperOrigin-RevId: 355381785

#minor-release

PiperOrigin-RevId: 355381610