This is the first CL for the offline qoe reporting
feature. Refer to the design doc for full information.
Design doc: go/exoplayer-offline-qoe
PiperOrigin-RevId: 305459231
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
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
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
These were introduced in c7164a30a0
In each case I checked that the groups are not optional,
so if they match they must be non-null.
PiperOrigin-RevId: 305213293
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
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
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.
Without this, URL-encoding is assumed, which means ampersand-codes are
not carried through to the underlying web page correctly.
PiperOrigin-RevId: 304163733
HlsSampleStreamWrapper currently calls HlsMediaChunk.init, which calls back
to HlsSampleStraemWrapper.init. This re-entrancy seems a bit confusing.
PiperOrigin-RevId: 304139462
