SDK / exoplayer

ISSUE: #7114
PiperOrigin-RevId: 311115835

PiperOrigin-RevId: 311106612

Put static methods at the end.

Also add a couple of missing parameter name comments.

PiperOrigin-RevId: 311077684

Log content progress events, as these are helpful to debug triggering of events
based on the content progress.

Don't log AD_PROGRESS events as they occur several times per second while ads
are playing, and the verbosity makes logs difficult to read.

PiperOrigin-RevId: 311077302

It's very unlikely any onQueueInputBuffer implementations are looking
at the subsample encryption data, but from a correctness perspective
we should be passing a buffer object that's self-consistent.

PiperOrigin-RevId: 311011246

PiperOrigin-RevId: 311002702

PiperOrigin-RevId: 310997932

FFmpeg requires input buffers to be sized larger than the size
of the data they contain. This is to allow optimized decoder
implementations that read data in fixed size chunks, without
the risk of such decoders reading beyond the end of the buffer.

Issue: #2159
PiperOrigin-RevId: 310946866

PiperOrigin-RevId: 310940572

It makes it harder to work with a different branch. Also make
the FFmpeg instructions consistent with those of the other
extensions (e.g., by removing the "jni" part of the path from
the FFMPEG_EXT_PATH variable.

PiperOrigin-RevId: 310937751

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