SDK / exoplayer

*** Original commit ***

Don't call MediaDrm.setLogSessionId in FrameworkMediaDrm

This method throws an UnsupportedOperationException on some Android 12
devices.

***

PiperOrigin-RevId: 433708582

r2.17.1

#minor-release

PiperOrigin-RevId: 433499164
(cherry picked from commit 72bda9e6)

The variable marks the coordinates used to sample from a texture, so hopefully
this makes the naming a bit more descriptive.

This renames vTexCoords and aTexCoords. No functional changes intended.

PiperOrigin-RevId: 433499934

#minor-release

PiperOrigin-RevId: 433499164

This fixes an exception thrown when parceling becasue the type can not be found
(expects the AdsPlaybackState to be Serializable). Transforming the map and the
ad playback states to a Bundle fixes the problem.

#minor-release

PiperOrigin-RevId: 433491993

PiperOrigin-RevId: 433467068
(cherry picked from commit 153b16a8)

PiperOrigin-RevId: 433467719

#minor-release

PiperOrigin-RevId: 433467068

When the start position of a MediaPeriodInfo is equal or higher than the duration,
we set the start position to `duration - 1` to end on the last frame. With server
side inserted ad streams, this has the effect that we actually need to seek back to
the last content frame after a post-roll.

This is desirable when actually ending on that frame but produces a BUFFERING event
when transitioning from an SSAI stream with a post-roll to the next media item in
the playlist. This change sets the start position to the duration when we are
clipping the last content period of an SSAI stream that is played in a playlist.

PiperOrigin-RevId: 433445680

If an OpenGL call blocks because the encoder's input surface is full,
this will now block the background thread while the main thread can
continue querying encoder output and free up encoder capacity until
it accepts more input unblocking the background thread.

PiperOrigin-RevId: 433283287

*** Original commit ***

Fix PlayerView touch handling

Overriding onTouchEvent was causing multiple issues, and
appears to be unnecessary. Removing the override fixes:

1. StyledPlayerView accessibility issue where "hide player
   controls" actually toggled play/pause.
2. Delivery of events to a registered OnClickListener when
   useController is false.
3. Delivery of events to a registered OnLongClickListener
   in all configurations.
4. Incorrectly treating a sequence of touch events that
   exit the bounds of the vi...

***

PiperOrigin-RevId: 433262414

PiperOrigin-RevId: 433237266

With the new version, we try the following before fixing resolution:

- Fix size alignment
- Try 3/4 the width and height
- Try 2/3 the width and height
- Try 1/2 the width and height

Also: align the resolution ends in 1 or 9 to 0.
PiperOrigin-RevId: 433206358

PiperOrigin-RevId: 433174767

Overriding onTouchEvent was causing multiple issues, and
appears to be unnecessary. Removing the override fixes:

1. StyledPlayerView accessibility issue where "hide player
   controls" actually toggled play/pause.
2. Delivery of events to a registered OnClickListener when
   useController is false.
3. Delivery of events to a registered OnLongClickListener
   in all configurations.
4. Incorrectly treating a sequence of touch events that
   exit the bounds of the view before ACTION_UP as a click,
   both for delivery to OnClickListener and for toggling
   the controls.

Note: After this change, control visibility will not be
toggled if the application developer explicitly sets the
view to be non-clickable. I think that's probably working
as intended though. It seems correct that a non-clickable
view would not respond to clicks.

Issue: google/ExoPlayer#8627
Issue: google/ExoPlayer#9605
Issue: google/ExoPlayer#9861
PiperOrigin-RevId: 433016626

This change rewrites the UI module's track selection
components to depend on the Player API, allowing us to
finally remove the UI module's dependency on ExoPlayer
as a concrete player implementation.

PiperOrigin-RevId: 432989318

The change will be useful in testing transcoding performance

PiperOrigin-RevId: 432956283

PiperOrigin-RevId: 432937645

PiperOrigin-RevId: 432928418

