SDK / exoplayer

Create a Builder that creates SimpleExoPlayer instances with fake
components, suitable for testing.

Basically extracts the Builder from ExoPlayerTestRunner to a standalone
class that can be re-used.

PiperOrigin-RevId: 305458419

Issue: #6410
PiperOrigin-RevId: 305436352

PiperOrigin-RevId: 305300409

PiperOrigin-RevId: 305276107

This CL is a renaming only. It's mostly about finding a decent naming for the internal Playlist class. The plan is to have a public Playlist class in the converged Player API, so we need to rename the internal one.

PiperOrigin-RevId: 305266196

PiperOrigin-RevId: 305258836

PiperOrigin-RevId: 305242260

PiperOrigin-RevId: 305235961

If we're in the ducked state and updateAudioFocus is called with a
new state for which focus is no longer required, we should restore
the player back to full volume.

Issue: #7182
PiperOrigin-RevId: 305232155

PiperOrigin-RevId: 305216138

These were introduced in https://github.com/google/ExoPlayer/commit/c7164a30a067e5ddf5f0c706d6861652d39fd967

In each case I checked that the groups are not optional,
so if they match they must be non-null.

PiperOrigin-RevId: 305213293

PiperOrigin-RevId: 305140826

PiperOrigin-RevId: 305137114

This avoids cases where audio focus is never successfully acquired
because another app is holding on to transient audio focus indefinitely.

Issue: #7182
PiperOrigin-RevId: 305108528

When ClippingMediaPeriod first tried to read a buffer, if its end
position was before the end of the stream and it was buffered to its end
position, it would sometimes erroneously signal end-of-stream for
protected content because the sample queue might be waiting for DRM keys
at this point.

Work around the issue temporarily by signaling this specific case back
to ClippingMediaPeriod via the DecoderInputBuffer.

There will likely be a cleaner fix as a result of adding support for
dynamic clip end points in the future, at which point this can be
reverted.

issue:#7188
PiperOrigin-RevId: 305081757

PiperOrigin-RevId: 305037428

PiperOrigin-RevId: 305006564

PiperOrigin-RevId: 304986313

PiperOrigin-RevId: 304795753

In particular, replace @SuppressWarnings("initialization") with
@SuppressWarnings("nullness"); see
https://github.com/typetools/checker-framework/issues/3212.

More information: go/checker-lsc

Tested:
    TAP train for global presubmit queue
    http://test/OCL:304697666:BASE:304680497:1585968008044:f0c4fd6c
PiperOrigin-RevId: 304751415

This should have been done before, I just missed it.

PiperOrigin-RevId: 304612519

This is supported (despite what my now-deleted comment says), see the
example here:
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/rt

PiperOrigin-RevId: 304612099

PiperOrigin-RevId: 304420177

PiperOrigin-RevId: 304386857

PiperOrigin-RevId: 304356504

The attempt in <unknown commit> was hacky and incomplete.

PiperOrigin-RevId: 304356038

PiperOrigin-RevId: 304355717

It's interesting WebVTT explicitly handles line & position differently
in horizontal-rl/lr and vertical-lr/rl contexts. position is always
measured from the left of the viewport, even for rtl text, but line in
vertical-rl is measured from the right of the viewport.

We don't have to make Cue match WebVTT (I can go change the WebVTT
decoding instead) but it seems a reasonable 'default' to follow.

PiperOrigin-RevId: 304353900

With these additional properties, we can declare the behaviour for clear tracks and clear content on a media item level.

PiperOrigin-RevId: 304351716

Fix mistake from the backport merge, should get TEXT track type for subtitles.  Also update testcase to match pattern in `dev-v2` branch.

Use the `Util.getCodecsOfType()` method rather than hard coded codec strings

ExoPlayer needs a codec to decide among WEBVTT and TTML decoder mimeType.
Apple describes IMSC1 in MP4 in
[RFC-8216 Section 3.6](https://tools.ietf.org/html/draft-pantos-hls-rfc8216bis-04#section-3.6).

The DASH manifest specifies the SMPTE-TT captions in the codecs in the manifest
(from W3C [TTML Profiles for Internet Media Subtitles and Captions 1.1](https://www.w3.org/TR/ttml-imsc1.1/#general-0).
DASH just doesn't require the rendition linking, but HLS does.

Apple implies the CODECS attribute of the variant needs to be do this.  That is
with SHOULD and MAY language to imply the codec to use for it in the
[Authoring Guidelines](https://developer.apple.com/documentation/http_live_streaming/hls_authoring_specification_for_apple_devices)

This change defaults to WebVTT if no codec is specifed (same as current behavior) otherwise it picks it from the variants
referencing the media.

PiperOrigin-RevId: 304196424

SimpleExoPlayer instances don't have to be created from the application
thread.

PiperOrigin-RevId: 304190901

PiperOrigin-RevId: 304186326

PiperOrigin-RevId: 304184650

PiperOrigin-RevId: 304164078

Without this, URL-encoding is assumed, which means ampersand-codes are
not carried through to the underlying web page correctly.

PiperOrigin-RevId: 304163733

These are handled by converting to ampersand codes - add a test to show
that's explicit & deliberate.

PiperOrigin-RevId: 304163712

HlsSampleStreamWrapper currently calls HlsMediaChunk.init, which calls back
to HlsSampleStraemWrapper.init. This re-entrancy seems a bit confusing.

PiperOrigin-RevId: 304139462