SDK / exoplayer

Relanding http://https://github.com/androidx/media/commit/9788750ddb23b2064dddf99d6e1ea491b2e45cea, with some changes
applied to improve primarily readability, naming,
and nullness checks.

PiperOrigin-RevId: 406101742

#minor-release

PiperOrigin-RevId: 405927299

Only deprecated references remain.

Usages of the deprecated methods will be migrated in a follow-up change.

#minor-release

PiperOrigin-RevId: 405927141

Also add a setRenderersFactory() method, so that all constructor-provided
components can also be passed via setters.

This comment already appears on the constructor that takes all
components, but it applies to these ones as well.

PiperOrigin-RevId: 405917343

PiperOrigin-RevId: 405909676

`checkNotNull` should be avoided where possible.
This change adds `@EnsuresNonNull` or `@EnsuresNonNullIf` to configuration methods for fields they initialize.

`checkNotNull` is now avoided for the `@MonotonicNonNull` formats by adding `@RequiresNonNull` annotations.

`checkNotNull` is now avoided for the encoder and decoder in `feedMuxerFromEncoder()`, `feedEncoderFromDecoder()`, `feedDecoderFromInput()`, etc. by creating local variables for `encoder` and `decoder` in `render` after the configuration method calls and passing these as non-null parameters.

PiperOrigin-RevId: 405893824

No other index-related methods in Player are annotated, it's considered
obvious that these should be >=0.

PiperOrigin-RevId: 405882756

Should have been part of
<unknown commit>

#minor-release

PiperOrigin-RevId: 405880982

Our package-info.java files are annotated with @NonNullApi which results
in everything being non-null by default, so this annotation is never
needed.

#minor-release

PiperOrigin-RevId: 405864737

PiperOrigin-RevId: 405862549

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

PiperOrigin-RevId: 405841397

PiperOrigin-RevId: 405837263

PiperOrigin-RevId: 405825700

PiperOrigin-RevId: 405736227

PiperOrigin-RevId: 405656499

PiperOrigin-RevId: 405626270

PiperOrigin-RevId: 405626096

PiperOrigin-RevId: 405624136

PiperOrigin-RevId: 405616711

PiperOrigin-RevId: 405598530

PiperOrigin-RevId: 405592960

This has been done for (almost) all span types.

PiperOrigin-RevId: 405588294

PiperOrigin-RevId: 405473686

PiperOrigin-RevId: 405429757

PiperOrigin-RevId: 405408606

PiperOrigin-RevId: 405396600

PiperOrigin-RevId: 405394994

PiperOrigin-RevId: 405391455

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

PiperOrigin-RevId: 405379511

PiperOrigin-RevId: 405377964

PiperOrigin-RevId: 405375352

This introduces a new option `setAudioMimeType` in `TranscodingTransformer.Builder` and a corresponding check whether the selected type is supported. This check is done using `supportsSampleMimeType` which is now part of the `Muxer.Factory` and `MuxerWrapper` rather than `Muxer`.
A new field `audioMimeType` is added to `Transformation` and the `TransformerAudioRenderer` uses this instead of the input MIME type if requested.

PiperOrigin-RevId: 405367817

Decoded video frames can be large and there is no need to retrieve the
corresponding ByteBuffer as we render the decoded frames on a surface
for better performance.

PiperOrigin-RevId: 405364950

The current API exposes an `ImmutableMap` of
`TrackGroup` -> `TrackSelectionOverride`.
This has several disadvantages:
 - A difficult to use API for mutation
   (`ImmutableMap.Builder` doesn't support key removal).
 - There is no track selection specific methods,
   how the generic map API mapps to the selection override is not complex
   but to obvious for a casual reader.
 - The internal data type is exposed, making internal refactor difficult.

This was done to have the API ready as quick as possible.

When transitioning the clients to the map API in <unknown commit>,
it became clear that the map API was too verbose and not mapping
to the clients needs, so utility methods
were added to make operations clearer and more concise.

Nevertheless, having to use utility method to use easily and correctly
an API is not the sign of a good API.

This cl refactors the track selection API for several improvements:

 - Add a type `TrackSelectionParameters` that encapsulate the internal
   data structure (map currently).
 - For iteration, expose as a list.
 - Add a `Builder` for easy mutable operations.
 - Add track selection specific methods to avoid having utilities functions.
 - Those operations are the same as `DefaultTrackSelector.Parameters`
   for easier migration. (`setOverride` was renamed to `addOverride`)
 - Move `TrackSelection` classes outside of `TrackSelectionParameters`
   as their own top level classes.

The migration of the client code is straightforward as most of it
were already using the previously mentioned utility functions
that are now native methods.

The full migration has not been done yet, and is pending on this cl approval.

PiperOrigin-RevId: 405362719

PiperOrigin-RevId: 404897119

PiperOrigin-RevId: 404876228

PiperOrigin-RevId: 404851976

PiperOrigin-RevId: 404810682