SDK / exoplayer

This test became flaky after https://github.com/google/ExoPlayer/commit/cbb6878f9fef20ea440c6ffda77dd4edc00ce1f2 because some of the
unrealistic frame times ended up on the same release time.

Using realistic numbers avoids the flakiness.

PiperOrigin-RevId: 512566469
(cherry picked from commit 13700e0a)

Protected system broadcasts should not specify the export flag.
Marking them as NOT_EXPORTED breaks sticky broadcasts in some
cases.

Issue: google/ExoPlayer#10970

#minor-release

PiperOrigin-RevId: 512020154
(cherry picked from commit 34b98242)

PiperOrigin-RevId: 512002735
(cherry picked from commit 1ef70cd6)

The current logic uses manual array operations to keep track of pending
changes. Modernize this code by using an ArrayDeque and a data class.
This also allows to extend the output stream information in the future.

This also fixes a bug where a position reset accidentally assigns a pending
stream offset instead of keeping the current one.

PiperOrigin-RevId: 511787571
(cherry picked from commit 4e0babdc)

Issue: google/ExoPlayer#10992

#minor-release

PiperOrigin-RevId: 510988140
(cherry picked from commit 57a638aa)

When rendering frames at a rate higher than the screen refresh rate,
e.g. playing at 8x, the player is releasing multiple frames at the same
release time (nanos) which are then dropped by the platform. The output
buffers are available later and as a result MediaCodec cannot keep up
decoding fast enough.

This change skips releasing multiple video frames on the same vsync
period and proactivelly drops the frame. The frame is counted as skipped
rather than dropped to differentiate with frames dropped due to slow
decoding.

PiperOrigin-RevId: 510964976
(cherry picked from commit cbb6878f)

This call may cause performance overhead in some situations,
for example if the AudioTrack needs to query an offload DSP
for the current position. We don't need to check this multiple
times per doSomeWork iteration as the value is unlikely to
change in any meaningful way.

PiperOrigin-RevId: 510957116
(cherry picked from commit 829b49d7)

#minor-release
Issue: androidx/media#245
PiperOrigin-RevId: 510456793
(cherry picked from commit a231ff4f)

PiperOrigin-RevId: 509473556
(cherry picked from commit 08cf6db3)

In parsing Describe RTSP response messages, IllegalArgumentExceptions are thrown for invalid parameters and values. These exceptions were not caught and crashed the Playback thread. Now these exceptions will be caught and their errors forwarded to the proper error handling listeners.

#minor-release

Issue: google/ExoPlayer#10971
PiperOrigin-RevId: 509207881
(cherry picked from commit 711fa44d)

#minor-release

PiperOrigin-RevId: 509189206
(cherry picked from commit e98670e2)

The AsynchronousMediaCodecAdapter's queuing thread stores any exceptions
raised by MediaCodec and re-throws them on the next call to
queueInputBuffer()/queueSecureInputBuffer(). However, if MediaCodec
raises and error while queueing, it goes into a failed state and does
not announce available input buffers. If there is no input available
input buffer, the MediaCodecRenderer will never call
queueInputBuffer()/queueSecureInputBuffer(), hence playback is stalled.

This change surfaces the queueing error through the adapter's dequeueing
methods.

PiperOrigin-RevId: 508637346
(cherry picked from commit a5f4651d)

`TrackSelectorResult.rendererConfigurations` can contain null elements:
> A null entry indicates the corresponding renderer should be disabled.

This wasn't caught by the nullness checker because `ExoPlayerImpl` is
currently excluded from analysis.

#minor-release

Issue: google/ExoPlayer#10977
PiperOrigin-RevId: 508619169
(cherry picked from commit 5e3cd7a3)

PiperOrigin-RevId: 508602059
(cherry picked from commit 1c291310)

PiperOrigin-RevId: 508323432
(cherry picked from commit 20a5e468)

PiperOrigin-RevId: 507784608
(cherry picked from commit 08342ea9)

The AudioTrackPositionTracker needs to correct positions by
the speed set on the AudioTrack itself whenever it makes
estimations based on real-time (=the real-time playout
duration is not equal to the media duration played).

This happens for the main playback path already, but not for
the mode in which the position is estimated from the playback
head position and also not in the phase after the track has
been stopped. Both cases are not very noticeable during
normal playback, but become relevant when playing in offload
mode.

PiperOrigin-RevId: 507736408
(cherry picked from commit 4ede931c)

