SDK / exoplayer

When I moved ParsableByteArray#data behind a getter I replaced some
assignments with calls to reset(byte[]):
https://github.com/google/ExoPlayer/commit/ce2e6e2fd625db787b1f400614adcd7458144bbd

reset(byte[]) deliberately sets `limit` to `data.length`, in order to
handle cases that were reassigning `data` but not updating `limit`.
However OggPacket was already using `limit` to track where to write
'new' data into the array, so changing `limit` to `data.length` caused
us to try and write new data beyond the end of the array.

I looked at other uses of reset(byte[]) in https://github.com/google/ExoPlayer/commit/ce2e6e2fd625db787b1f400614adcd7458144bbd
and condluded the only other usage in MatroskaExtractor is legit and
shouldn't be updated like this (because MatroskaExtractor previously
*wasn't* correctly updating/maintaining `limit`).

Issue: #7992
PiperOrigin-RevId: 334601586

PiperOrigin-RevId: 334580007

PiperOrigin-RevId: 334567234

PiperOrigin-RevId: 334562209

PiperOrigin-RevId: 334549894

Non-realtime AudioTrack playback speed was not taken into account when
extrapolating the old mode's position, causing the position not to
advance smoothly.

This should be a no-op when not using AudioTrack playback params for
speed adjustment.

Issue: #7982
PiperOrigin-RevId: 334151163

Every other subtitleButton has an if not null check, but does not force non null.

Issue: #7962
PiperOrigin-RevId: 334124323

On receiving a fetch error for an ad that would otherwise play based on an
initial/seek position, the pending content position wasn't cleared which meant
that position reporting was broken after a fetch error. Fix this by always
clearing the pending position (if there was a pending position that will have
triggered the fetch error).

Also deduplicate the code for handling empty ad groups (fetch errors)
and ad group load errors.

Issue: #7956
PiperOrigin-RevId: 334113131

PiperOrigin-RevId: 333751261

Issue: #7949
PiperOrigin-RevId: 333733615

ISSUE: #7977
PiperOrigin-RevId: 333726625

PiperOrigin-RevId: 333720336

PiperOrigin-RevId: 333714978

PiperOrigin-RevId: 333712782

Set the FLAG_MIGHT_NOT_USE_FULL_NETWORK_SPEED on live load DataSpecs
for segments that are not yet fully available.

PiperOrigin-RevId: 333712684

Issue: #7967
PiperOrigin-RevId: 333709003

Remove the SynchronousMediaCodecBufferEnqueuer interface
since we only keep the AsynchronousMediaCodecBufferEnqueuer
implementation.

PiperOrigin-RevId: 333701115

Retry AudioTrack init and write for 100ms before
giving up and aborting playback.

This was tested by throwing every 2 init/write and
making sure playback did not stopped.

#exo-offload

PiperOrigin-RevId: 333536841

#exo-offload

PiperOrigin-RevId: 333532900

Intended for statistics now that all errors
are not surfaced to the app.

PiperOrigin-RevId: 333519898

#exo-offload

PiperOrigin-RevId: 333513385

#exo-offload

PiperOrigin-RevId: 333512383

Do that by adding a recoverable state to
the ExoPlaybackException marking when
it is needed to recreate the renderers.

PiperOrigin-RevId: 333507849

Fix bug to place the negative sign in the beginning
of the returned String.

PiperOrigin-RevId: 333504868

Remove MediaCodecOperationMode and replace it with a boolean
flag to enable/disable asynchronous queueing.

PiperOrigin-RevId: 333504817

Those aliases were introduced when the class
was also called AudioTrack.

PiperOrigin-RevId: 333499360

#exo-offload

PiperOrigin-RevId: 333497538

Apps can still opt out for now, but this option will be removed in
the future.

Issue: #4463
PiperOrigin-RevId: 333489424

PiperOrigin-RevId: 333485323

PiperOrigin-RevId: 333480727

This issue has been observed on a test app stress
testing setEndOfStream.

The issue has not been observed on ExoPlayer,
probably due to timing differences, but it is fixed
preventively.

#exo-offload

PiperOrigin-RevId: 333472136

This seems to be an exact copy of sample.adts. Update the test to use
the same sample but just output to a different dump file.

PiperOrigin-RevId: 333469714

These are from https://medium.com/google-exoplayer/improved-japanese-subtitle-support-7598fee12cf4

PiperOrigin-RevId: 333296789

PiperOrigin-RevId: 333272292

This allows the player to load the unfinished segment of a low-latency
DASH stream.

PiperOrigin-RevId: 333077153

The shrinking didn't mention that users of the existing
ProgressiveMediaSource need to pass in ExtractorsFactory.EMPTY to the
SimpleExoPlayer.Builder as well.

Also updated the release notes to mention the changed shrinking
guidance.

Issue: #7937
PiperOrigin-RevId: 333060452

PiperOrigin-RevId: 333051018

We have a workaround for uneven sample stream durarions in playlists that
assumes a renderer allows playback if it's reading ahead or waiting for
the next stream.

https://github.com/google/ExoPlayer/commit/652c2f9c188bf9d9d6e323ff5333e5026454a082 changed this logic to no longer require to
wait until the next stream is prepared due to a change in how we advance
media periods in the queue. However, the code falsely still requires the
next stream to exist (even if it's not prepared). This can cause a stuck
buffering state when the difference in the duration of the streams is more
than what we buffer ahead because we never create the next stream in such
a case.

Note: DefaultMediaClock.shouldUseStandaloneClock has roughly the same logic
and also doesn't require the next stream to be present.

Also fix a test that seemed to rely on this stuck buffering case to test
stuck buffering detection. Changed the test to not read the end of stream
to ensure it runs into the desired stuck buffering case.

Issue:#7943
PiperOrigin-RevId: 333050285

This allows to use the same logic from multiple places without duplicating
it, encapsulates in its logical place, and allows to change the available
segments based on the new availabilityTimeOffset value.

The overall effect of this change is a no-op.

PiperOrigin-RevId: 333044186

PiperOrigin-RevId: 333036751