SDK / exoplayer

The current state is inconsistent with SpannedToHtmlConverter, it seems
they might as well agree on quoting strategy.

PiperOrigin-RevId: 310926683

Issue:#6705
PiperOrigin-RevId: 310907118

PiperOrigin-RevId: 310901647

We currently use the playback position in the current window, not the
position in the window the event belongs to. This creates confusing
outputs, e.g, window=1, mediaPos=100, even if the position refers to
window 0.

issue:#7332
PiperOrigin-RevId: 310896908

The tts:textAlign property only applies to <p> elements, which
correspond 1:1 with ExoPlayer Cue objects, so we can use
Cue.textAlignment to store this info instead of encoding it in
the span-styled text.

This will mean that TTML subtitles used with
SubtitleView#setApplyEmbeddedStyles(false) will start respecting
the tts:textAlign properties from the source data (currently this
information is stripped when we remove all span styling). I think this
is working-as-intended, we respect alignment of other subtitle types
(e.g. WebVTT) when applyEmbeddedStyles=false. We also respect all other
'positioning' related properties in this case e.g. Cue.position and
Cue.line.

PiperOrigin-RevId: 310895499

PiperOrigin-RevId: 310889726

*** Original commit ***

Rollback of https://github.com/google/ExoPlayer/commit/70273a0361cd3091858c0c9122c58ce9cb8ec62a

*** Original commit ***

Assert incoming buffers are little endian in the DefaultAudioSink.

***

***

PiperOrigin-RevId: 310889382

When operating the MediaCodec in asynchronous mode, we are seeing
NPEs raised from the DefaultAudioSink because output buffers are pushed
to the DefaultAudioSink with the DefaultAudioSink not configured yet.
This is possible to happen if an output buffer is passed with
MediaCodecAudioRenderer.processOutputBuffer() before an output format
change.

One possible code path to trigger this is when an output format change
is pending and we flush MediaCodec (e.g. for a seek): the callback is
waiting in the looper's queue but we ignore all currently queued
callbacks after a flush().

This commit checks for a pending output format change during a flush():
if one exists, and the next MediaCodec output callback right after the
flush() is an output buffer (and not a new output format), then the
pending output format is propagated first.

The only adapter that needs to change is the
AsynchronousMediaCodecAdapter which previsouly deleted all pending
callbacks immediately on flush(). The AsynchronousMediaCodecAdapter now
needs to also handle every enqueued callback in order to identify is
there's a pending output format change.

Testing: added unit tests for the new code. I have verified that if we
pass an output buffer to the audio renderer before the output format, it
will result on the specific NPE, but I cannot reproduce the base
scenario (an output format change is pending when flushing) on a real
device because we can't know if an output format is indeed pending.
PiperOrigin-RevId: 310885283

PiperOrigin-RevId: 310883076

*** Original commit ***

Assert incoming buffers are little endian in the DefaultAudioSink.

***

PiperOrigin-RevId: 310377513

We currently propagate only ColorInfo, but propagating the whole Format
is generally useful (e.g., to get the frame-rate on the output side of
the decoder).

PiperOrigin-RevId: 310359650

The spec lists an exhaustive list of CSS properties that should be
recognised, all others must be ignored:
https://www.w3.org/TR/webvtt1/#the-cue-pseudo-element

PiperOrigin-RevId: 310353888

This allows properties to propagate when switching view types
(e.g. bottomPaddingFraction).

It also allows the style-stripping code to be pushed up to SubtitleView
and therefore shared.

PiperOrigin-RevId: 310353534

PiperOrigin-RevId: 310332895

PiperOrigin-RevId: 310332708

Fixes AsynchronousMediaCodecBufferEnqueuerTest broken tests by
enqueueing input buffers that have previously been dequeued from the
MediaCodec.

The test assumes that the shadow MediaCodec implementation can dequeue
at least 10 input buffers before queueing them back. Although fragile,
it seems to work with the current robolectric shadow MediaCodec. This is
at the moment preferred compared to making the test more complicated.

PiperOrigin-RevId: 310325096

Change CastPlayer#getTrackSelector to return null
instead of throwing exception.

PiperOrigin-RevId: 310319964

PiperOrigin-RevId: 310242733

PiperOrigin-RevId: 310199693

Some part of the audio pipeline in the DefaultAudioSink
(PCM processors) are expecting little endian buffers.

As a result, in order to behave like MediaCodec,
make sure the passthrough MediaCodec-bypass pipeline
also processes little endian output buffers.

PiperOrigin-RevId: 310172464

This aligns mkv with mp4, flv and ts extractors.

This issue was found when AAC in an MKV container was not offloaded
as format.codecs was null.

PiperOrigin-RevId: 310170759

#exo-offload

PiperOrigin-RevId: 310150780

Part of issue:#6765

PiperOrigin-RevId: 310143494

Previously the input format values were used,
but it could be incorrect if two format change were
occurring in quick successions.

PiperOrigin-RevId: 310142675

PiperOrigin-RevId: 310142362

PiperOrigin-RevId: 310115628

PiperOrigin-RevId: 310114401

These methods operate on a thread-safe collection and are thus
inherently thread-safe. This simplifies some player setup configurations
where initial listeners are added on a background thread (e.g. when
using a dependency injection framework).

PiperOrigin-RevId: 310113181

Users of addTextOutput should instead query the current cues if they
need them. This is more consistent with how other listeners are handled.

PiperOrigin-RevId: 310112241

We currently have DecoderVideoRenderer and VideoDecoderRenderer, which
is very confusing! This one is package private, so we can rename it to
remove some of the confusion.

Also fix some nullness issues.

PiperOrigin-RevId: 309964088

PiperOrigin-RevId: 309963490

PiperOrigin-RevId: 309949800

In passthrough MediaCodec is not used except if
the format has a DRM.

Nevertheless the code was still requiring that a
passthrough decoder be present even if it was not going to be
used (aka no drm).

PiperOrigin-RevId: 309947271

A silly mistake of confusing a fractional float with a percentage.

PiperOrigin-RevId: 309946004

PiperOrigin-RevId: 309944716

- Fix DecoderAudioRenderer to re-init codec if the DRM session changes.
- Add canKeepCodec to DecoderVideoRenderer. Previously it was assumed
  that the decoder could be re-used, but this will not be true in all
  cases for FfmpegVideoRenderer.

Issue: #7079
PiperOrigin-RevId: 309935278

If the condition isn't fulfilled, they currently block until the
test runner times out the test. Our usual approach is to timeout
in the test itself so that the error message is clearly showing the
blocked condition.

Also clean-up some documentation.

PiperOrigin-RevId: 309930198

PiperOrigin-RevId: 309925306

Now that MediaCodec is not use in passthrough, no
MediaCodec should be created in this mode.

Additionally, do not instantiate a MediaCodec in passthrough

#exo-offload

PiperOrigin-RevId: 309916131

issue:#6429
PiperOrigin-RevId: 309906760