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
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
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 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).
CharSequence is used by Notification builders and allows to set Spannable text.
It's the base interface of the String class, so apps wouldn't be break after
the update.
PiperOrigin-RevId: 303731890
- They are always listed with their canonical names
- Considering aliases means that blacklisting a decoder can end up
not actually blacklisting it, since it may still be accessible
via an alias. It also means that our decoder fallback logic can
end up falling back to a decoder that we've already tried!
PiperOrigin-RevId: 303348297
This is less confusing than having audio processing functionality (e.g., playback
speed adjustment) just "not work" for some pieces of media.
If this change is merged, I will update #6749 to also track making DefaultAudioSink
intelligently enable/disable float output depending on how the audio processors are
configured.
Issue: #7134
PiperOrigin-RevId: 302871568
It's incorrect to use an AudioFormat returned from AudioProcessor.configure
unless the AudioProcessor is active.
Issue: #7134
PiperOrigin-RevId: 302674132
This is a no-op for DefaultAudioSink for now, because DefaultAudioSink
currently disables processing anyway if the input uses ENCODING_PCM_FLOAT.
Issue: #7134
PiperOrigin-RevId: 302670534
