SDK / exoplayer

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

PiperOrigin-RevId: 319784140

PiperOrigin-RevId: 319764381

ISSUE: #7308
PiperOrigin-RevId: 319747742

Issue: #7584
PiperOrigin-RevId: 319744023

We currently try to keep track of the playback queue (MediaPeriodQueue)
by listening to onMediaPeriodCreated/onMediaPeriodReleased events.
This approach has some problems:
 1. It's easily broken by custom MediaSources that don't report these
    events correctly.
 2. We need to make some assumptions about what the order of these
    events actually means. For example it is currently important that
    the playing period gets released last in MediaPeriodQueue.clear()
 3. We don't see batched events (like MediaPeriodQueue.clear()), so that
    it is impossible to keep the "last reading period" for example. This
    information is needed to correctly associate renderer errors to
    periods after the queue has been cleared.

All of these problems can be solved by directly tracking the queue.

This also makes the onMediaPeriodCreated/Released/ReadingStarted events
obsolete and they can be removed in a future change.

PiperOrigin-RevId: 319739993

ISSUE: #7565
PiperOrigin-RevId: 319734842

ISSUE: #7308
PiperOrigin-RevId: 319541273

ISSUE: #7565
PiperOrigin-RevId: 319536055

PiperOrigin-RevId: 319520755

It applies only to regions:
https://www.w3.org/TR/2018/REC-ttml2-20181108/#style-attribute-writingMode

PiperOrigin-RevId: 319515547

The current code only works if the tts:ruby attributes are defined
directly on the in-line elements. This changes that so we also consider
tts:ruby attributes on `style` nodes referenced by ID.
PiperOrigin-RevId: 319515177

We don't need the renderer immediately after stopping, so the
renderer should not throw a checked exception until it's used again.
This is inline with the not throwing from disable().

Also, none of the known implementation throw an exception at the moment
and all reasonable base classes omit the throws clause already.

PiperOrigin-RevId: 319503643

They are all for Context.getSystemService that is allowed to return
null. In most cases where we need to service, we make an assertion that
it is available.

PiperOrigin-RevId: 319503557

PiperOrigin-RevId: 319497156

Because the stbl atom is mandatory, there is no reason for having a
special C.TIME_UNSET value instead of 0.

PiperOrigin-RevId: 319496999

And also replaced "Click" with "Tap" for CC button descriptions.

PiperOrigin-RevId: 319455553

PiperOrigin-RevId: 319420451

The test was incorrectly assuming that with LooperMode.PAUSE,
HandlerThread instances needed explicit calls to execute
tasks. This commit fixes the test flakiness by manually pausing the
HandlerThead when needed.

PiperOrigin-RevId: 319411552

PiperOrigin-RevId: 319399717

The standard, least surprising name, for a builder's method
that builds the object is `build`.

PiperOrigin-RevId: 319379622

Without checking if getFramesPerEncodedSample fails,
the frame count becomes negative which leads to
hard to debug errors.

PiperOrigin-RevId: 319247618

PiperOrigin-RevId: 319230328

Passthrough mode can use a codec or not, but
the code only mentioned "passthrough" in most cases,
making the specific mode confusing.

For example both `MediaCodecRenderer` and
it's derived class `MediaCodecAudioRenderer`
had a private `passthroughEnabled` field,
but they were used for the opposite modes!

This change renames all relevant variables/functions
to explicit `CodecPassthrough` or `Bypass`.

PiperOrigin-RevId: 319225235

PiperOrigin-RevId: 319223173

PiperOrigin-RevId: 319222833

Even without a drmInitData, a format can still has
a DRM.

PiperOrigin-RevId: 319217188

PiperOrigin-RevId: 319205008

The system services may return a null value if the service is
not available. Guard against this by falling back to default values.

PiperOrigin-RevId: 319187882

Issue: #7011
Issue: #6725
Issue: #7066

This also mitigates (but doesn't fix) Issue: #4133 because it
prevents a second key load after a short clear section.

PiperOrigin-RevId: 319184325

PiperOrigin-RevId: 319183621

PiperOrigin-RevId: 319183486

- Removed unnecessary private method
- Revised document for animation_enabled attribute
- Added setAnimationEnabled/isAnimationEnabled in StyledPlayerControlView

PiperOrigin-RevId: 319054648

Including ExoPlayer via relative paths currently breaks the import
logic of the common library settings file because it's referenced
from different directories. Fix this by resolving the setting path
to its canonical name.

Issue: #7554
PiperOrigin-RevId: 319043560

See https://developer.android.com/reference/android/media/MediaCodec.CryptoInfo#numBytesOfClearData. Both values are allowed to be null.

PiperOrigin-RevId: 319038124

SampleStreams should always provide samples starting from a keyframe.
We do not have equivalent logic in any of our extension decoder renderers.

PiperOrigin-RevId: 319012365

PiperOrigin-RevId: 319007693

The list of MediaSourceHolder in ExoPlayerImpl is only maintained to be able to create a PlaylistTimeline for masking. By keeping only the id and a snapshot of the timeline of the MediaSourceHolder in ExoPlayerImpl, parallel access is prevented and we still have sufficient information to create the masking timeline.

PiperOrigin-RevId: 319003837

Moved ui2/ code and resources into ui/

PiperOrigin-RevId: 318984707

We can't restore the previous state of the remaining chunk, so we can't
support discarding from spliced-in chunks. Mark this explicitly instead
of attempting to discard from the previous chunk.

PiperOrigin-RevId: 318983628