SDK / exoplayer

Issue: #8323
PiperOrigin-RevId: 347827615

This regression was introduced in
https://github.com/google/ExoPlayer/commit/b1e9257de143e9f377895b63868ef47b4fc0eea9

Issue: #8349

PiperOrigin-RevId: 347802049

It's intended to log a warning in this case, rather than throw.

Issue: #8290

PiperOrigin-RevId: 347790527

PiperOrigin-RevId: 347789441

Issue: #8011
PiperOrigin-RevId: 347288689

Issue: #8272
PiperOrigin-RevId: 347010412

PiperOrigin-RevId: 346764371

PiperOrigin-RevId: 346346359

Issue:#8295
PiperOrigin-RevId: 346064966

Issue: #8308
#minor-release
PiperOrigin-RevId: 345707141

This was reported for SSA/ASS in PR #8265, but it seems to me the
SubRip part of the Matroska spec is similarly loose, so this change
handles null-terminated strings in both.

PiperOrigin-RevId: 345452667

PiperOrigin-RevId: 345428731

The `AudioProcessor` interface requires that no more input is queued after
queueing end of stream, but `DefaultAudioSink` did queue more input and the
implementation of `SonicAudioProcessor` actually relied on this to drain output
at the end of the stream.

Fix this behavior by getting `Sonic` output in `getOutput` and having
`DefaultAudioSink` only queue input to processors that are not draining.

Also add TODOs to clean up audio processor implementations where the code
handles interaction that doesn't conform to the interface.

PiperOrigin-RevId: 345406478

Asset generated using a temporary SSA file and:
```
$ mkvmerge -o sample_with_ssa_subtitles.mkv sample.mkv input.ssa
```

PiperOrigin-RevId: 345217628

PiperOrigin-RevId: 345202157

PiperOrigin-RevId: 345036042

Previously `MediaPeriodQueue` would return null if an ad media URI hadn't
loaded yet, but this meant that the player could be stuck in `STATE_READY` if
an `AdsLoader` unexpectedly didn't provide an ad URI. Fix this behavior by
masking ad media periods. `MaskingMediaPeriod` no longer requires a
`MediaSource` to instantiate it.

This also fixes a specific case where playback gets stuck when using the IMA
extension with an empty ad where the IMA SDK unexpectedly doesn't notify the ad
group fetch error.

Issue: #8205
PiperOrigin-RevId: 344984824

PiperOrigin-RevId: 334801561

r2.12.2

PiperOrigin-RevId: 344801462

- Retire YouTube streams. They're flaky (e.g., one of them has transformed into
  an audio only stream!). There is also a desire for us to stop relying on special
  non-expiring YouTube URLs.
- Reorganize the remaining streams.

PiperOrigin-RevId: 344421031

PiperOrigin-RevId: 344420436

PiperOrigin-RevId: 344408351

#exofixit

PiperOrigin-RevId: 344246408

Issue: #8239

PiperOrigin-RevId: 344211877

#exofixit
Issue: #5602
PiperOrigin-RevId: 344093622

The ref'd issue was marked as a doucmentation candidate, but I think
the confusion likely arises from the lack of "next" and "previous" in
the method names. Our other UI components also support enabling each
button individually, so this also brings notifications in line with
those.

Issue: #6491
#exofixit
PiperOrigin-RevId: 344058969

PiperOrigin-RevId: 344057097

#minor-release

PiperOrigin-RevId: 344051610

PiperOrigin-RevId: 343883034

PiperOrigin-RevId: 343882631

PiperOrigin-RevId: 343871061

Don't refer to the "system's default charset", just specify UTF-8
explicitly.

PiperOrigin-RevId: 343839878

RunnableFutureTask is not reusable. Trying to reuse it meant that a
failure in one doWork() call would cause subsequent download() calls
to (a) not block until the runnable has finished executing (does not
apply when using a direct executor), and (b) throw the same failure
as thrown from the first doWork() call.

This could cause #8078 if the initial failure occurred before the
content length was resolved. Retries are not blocked on their work
completing due to (a), and the download would be marked as failed due
to (b). The work itself could then resolve the content length, which
causes the stack trace in this issue.

Issue: #8078
PiperOrigin-RevId: 343498252

The demo app has two states for downloads, as per DownloadTracker.isDownloaded.
It's either "downloaded or downloading" (isDownloaded returns true, and the UI
shows a blue tick) or it's "not downloaded or failed (isDownloaded returns
false, and the UI does not show a blue tick).

toggleDownload is out of sync in that it treates "failed" as belonging to the
first state rather than the second. This means tapping on the grey tick in the
UI in this case appears to be a no-op (tapping it again will make something
happen).

This change aligns things by making toggleDownload re-download in the case a
previous download failed. In the future we could consider having three states,
so failed downloads could be disambiguated properly. Unclear whether it's a
good complexity/benefit trade-off for the demo app though!

#minor-release

PiperOrigin-RevId: 343464364

When a stream has duplicate timestamps we currently discard to
the last sample with the specified discardTo timestamp, but
it should be the first one to adhere to the method doc and the
intended usage.

#minor-release

PiperOrigin-RevId: 343458870

PiperOrigin-RevId: 343437513