SDK / exoplayer

PiperOrigin-RevId: 320909448

Previously, the automatically selected subtitle track
has not been marked (with check mark) in subtitle track list,
just like audio track.

But, in subtitle track option UI, there is no 'auto' option,
which is different from audio track selection menu.

This CL marks the auto selected subtitle track name in the cc list.

PiperOrigin-RevId: 320802575

Remove occurrences in comments and private fields.

ISSUE: #7565
PiperOrigin-RevId: 320606558

PiperOrigin-RevId: 320601157

The counter was increased by one for each batch
instead of each frame.

Additionally fix a null check.

PiperOrigin-RevId: 320592873

Sharing the Handler has led to it being accidentally used for purposes
beyond the original intention.

Instead for EPII -> EPI communication: Call methods directly on
ExoPlayerImpl that then post from the playback thread to the
application thread.

And for the MediaSourceList and Queue initialization, create a dedicated
Handler based on the same applicationLooper.

PiperOrigin-RevId: 320590527

PiperOrigin-RevId: 320581002

PiperOrigin-RevId: 320574671

Also flip DefaultDrmSessionManager#prepare()/release() into guard
clauses.

Suggestions from review comments on:
https://github.com/google/ExoPlayer/commit/316f8a88cdaeff2b1b5d219097b2739ef607b2c4

PiperOrigin-RevId: 320572462

AdDisplayContainer now takes the video ad player at construction time,
and obstructions are registered/unregistered via a new method. Also
'content complete' is now notified via ad callbacks rather than the
AdsLoader.

PiperOrigin-RevId: 320567666

PiperOrigin-RevId: 320565543

The new reader is named H263Reader as it handles H.263 streams, but
MPEG-4 Part 2 streams are also intended to be handled. The reader's
output format MIME type is video/mp4v as the H.263 streams can be
decoded by decoders supporting this MIME type.

The implementation is based on the framework implementation for
extracting MPEG-4 video in MPEG-TS
(https://cs.android.com/android/platform/superproject/+/master:frameworks/av/media/libstagefright/mpeg2ts/ESQueue.cpp;l=1825;drc=86e363c1fac27302ca4ae33e73296f7797672995)
and is similar to the existing H262Reader.

Issue: #1603
Issue: #5107
PiperOrigin-RevId: 320565337

This brings in a fix for the IMA SDK ignoring the media load timeout.

Issue: #7170
PiperOrigin-RevId: 320557386

Issue: #7592
PiperOrigin-RevId: 320556981

DecoderCounters are reset in onEnabled, but the way the local
counters in MediaCodecVideoRenderers were reset assumed the
DecoderCounters were reset in onStarted.

PiperOrigin-RevId: 320440991

Building on the Format that was provided on the input side of the
decoder creates a format that's a mixture of the formats on the
input and output sides of the decoder. This change instead builds
a PCM format from scratch.

PiperOrigin-RevId: 320405656

The counter was increased by one for each batch
instead of each frame.

PiperOrigin-RevId: 320396903

The renderers are currently constructing formats that consist of their
input format with added PCM encoding. Such formats are not self-consistent,
and this only works because DefaultAudioSink ignores the rest of the
format if the format has a PCM encoding. It would not work if the sink
implementation checked the MIME type, for example, which wouldn't be a
strange or incorrect thing for it to do.

The more correct approach is to construct a new format that properly
represents the PCM that will be provided to the sink.

This change also renames supportsOutput to supportsFormat, because
AudioSink itself has both an input and an output side, and this method
is actually evaluating support on the input side of the sink.

PiperOrigin-RevId: 320396089

PiperOrigin-RevId: 320351394

PiperOrigin-RevId: 320323388

The receiving code was updated in:
https://github.com/google/ExoPlayer/commit/7b82a3c8892a2b90fa1121dc6bfad7817ae03944
but this sending site was missed.

PiperOrigin-RevId: 320173033

PiperOrigin-RevId: 320172040

This is useful for subclasses to easily query the point up to which
they should only decode (but not render) content, rather than each
subclass having to have its own startPositionUs and update it in
onPositionReset.

PiperOrigin-RevId: 320163677

*** Original commit ***

Stop parsing unsupported WebVTT CSS properties

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: 320150427

PiperOrigin-RevId: 320149613

This constructor and the way of passing BandwdithMeter has long been
deprecated now and can be removed.

PiperOrigin-RevId: 320147888

This also removes unused deprecated methods.

PiperOrigin-RevId: 320141729

*** Original commit ***

Rollback of https://github.com/google/ExoPlayer/commit/0943886cbd7ee6c4e33ed731ddff0b23e5699abd

*** Original commit ***

Use last queue format instead of previous decision to select new track

We currently use the save...

***

PiperOrigin-RevId: 320015109

PiperOrigin-RevId: 320006659

*** Original commit ***

Use last queue format instead of previous decision to select new track

We currently use the saved selectionIndex to base our new track
selection decision on. This index might be stale if the previous
selection didn't result in a queue update (e.g. when loading live
streams where the new chunk isn't available yet).

Fix this by using the format of the last chunk to make the new decision.

Issue: #7582

***

PiperOrigin-RevId: 319991676

PiperOrigin-RevId: 319989989

Also move implementations of some VideoAdPlayer callback methods into
their own methods. This is a no-op change except for expanding the
scope of some defensive try blocks associated with those callbacks.

Also add static imports for Math.max and Assertions helpers methods.

PiperOrigin-RevId: 319958087

We currently use the saved selectionIndex to base our new track
selection decision on. This index might be stale if the previous
selection didn't result in a queue update (e.g. when loading live
streams where the new chunk isn't available yet).

Fix this by using the format of the last chunk to make the new decision.

Issue: #7582
PiperOrigin-RevId: 319957980

PiperOrigin-RevId: 319954774

The wait time parameter is an implementation detail where we can just
provide a default.

In addition, we should also force the evaluation when the last chunk
in the queue changed to ensure it is always evaluated before starting
to load a new chunk.

Issue: #7582
PiperOrigin-RevId: 319949251

Remove occurrences in comments and private fields.

ISSUE: #7565
PiperOrigin-RevId: 319828820

ExoMediaCrypto with the sole purpose of being unsupported. So all
renderers checking whether the type is supported will report
encrypted content as unsupported, unless the source producing
the format replaces it with a valid value.

PiperOrigin-RevId: 319824703

This is a partial revert of https://github.com/google/ExoPlayer/commit/0a2bacb7b7ca9a3e88962dbeaaa86f10f0e83b2a. I've added a comment
explaining why the code path is necessary after all, to avoid
future confusion.

PiperOrigin-RevId: 319822696

PiperOrigin-RevId: 319798613

Clearing the exception puts the SimpleDecoder into a silent failure
state - the decoder thread is dead (because decode() has returned
false) but it's still possible to queue buffers to the decoder (they
just never get decoded). This partially reverts
https://github.com/google/ExoPlayer/commit/4107375c9d21136090d0071b04a498024eec6a4c

Also always recreate the decoder when handling an error in TextRenderer

This ensures we can try and decode a later subtitle sample after
encountering a decode error. This behaviour is what nulling out the
exception in SimpleDecoder.flush() was trying to achieve. We need to
ensure we don't start passing data to the new decoder until we've
hit the next key frame, so we throw away any non-keyframe samples
inside TextRenderer#render().

Issue: #7590
PiperOrigin-RevId: 319785908