SDK / exoplayer

Added another check in test to make sure we don't add keys to bundle for fields with `null` values.

PiperOrigin-RevId: 496948705

Issue: google/ExoPlayer#10845
PiperOrigin-RevId: 496947392

PiperOrigin-RevId: 496942702

AssetLoader declares the tracks with a setTrackCount() method. Setting
the track count on the MuxerWrapper is easier than calling
registerTrack() as many times as the number of tracks.

PiperOrigin-RevId: 496933501

Issue: google/ExoPlayer#10854
PiperOrigin-RevId: 496922055

AssetLoader declares the tracks with a setTrackCount() method. Setting
the track count on the FallbackListener is easier than calling
registerTrack() as many times as the number of tracks.

PiperOrigin-RevId: 496919969

The TransformationRequest passed to FallbackListener (and
createSupportedTransformationRequest) can have null for values that
are inferred from source. Within fallback, this can be height, width,
video mime type and audio mime type (HDR mode is not linked to source).
requestedFormat has these values populated from source, and
supportedFormat then finds the closest supported values to the
requested.

If any of the values in supportedFormat do not match the
requestedFormat, then this method would build upon the
TransformationRequest and update ALL possible fallback fields. This is
a problem because the fallback listener compares the original request
to the fallback one and notifies about all the fields that have
changed.

This CL changes this so that only the values that are not the same as
requested are changed in the supported request that is given to the
fallback listener.

PiperOrigin-RevId: 496908492

When trying to run the test on Android Studio, error "incompatible
types: Buffer cannot be converted to ByteBuffer" is logged. This is
because ByteBuffer.flip() returns a Buffer (and not a ByteBuffer).
Annotation @CovariantReturnType on ByteBuffer.flip() should resolve this
automatically but it doesn't seem supported at the moment.
PiperOrigin-RevId: 496894723

There are two overloads of this method due to a type 'rename' from
`PlayerControlView.VisibilityListener` to
`PlayerView.ControllerVisibilityListener`. Currently when you call one
overload it passes `null` to the other one (to clear the other listener).
Unfortunately this results in it clearing itself, because it receives
a null call back!

This change tweaks the documentation to clarify that the 'other'
listener is only cleared if you pass a non-null listener in. This solves
the recursive problem, and allows the 'legacy' visibility listener to be
successfully registered.

Issue: androidx/media#229

#minor-release

PiperOrigin-RevId: 496876397

Users of this class may run into these assertions when creating the
State and they need to check the source code to understand why
the State is invalid. Adding error messages to all our correctness
assertions helps to understand the root cause more easily.

PiperOrigin-RevId: 496875109

Replace onTrackRegistered and onAllTracksRegistered with onTrackCount.

PiperOrigin-RevId: 496853037

PiperOrigin-RevId: 496768072

PiperOrigin-RevId: 496727803

This CL replaces concurrent collections and atomic primitives with a single
lock, this way the code is easier to reason about.

PiperOrigin-RevId: 496718057

Note that we simply use GlEffectsFrameProcessor in-app / GL tone-mapping, so PQ->SDR tone-mapping isn't yet implemented.

Tested manually using the demo on Pixel 7, to confirm that device and in-app tone
mapping behave similarly.

PiperOrigin-RevId: 496700231

Adds the AudioMixerAlgorithm interface which allows for specialized
implementations of audio mixing that also efficiently convert between
source and mixing formats.

Initial implementation has two algorithms:
1. Float -> float (with channel mixing)
2. S16 -> float (with channel mixing)

PiperOrigin-RevId: 496686805

#minor-release

PiperOrigin-RevId: 496668378

PiperOrigin-RevId: 496664711

#minor-release

PiperOrigin-RevId: 496661152

PiperOrigin-RevId: 496660388

To do that, rename PROGRESS_STATE_NO_TRANSFORMATION to
PROGRESS_STATE_NOT_STARTED and update Javadoc of ProgressState to not be
Transformer specific.

PiperOrigin-RevId: 496653460

PiperOrigin-RevId: 496410502

This should allow us to focus on HDR failures instead of network buffering
failures when debugging HDR issues.

These files are each used on several files, so it should be more worth the
test binary impact to move these files to local first.

Locally, tests did take less time after this diff

PiperOrigin-RevId: 496398130

The MediaSourceFactory won't be used by the other AssetLoaders

In order to do that, ExoPlayerAssetLoader has been made public, and the
DefaultAssetLoaderFactory has become a wrapper around
ExoPlayerAssetLoader.

PiperOrigin-RevId: 496386853

PiperOrigin-RevId: 496379904

https://developer.android.com/reference/androidx/leanback/media/PlayerAdapter#seekTo(long)

#minor-release

PiperOrigin-RevId: 496378709

PiperOrigin-RevId: 496377192

These are the remaining setter operations. They all share the same
logic that handles playlist and/or position changes. The logic to
create the placeholder state is mostly copied from ExoPlayerImpl's
maskTimelineAndPosition and getPeriodPositonUsAfterTimelineChanged.

PiperOrigin-RevId: 496364712

*** Original commit ***

Add TransformerTestBuilderFactory to make transformer testable by apps

***

PiperOrigin-RevId: 496342997

*** Original commit ***

Remove extra colons in `build.gradle`s

modulePrefix should include this already.

***

PiperOrigin-RevId: 496337833

FrameProcessor already support using different transfer function for input and
output color. This CL has two major changes:

- Create an eglSurface that recognizes BT.2020 PQ
  - This requires a separate extension that works only after 33
  - So we current throw, if input is HDR, and this extension doesn't work
- Create FrameProcessor with PQ output transfer function

PiperOrigin-RevId: 496023758

The tunneling callbacks are sent via Handler messages and may be
handled after the codec/surface was changed or released.

We already guard against the codec/surface change condition by
creating a new listener and verifying that the current callback
happens for the correct listener instance, but we don't guard
against a released codec yet.

PiperOrigin-RevId: 495882353

PiperOrigin-RevId: 495860300

Some Player methods operate relative to existing indices in the
playlist (add,remove,move,seek). As these operations may be issued
from a place with a stale playlist (e.g. a controller that sends
a command while the playlist is changing), we have to handle out-
of-bounds indices gracefully. In most cases this is already
documented and implemented correctly. However, some cases are not
documented and the existing player implementations don't handle
these cases consistently (or in some cases not even correctly).

PiperOrigin-RevId: 495856295

modulePrefix should include this already.

PiperOrigin-RevId: 495853065

The `MediaItem` instances in the following cases are not actually empty but acts as a placeholder. `EMPTY_MEDIA_ITEM` can also be confused with `MediaItem.EMPTY`.

PiperOrigin-RevId: 495843012

PiperOrigin-RevId: 495842393

PiperOrigin-RevId: 495821660

PiperOrigin-RevId: 495646341

Issue: androidx/media#220
PiperOrigin-RevId: 495642588