Previously, we've used getSupportedHeights/Widths() to find the supported
resolution. However, the height/width can be over-reported when using these
APIs. For example, getSupportedWidths and getSupportedHeights can both return
3840, but the supported height when using 3840 as width is only 2160.

PiperOrigin-RevId: 432926192

This makes the reading period advance early as expected at the end of an ad
period. Before this change the reading position of the metadata renderer
prevented advancing the period until metadata arrived after the start position of
the following period. Only then the reading position of the metadata renderer
is updated and beyond the start position of the following period which is a
condition to advance the reading period.

Because transitioning to the next period is a virtual transition and the
SharedMediaPeriod keeps reading from the same underlying sample streams, the
metadata renderer can safely be ignored for this check.

PiperOrigin-RevId: 432646037
(cherry picked from commit 25e56804)

These should have been removed as part of https://github.com/google/ExoPlayer/commit/1391b7c65dab1856dad363dff7c0a250245f1671, since we no
longer officially support overriding the layout file for this class.

This class is known as StyledPlayerView in exoplayer2.

#minor-release

PiperOrigin-RevId: 432411322
(cherry picked from commit 41276e8b)

PiperOrigin-RevId: 432189509
(cherry picked from commit e66d0c90)

This method is no longer needed since we added SubtitleConfiguration#id
in https://github.com/google/ExoPlayer/commit/59d98b9a4e2381647f3e4552b6935bcca1be6f89.

Issue: google/ExoPlayer#10016

PiperOrigin-RevId: 432169262
(cherry picked from commit 540f2061)

PiperOrigin-RevId: 432154626
(cherry picked from commit 733cd609)

PiperOrigin-RevId: 431395359
(cherry picked from commit f66c9290)

PiperOrigin-RevId: 431376857
(cherry picked from commit 95c74f04)

When a live stream is joined while ads are already playing, the LOADED event is
missed and we don't have ad information for those ads in the ad group that are
before the ad index at which we joined. This way we can clip the duration when we
receive the LOADED event for the last ad in the group. This fixes the problem of
the playback controls being hidden when content resumes after the ad group.

#minor-release

PiperOrigin-RevId: 431269627
(cherry picked from commit da00f0c6)

The command is not needed, because the specified branch is already the
default branch on GitHub so will be checked out by clone automatically.

PiperOrigin-RevId: 430910549
(cherry picked from commit 6ed72dcd)

Issue: google/ExoPlayer#9996
PiperOrigin-RevId: 430773329
(cherry picked from commit 1bc4ba29)

Generated by running:
./gradlew wrapper --gradle-version 7.4 --distribution-type all

#minor-release

PiperOrigin-RevId: 430666317
(cherry picked from commit 8416f465)

#minor-release

PiperOrigin-RevId: 430454251
(cherry picked from commit f310a57a)

This makes the reading period advance early as expected at the end of an ad
period. Before this change the reading position of the metadata renderer
prevented advancing the period until metadata arrived after the start position of
the following period. Only then the reading position of the metadata renderer
is updated and beyond the start position of the following period which is a
condition to advance the reading period.

Because transitioning to the next period is a virtual transition and the
SharedMediaPeriod keeps reading from the same underlying sample streams, the
metadata renderer can safely be ignored for this check.

#minor-release

PiperOrigin-RevId: 432646037

PiperOrigin-RevId: 432485797

We will be migrating our track selection UI components to be
based on TracksInfo. We need DownloadHelper to expose TracksInfo
to make it compatible with such components.

PiperOrigin-RevId: 432474487

PiperOrigin-RevId: 432461547

addTrackSelectionForSingleRenderer takes a list of legacy overrides,
which are then set on the supplied parameters one at a time to run
track selection. This allows multiple overrides for a single track
type to be applied in the download use case, despite it not being
possible to place such overrides directly into a single parameters.

For new style overrides, multiple overrides for the same track type
can be placed directly into a single parameters. Therefore we'll be
able to replace use of addTrackSelectionForSingleRenderer with use
of addTrackSelection, which is a much cleaner API. For this to work,
we need to make DownloadHelper apply multiple overrides in this case.

PiperOrigin-RevId: 432459834