SDK / exoplayer

PiperOrigin-RevId: 407540705

And in a couple of related places.

This is for consistency with the rest of the codebase where
we exclusively use indices.

#minor-release

PiperOrigin-RevId: 408273372

#minor-release

PiperOrigin-RevId: 408269341

#minor-release

PiperOrigin-RevId: 407847729

#minor-release

PiperOrigin-RevId: 407843859

The ExoPlayer.Builder constructor overloads are only needed for apps
trying to ensure certain classes are removed by R8/proguard, which isn't
relevant for the demo app.

PiperOrigin-RevId: 407819694

When we have multiple overrides for TrackGroups associated with
one renderer, we need to look at all of them to find the non-empty
one. Empty ones should only be used to remove previously selected
tracks for this group and otherwise be ignored.

Currently this is broken because the first override (no matter if
it's empty or not) is used as the final selection for this renderer.

Issue: google/ExoPlayer#9649

PiperOrigin-RevId: 407792330

r2.16.0

PiperOrigin-RevId: 407379522

PiperOrigin-RevId: 407333525

PiperOrigin-RevId: 407314385

This cause the muxer to fail to stop on older devices/API levels.

#minor-release

PiperOrigin-RevId: 407309028

#minor-release

PiperOrigin-RevId: 407305661

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

#minor-release

PiperOrigin-RevId: 407301056

PiperOrigin-RevId: 407162673

#minor-release

PiperOrigin-RevId: 407136922

These warnings are caused by the fact that this is a library and the
lint check doesn't see any app using the library in a TV context.

PiperOrigin-RevId: 407110725

#minor-release

PiperOrigin-RevId: 407086818

The values returned by the framework method are equivalent to the local IntDef values.

PiperOrigin-RevId: 407048748

#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/google/ExoPlayer/commit/c53924326dd100874d080c55812659a3cb9e843a

PiperOrigin-RevId: 406858888

PiperOrigin-RevId: 406849436

PiperOrigin-RevId: 406840246

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

PiperOrigin-RevId: 406827799

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

AudioAttributesCompat.AttributeUsage and C.AudioUsage use equivalent values and can be directly assigned.

PiperOrigin-RevId: 406815447

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 <unknown commit>

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