SDK / exoplayer

#minor-release

PiperOrigin-RevId: 407042882

Where this introduced an inconsistency (e.g. assigning to something
called `windowIndex`), I generally renamed the transitive closure of
identifiers to maintain consistency (meaning this change is quite
large). The exception is code that interacts with Timeline and Window
directly, where sometimes I kept the 'window' nomenclature.

#minor-release

PiperOrigin-RevId: 407040052

Accidental changes were introduced in http://https://github.com/androidx/media/commit/c07c4cc95dc4ff625e4f95d8f5c06d31141c6fd8

PiperOrigin-RevId: 406858888

PiperOrigin-RevId: 406849436

The values are equivalent and we can suppress the warning.

PiperOrigin-RevId: 406839242

PiperOrigin-RevId: 406839109

The video scaling mode and stream type defines a default constant
that needs to be added to the IntDef definition to be assignable.

PiperOrigin-RevId: 406835696

The variable is storing OpenGL's draw mode, which is different from Projection.DrawMode.

PiperOrigin-RevId: 406820812

The return values of AudioManager.getPlaybackOffloadSupport are the same as the values defined in C.AudioManagerOffloadMode.

PiperOrigin-RevId: 406817413

PiperOrigin-RevId: 406816023

The presentation time in fMP4 is calculated by adding and subtracting
3 values. All 3 values are currently converted to microseconds first
before the calculation, leading to rounding errors. The rounding errors
can be avoided by doing the conversion to microseconds as the last step.

For example:
In timescale 96000:  8008+8008-16016 = 0
Rounding to us first: 83416+83416-166833=-1

#minor-release

PiperOrigin-RevId: 406809844

Currently, clipping errors are never thrown if we already have a
MediaPeriod. This may happen for example for ProgressiveMediaSource
where we need to create a MediaPeriod before knowing whether clipping
is supported. Playback will still fail, but with unrelated assertion
errors that are hard to understand for users.

Fix this by setting the pending error on the ClippingMediaPeriod.

#minor-release

Issue: Issue: google/ExoPlayer#9580
PiperOrigin-RevId: 406809737

These IntDefs are now annotated with TYPE_USE [1], so they can be moved
to directly before the type (int).

[1] Since https://github.com/androidx/media/commit/9ba21a75f

PiperOrigin-RevId: 406803555

This allows the use of the intdef in parameterized types,
e.g. List<@MyIntDef Integer>

For IntDefs that are already released in ExoPlayer 2.15.1 we add
TYPE_USE in addition to all other reasonable targets, to maintain
backwards compatibility with Kotlin code (where an incorrectly
positioned annotation is a compilation failure). 'reasonable targets'
includes FIELD, METHOD, PARAMETER and LOCAL_VARIABLE but not TYPE,
CONSTRUCTOR, ANNOTATION_TYPE, PACKAGE or MODULE. TYPE_PARAMETER is
implied by TYPE_USE.

For not-yet-released IntDefs we just add TYPE_USE.

#minor-release

PiperOrigin-RevId: 406793413

PiperOrigin-RevId: 406789671

This helps to prevent issues where decoders can't handle negative
timestamps. In particular it avoids issues when the media accidentally
or intentionally starts with small negative timestamps. But it also
helps to prevent other renderer resets at a later point, for example
if a live stream with a large start offset is enqueued in the playlist.

#minor-release

PiperOrigin-RevId: 406786977

PiperOrigin-RevId: 406783965

deviceVolume (int) and volume (float) are not the same. Elsewhere
MediaControllerImplLegacy doesn't support volume and defaults to 1
(setVolume, getVolume), so defaulting to 1 here seems correct.

PiperOrigin-RevId: 406780391

PiperOrigin-RevId: 406385758

This refactoring is the basis to support RF64 (see
Issue: google/ExoPlayer#9543).

#minor-release

PiperOrigin-RevId: 406377924

AnalyticsListener should not be used for non-analytical actions.

PiperOrigin-RevId: 406355758

PiperOrigin-RevId: 406354526

PiperOrigin-RevId: 406347510

Initialize default components lazily in ExoPlayer.Builder to avoid
redundant component instantiations, useful in cases where apps
overwrite default components with ExoPlayer.Builder setters.

The fields in ExoPlayer.Builder are wrapped in a Supplier (rather than
just making then nullable and initializing them in
ExoPlayer.Builder.build()) so that we maintain the proguarding
properties of this class.

PiperOrigin-RevId: 406345976

PiperOrigin-RevId: 406332026

This makes sure that #EXT-X-RENDITION-REPORT tags can be placed before
the list of segments/parts as well. We were previously assuming that
these come at the end, which naturally would make sense and is done like
this in all examples, but it is not explicitly defined by the spec.

Issue: google/ExoPlayer#9592
PiperOrigin-RevId: 406329684

PiperOrigin-RevId: 406255369

#minor-release

PiperOrigin-RevId: 406166670

These seem to be describing an exception being thrown based on a
property of the value being returned from this method? Or is the
expectation that every implementation of this interface throws the
AssertionError themselves.

Given AssertionError is unchecked, and shouldn't be explicitly caught
anywhere, it seems easiest just to remove all this documentation?

PiperOrigin-RevId: 406107606

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