SDK / exoplayer

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

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

#minor-release

PiperOrigin-RevId: 406347412

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. The exception is
ExoPlayer.Builder.AnalyticsCollector which became nullable and is
initialized in ExoPlayer.Builder.build() in order to use any Clock
that has been set separately with ExoPlayer.Builder.setClock().

#minor-release

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

#minor-release

PiperOrigin-RevId: 406163529

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

PiperOrigin-RevId: 406101742

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

`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
https://github.com/google/ExoPlayer/commit/98200c2692ba007ba0b177d7b285b957dc08ff93

#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

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: 405736227

- This CL does not introduce functional changes.
- This change will allow searching for the clli box while
  parsing the mdcv box in order to construct the HDR
  static info contained in ColorInfo.

#minor-release

PiperOrigin-RevId: 405656499

Also check that the output video MIME type is supported with the given container MIME type in `TranscodingTransformer` and `TransformerBaseRenderer`.

PiperOrigin-RevId: 405645362

This has a few benefits:
  * Aligns the Builder constructors with the setters
    (setRenderersFactory is missing, but can be easily added in a
    follow-up change).
  * Allows DefaultMediaSourceFactory to be stripped by R8 and
    makes the shrinking dev guide for the cases of providing a custom
    MediaSourceFactory or directly instantiating MediaSource instances
    less weird too.

#minor-release

PiperOrigin-RevId: 405632981

When no encoder video MIME type is specified, the `TransformerTranscodingVideoRenderer` now uses the video MIME type of the input for the encoder format.
The input format is now read in a new method `ensureInputFormatRead` which is called before the other configuration methods. This removes the logic for reading the input format from `ensureDecoderConfigured`, because it is now needed for both encoder and decoder configuration but the encoder needs to be configured before GL and GL needs to be configured before the decoder, so the decoder can't read the format.
The width and height are now inferred from the input and the frame rate and bit rate are still hard-coded but set by the `MediaCodecAdapterWrapper` instead of `TranscodingTransformer`.

PiperOrigin-RevId: 405631263

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