SDK / exoplayer

It's unreliable for at least one IMA ADPCM file I've found.
Calculating the blockIndex to seek to using exact properties
also seems more robust.

Note this doesn't change anything for the existing PCM test,
since averageBytesPerSecond is set correctly. It does make
a difference for an upcoming IMA ADPCM test though.

PiperOrigin-RevId: 287814947

PiperOrigin-RevId: 287810018

An experiment with this algorithm didn't show positive results. We can
therefore keep the simpler default algorithm.

Startblock:
  <unknown commit> is submitted
PiperOrigin-RevId: 287807538

PiperOrigin-RevId: 287669425

Issue: #6733
PiperOrigin-RevId: 286621715

Where media segments are specified using byte ranges, it makes
sense that a server might return 416 (which we don't consider
for blacklisting) if the segment is unavailable, rather than
the 404 (which we do consider for blacklisting) that we expect
when media segments are only specified using a URL.

Issue: #6775
PiperOrigin-RevId: 286620698

PiperOrigin-RevId: 286587978

PiperOrigin-RevId: 286586865

PiperOrigin-RevId: 286585978

PiperOrigin-RevId: 286583957

Inspired by the `vertical` cue setting in WebVTT:
https://www.w3.org/TR/webvtt1/#webvtt-vertical-text-cue-setting

PiperOrigin-RevId: 286583621

PiperOrigin-RevId: 286581465

Issue: #6774
PiperOrigin-RevId: 286576383

The Download constructor considers it invalid to have a failure
reason if the download isn't in the failed state. Unfortunately,
calling DefaultDownloadIndex.removeAllDownloads when there's a
failed download will change the state without clearing the reason.
If the downloads are then read back from the DefaultDownloadIndex
we end up violating the Download constructor assertion.

This change clears the failed reason for any existing rows in the
invalid state, and also fixes the root cause that allows invalid
rows to enter the table in the first place.

Issue: #6785
PiperOrigin-RevId: 286576242

Issue: #6774
PiperOrigin-RevId: 286575797

Merge of https://github.com/google/ExoPlayer/pull/6793

PiperOrigin-RevId: 286556008

PiperOrigin-RevId: 286551438

Without this @Nullable, potential subclasses can't  override the
method to return null if they don't want to use the renderer as a
media clock.

Issue:#6792
PiperOrigin-RevId: 286545736

PiperOrigin-RevId: 286381499

PiperOrigin-RevId: 286368964

PiperOrigin-RevId: 286225012

This seems to work with R8 but interact badly with ProGuard.

issue:#6771
PiperOrigin-RevId: 286215262

PiperOrigin-RevId: 286203692

PiperOrigin-RevId: 286201458

Clarify that the units used here are microseconds

PiperOrigin-RevId: 286200583

This class is only used to hold temporary data while we parse the
settings and text, so we don't need it outside the Parser class.

Also remove all state from WebvttCueParser - this increases
the number of allocations, but there are already many
and  subtitles generally aren't very frequent (compared to
e.g. video frames).

PiperOrigin-RevId: 286200002

PiperOrigin-RevId: 286197990

PiperOrigin-RevId: 286191078

PiperOrigin-RevId: 286185549

Fixes JavaDoc on MediaCodecAdapter and AsynchronousMediaCodecAdapter
and a field declaration on MediaCodecRenderer.

PiperOrigin-RevId: 286157106

PiperOrigin-RevId: 286156361

PiperOrigin-RevId: 286154938

R8 does constant folding, so we need to keep buildRawResourceUri
to ensure that resources passed to it are kept.

PiperOrigin-RevId: 286153875

Add support for MP3 as an encoding format for passthrough.

This change does not change the observable
behavior of Exoplayer.

Also name the magics.

#exo-offload

PiperOrigin-RevId: 286146539

*** Original commit ***

Move getting-stuck-prevention into DefaultLoadControl.

We recently added code that prevents getting stuck if the buffer is low and
the LoadControl refuses to continue loading (https://github.com/google/ExoPlayer/commit/b84bde025258e7307c52eaf6bbe58157d788aa06).

Move this logic into DefaultLoadControl to keep the workaround, and also apply the
maximum buffer size check in bytes if enabled. ExoPlayerImplInternal will now
throw if a LoadControl lets playback get stuck. This includes the case where
DefaultLoadControl reaches its maximum buffer size and not even a mim...

***

PiperOrigin-RevId: 286071115

Design doc: https://docs.google.com/document/d/11h0S91KI5TB3NNZUtsCzg0S7r6nyTnF_tDZZAtmY93g/edit

Issue: #6161, #5155
PiperOrigin-RevId: 286020313

Add experimental method on DefaultRenderersFactory to set the
MediaCodecOperationMode on MediaCodecRenderer instances.

PiperOrigin-RevId: 286004667

These annotations are compile-only - so we don't mind they're not
accessible at runtime.

PiperOrigin-RevId: 285993063

Issue: #6773
PiperOrigin-RevId: 285990377

We recently added code that prevents getting stuck if the buffer is low and
the LoadControl refuses to continue loading (https://github.com/google/ExoPlayer/commit/b84bde025258e7307c52eaf6bbe58157d788aa06).

Move this logic into DefaultLoadControl to keep the workaround, and also apply the
maximum buffer size check in bytes if enabled. ExoPlayerImplInternal will now
throw if a LoadControl lets playback get stuck. This includes the case where
DefaultLoadControl reaches its maximum buffer size and not even a mimimal buffer
duration.

PiperOrigin-RevId: 285979989