SDK / exoplayer

The media specifies a URL that uses http rather than https, which the
demo app doesn't permit by default. The URL here is the same except it
uses https instead.

#minor-release

PiperOrigin-RevId: 348445571

PiperOrigin-RevId: 348440799

This avoids a NullPointerException later when the format is used.

Fixes https://github.com/google/ExoPlayer/issues/8283.

PiperOrigin-RevId: 348017149

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