SDK / exoplayer

Some player setup steps that are likely to be only done once
should be moved into the Builder so that player setup can use
a consistent style (builder vs setters).

This also prevents some threading warning issues when the player
is built on a background thread (e.g. for dependency injection
frameworks) and setters can't be used due to threading restrictions.

PiperOrigin-RevId: 311487224

This is the last piece to bring feature parity between
WebViewSubtitleOutput and CanvasSubtitleOutput.

PiperOrigin-RevId: 311325749

Issue:#7309
PiperOrigin-RevId: 311324242

It displays images too, and in fact it's used exclusively to display
images in SubtitleWebView. It also doesn't use a TextView - so all round
a slightly confusing name.

Also rename SubtitleWebView to WebViewSubtitleOutput to match the same
pattern.

PiperOrigin-RevId: 311312758

- Remove proguard-rules.txt symlink
- Guard against classes annotated with @ClosedSource but not excluded

PiperOrigin-RevId: 311312671

This is useful for merging the FFmpeg video support pull request,
since it allows a Decoder base class implementation to catch
DecoderException rather than forcing it to catch Exception (i.e.,
everything). Note that unfortunately, Java doesn't allow catching
of a generic type (i.e., you cannot "catch (E e)") due to type
erasure.

PiperOrigin-RevId: 311300719

PiperOrigin-RevId: 311298802

PiperOrigin-RevId: 311295749

The only reason to require a context for creating an instance of
DefaultMediaSourceFactory is creating a user agent. DownloadHelper
has a bunch of static methods that need to instantiate a
DefaultMediaSourceFactory without a Context. By adding a setter for
the user agent we can remove that restriction and use a default user
agent.

PiperOrigin-RevId: 311291603

We aim for all SinglePeriodTimelines to set window.mediaItem and hence want to eliminate all constructors not passing a media item. The constructor removed in this CL is the easiest one to remove and fix in google3. It is still a breaking change for external ExoPlayer user who provide a custom media source with this timeline.

PiperOrigin-RevId: 311291493

PiperOrigin-RevId: 311290214

PiperOrigin-RevId: 311150195

Two tests had the same code when the were
supposed to test different state.

PiperOrigin-RevId: 311149216

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