In MediaCodecUtil, use Format.colorInfo, besides the codec string,
to accurately map to a 10bit HEVC profile.

PiperOrigin-RevId: 507500071
(cherry picked from commit 80dbaca0)

r2.18.3

#minor-release

PiperOrigin-RevId: 509867431
(cherry picked from commit 482871fe)

#minor-release

PiperOrigin-RevId: 509864205
(cherry picked from commit 19d4a588)

#minor-release

PiperOrigin-RevId: 509789955
(cherry picked from commit 4759e007)

#minor-release

PiperOrigin-RevId: 509501665
(cherry picked from commit b18dccde)

#minor-release

PiperOrigin-RevId: 509246479
(cherry picked from commit 8ff024e4)

Can be used to combine multiple media items into a single timeline window.

Issue: androidx/media#247
Issue: google/ExoPlayer#4868
PiperOrigin-RevId: 506283307
(cherry picked from commit eb8fffba)

PiperOrigin-RevId: 506261584
(cherry picked from commit 107e0c6e)

I missed this when fixing `positionInMs` for Dackka in https://github.com/google/ExoPlayer/commit/d2a3d8f6fabb6d22ac28a76379725d0915344cba

This time I manually verified that all the `@Override` methods have
parameter names that match [the docs](https://developer.android.com/reference/androidx/leanback/media/PlayerAdapter).

#minor-release

PiperOrigin-RevId: 506017063
(cherry picked from commit 736f090c)

When seeking in fMP4, we try to extract as little samples as possible
by only starting at the preceding sync frame. This comparison should
use <= to allow sync frames at exactly the seek position.

Issue: google/ExoPlayer#10941

#minor-release

PiperOrigin-RevId: 505098172
(cherry picked from commit ac3017b5)

MergingMediaPeriod creates its track groups with ids concatenating position in its periods array and the underlying child track group id. The ids can be used in selectTracks for matching to periods list.

Issue: google/ExoPlayer#10930
PiperOrigin-RevId: 505074653
(cherry picked from commit ee055ef0)

For most missing commands, we already disable the corresponding
controls. This change extends this to more UI elements that are
disabled in case the corresponding action is unavailable.

#minor-release

PiperOrigin-RevId: 505057751
(cherry picked from commit 641c3b1b)

The commands are partly checked already before enabling
features or calling player methods, but the checks were
still missing in many places.

#minor-release

PiperOrigin-RevId: 504589888
(cherry picked from commit 2d7ddcce)

#minor-release

PiperOrigin-RevId: 504517946
(cherry picked from commit f083ff26)

ImaUtil calls VideoProgressUpdate.equals() which is annotated as hidden,
which causes lint errors with gradle.

#minor-release

PiperOrigin-RevId: 504306210
(cherry picked from commit f86948f0)

PiperOrigin-RevId: 504281747
(cherry picked from commit 4c1be4c7)

The "Transforming media" page has been updated with changes that won't
be part of the next release. Undo these changes so that this page is
consistent with the latest release.

PiperOrigin-RevId: 503917637
(cherry picked from commit fdf86661)

This makes it implicitly clear that if the value of a getter changes due
to a change in command availability then the listener will be invoked,
without needing to explicitly document every command on every listener
method.

#minor-release

PiperOrigin-RevId: 503178383
(cherry picked from commit aa23920e)

We currently only document it for the getCurrentMediaItem(), but
the command was always meant to cover all information about the
current media item and the position therein.

To correctly hide information for controllers, we need to filter
the Timeline when bundling the PlayerInfo class if only this
command is available.

PiperOrigin-RevId: 503098124
(cherry picked from commit 5e9c9ed2)

When bundling PlayerInfo, we need to remove information if the
controller is not allowed to access it. This was only partially
done at the moment.

PiperOrigin-RevId: 502852798
(cherry picked from commit 50f066d6)

PiperOrigin-RevId: 502821506
(cherry picked from commit 8fcd6bbf)

When bundling PlayerInfo, we remove data when the controller is not
allowed to access this data via getters. We also remove data for
performance reasons. In the toBundle() method, it's currently hard to
make the connection between allowed commands and filtering, because
the values are checked at a different place. This can be made more
readable by forwarding the applicable Commands directly.

The only functional fix is to filter the Timeline when sending the
first PlayerInfo after a connecting a controller if the command to
get the Timeline is not available. This also allows us to remove a
path to filter MediaItems from Timelines as it isn't used.

PiperOrigin-RevId: 502607391
(cherry picked from commit 5461d5cb)