SDK / exoplayer

GlViewGroup doesn't work properly as an actual ViewGroup. For example,
it doesn't support addition of child views after instantiation. This
change turns the class into a renderer, which is also more consistent
with other classes in the package.

PiperOrigin-RevId: 275322295

PiperOrigin-RevId: 275293735

*** Original commit ***

Rollback of https://github.com/google/ExoPlayer/commit/3b22db33ba944df6829b1eff328efb0cd25e1678

*** Original commit ***

add top-level playlist API to ExoPlayer

Public design doc:
https://docs.google.com/document/d/11h0S91KI5TB3NNZUtsCzg0S7r6nyTnF_tDZZAtmY93g

Issue: #6161

***

***

PiperOrigin-RevId: 275276158

PiperOrigin-RevId: 275233915

If an odd resolution is impossible in the specification itself, then we know
that the caller is passing invalid data. Round up on the assumption it's a
rounding error so that playback can proceed.

Issue: #6551
PiperOrigin-RevId: 275226813

It makes observing differences without and with tunneling
much faster than recompiling.

PiperOrigin-RevId: 275216567

PiperOrigin-RevId: 275052534

PiperOrigin-RevId: 275014741

Feature enabled through the SimpleExoPlayer.setHandleAudioBecomingNoisy.

PiperOrigin-RevId: 274988924

This gives a clear way to ensure all the preparation-related @MonotonicNonNull
fields have been set to something.

PiperOrigin-RevId: 274988280

Same change as done in https://github.com/google/ExoPlayer/commit/c49388aca2047ed7680e7d8834def4f769060e2d.

PiperOrigin-RevId: 274894288

It's more explicit and simpler than having the subclass call up into
the activity.

PiperOrigin-RevId: 274881350

PiperOrigin-RevId: 274848191

PiperOrigin-RevId: 274845045

PiperOrigin-RevId: 274834663

Issue:#2668
PiperOrigin-RevId: 274793644

PiperOrigin-RevId: 274789337

Use composition instead.

This makes the null-handling more explicit & complete (previous implementation
tried to prevent null values, but didn't override all mutation methods
e.g. replace(), putIfAbsent() etc.)

PiperOrigin-RevId: 274778513

- Simplify the supported formats configuration by moving it to a
  separate variable, therefore avoiding updating the COMMON_OPTIONS
  variable in the ffmpeg build command.
- Move the ffmpeg build command to a shell script.

PiperOrigin-RevId: 274778232

Generates a manifest to have Google3InstrumentationTestRunner in order to fix the error in Zapfhahn (service to measure test coverage)

PiperOrigin-RevId: 274754720

The corresponding devices are Wiko FEVER l5460 and Huawei Honor 8X.

Issue:#6503
PiperOrigin-RevId: 274753710

*** Original commit ***

Remove null-ness of muxedCaptionFormats list

Pre-work for removing HlsMasterPlaylist and HlsPlaylistParser from null-checking
blacklist.

***

PiperOrigin-RevId: 274591502

Pre-work for removing HlsMasterPlaylist and HlsPlaylistParser from null-checking
blacklist.

PiperOrigin-RevId: 274585117

PiperOrigin-RevId: 274585052

PiperOrigin-RevId: 274568961

PiperOrigin-RevId: 274568660

PiperOrigin-RevId: 274566133

PiperOrigin-RevId: 274564800

PiperOrigin-RevId: 274561876

I could do this with nullSafeArrayConcat but this saves allocating a throw-away
single-element array.

PiperOrigin-RevId: 274545815

PiperOrigin-RevId: 274545728

PiperOrigin-RevId: 274537528

PiperOrigin-RevId: 274534626

If a surface was previously passed to the player then an output buffer
renderer was set, we would remove surface callbacks but not clear the
surface on renderers that accept MSG_SET_SURFACE.

PiperOrigin-RevId: 274532266

Add a javadoc explanation for ProgressiveDownloader that explains that it tries to skip downloading already cached bytes.

download calls through to CacheUtil#cache, which handles skipping already downloaded bytes.

It is useful for callers to know that ProgressiveDownloader has this behavior - otherwise, they might reimplement the logic themselves.

I hope this behavior is something that can be part of the public API :)

PiperOrigin-RevId: 274202995

This is useful for apps that want to access HDR metadata that MediaCodec puts
in its output format.

PiperOrigin-RevId: 274169985

This is a proof of concept for cleanup we should do for all of
our DataSource implementations as we move toward stabilizing
parts of the API.

- Move all XDataSourceFactory classes to be inner classes.
- Remove chained constructors for XDataSourceFactory classes. Keep
  required args going through constructors. Use setters for the
  rest.
- Not applicable in this case, but we probably want to deprecate
  all but the no-arg method for instantiating eac XDataSource
  instance (with the all-arg method kept but with the intention
  of making it package private).

PiperOrigin-RevId: 274162076

PiperOrigin-RevId: 274161845

Issue: #6523
PiperOrigin-RevId: 274160232

PiperOrigin-RevId: 274148614