SDK / exoplayer

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

Before:
https://docs.oracle.com/javase/7/docs/api/index.html?java/lang/String.html

After:
https://developer.android.com/reference/java/lang/String.html
PiperOrigin-RevId: 304137011

This means is-external=true is removed and target=_top is
set on the <a> tag.

Without this, javadoc links to framework docs with anchors are
currently broken when viewed in the "frame view" on
exoplayer.dev/doc/reference/

Before this change:
https://developer.android.com/reference/android/media/MediaDrm.html?is-external=true#getKeyRequest-byte:A-byte:A-java.lang.String-int-java.util.HashMap-

With this change:
https://developer.android.com/reference/android/media/MediaDrm.html#getKeyRequest-byte:A-byte:A-java.lang.String-int-java.util.HashMap-

PiperOrigin-RevId: 304136858

Partial rollback of https://github.com/google/ExoPlayer/commit/ca799716b8dab5ddf05d7deaf219ce4c645aab9f. We'll have to plumb
the id manually, like the rest of the LoadEventInfo
members.

PiperOrigin-RevId: 304067761

PiperOrigin-RevId: 303998690

Selection of a passthrough codec will rarely (if ever) need to be customized, so
remove this capability from MediaCodecInfo.

Applications can still customize whether passthrough is used by overriding
MediaCodecAudioRenderer.usePassthrough, which now also checks for a passthrough
codec.

#exo-offload

PiperOrigin-RevId: 303964682

PiperOrigin-RevId: 303937576

This is used to generate the initialization vector for encrypting the
cache contents.

Startblock:
   <unknown commit> is submitted
   and then
   3w have passed
PiperOrigin-RevId: 303932151

This was messed up by me in https://github.com/google/ExoPlayer/commit/a035c2e20a4ce25bd86774a870b5960bcfa6f0df

PiperOrigin-RevId: 303930392

PiperOrigin-RevId: 303829900

This avoids massive changes to method signatures to add throws.  Also, took suggestion to make it an `IllegalStateException`.

Move the catch outside of the finally that sets `nextLoadPosition` (this allows for possible recovery by reseting the `Extractor` and `TimestampAdjuster`).

Lastly, took the suggestion to make a minimum value for the tolerance (especially usefull for very short i-Frame only segments).

PiperOrigin-RevId: 303776645