SDK / exoplayer

Issue: #5246

PiperOrigin-RevId: 366041182

PiperOrigin-RevId: 365998615

The exo_controls_background view is supposed to fill its parent,
and so previously used match_parent to do this. However, if the
parent uses wrap_content for its own dimensions, the constraints
being specified become somewhat ambiguous. The parent is supposed
to be sizing itself to wrap its children, and one of the children
is supposed to be sizing itself to match the parent.

Intuitively for this case, you'd hope that the layout logic would
size the parent to wrap its other children, and that the
match_parent child would then fill the parent with its determined
size. That's not what happens, and instead the parent ends up
expanding to occupy all of the space available to it.

This commit sets the exo_controls_background view's dimensions
to be 0dp in the layout, to stop it from influencing the size of
the parent. It's then expanded to fill the parent in code.

Issue: #8726
#minor-release
PiperOrigin-RevId: 364868301

PiperOrigin-RevId: 360404403

Issue: #8705
PiperOrigin-RevId: 364821429

PiperOrigin-RevId: 364779790

Before this change, calling read after reaching the end of input in an Ogg file
would cause an IllegalStateException.

PiperOrigin-RevId: 364758873

#minor-release

PiperOrigin-RevId: 364561115

PiperOrigin-RevId: 364363882

#minor-release

PiperOrigin-RevId: 363915106

Issue: #8718
PiperOrigin-RevId: 363869093

#minor-release

PiperOrigin-RevId: 363859522

This change fixes playback of playlists where segments have the
extension and Content-Type of JPEG pictures (although in reality)
they are transport streams. File inferrence before this change will
cause an exception when assuming the inferred file type is one of
the allowed HLS containers.

#minor-release
Issue: #8733
PiperOrigin-RevId: 363641277

This brings in a fix for `NullPointerExceptions` within `WebView` callbacks in
the IMA SDK.

Issue: #8447
PiperOrigin-RevId: 363627446

#minor-release

PiperOrigin-RevId: 363141851

This makes HLS playback less liable to become stuck if discontinuity
tags are inserted at different times across media playlists.

Issue: #8700
Issue: #8372
PiperOrigin-RevId: 362903428

According to the spec (section 8.4.2), high numeric values represent low
priorities, so we need to flip this sort.

Issue: #8704
#minor-release
PiperOrigin-RevId: 362558370

`ImaAdsLoader` clears its `AdPlaybackState` when it's released but this could
cause `AdsMediaSource` to look up information in the ad playback state that is
no longer in bounds.

Issue: #8693

PiperOrigin-RevId: 362556286

PiperOrigin-RevId: 362079362

If none of the extractors successfully sniff the content then we will fall back
to inferred file types in the following order:
- Webvtt if the media comes from a SUBTITLE EXT-X-MEDIA.
- The type of media declared in the HTTP "Content-Type" header.
- The type of the media according to the file extension.
- Transport stream.

Issue: #8700
PiperOrigin-RevId: 362519769

PiperOrigin-RevId: 362298115

In a period transition we pass the start time of the next period, for
the final period we pass the duration of the period or timeline, if
known.

This means sideloaded subtitles now respect the end point of
ClippingMediaSource and ensures that content subtitles aren't
incorrectly displayed over mid-roll ads.

When transitioning back into the subtitled content the subtitles still
appear slightly before the video transitions, meaning the first subtitle
of the content is shown with the last few frames of the ad. Resolving
this in a way that doesn't break anything else requires a deeper
investigation.

Issue: #5317
Issue: #8456
#minor-release
PiperOrigin-RevId: 361797118

PiperOrigin-RevId: 361767801

MaskingMediaSource needs to resolve the prepare position set for a MaskingPeriod
while the source was still unprepared to the first actual prepare position.

It currently assumes that the period-window offset and the default position is
zero. This assumption is correct when a PlaceholderTimeline is used, but it
may not be true if the real timeline is already known (e.g. when re-preparing
a live stream after a playback error).

Fix this by using the known timeline at the time of the preparation.
Also:
 - Update a test that should have caught this to use lazy re-preparation.
 - Change the demo app code to use the recommended way to restart playback
   after a BehindLiveWindowException.

Issue: #8675
PiperOrigin-RevId: 361604191

PiperOrigin-RevId: 361106701

- Avoid having two onPositionDiscontinuity events (seek and transition)
  sent after a seek to another media item.
- Avoid triggering an onPositionDiscontinuity event after a timeline
  change.

#minor-release

PiperOrigin-RevId: 361092914

PiperOrigin-RevId: 361029604

Issue: #8664
#minor-release
PiperOrigin-RevId: 360877086

PiperOrigin-RevId: 360433358

PiperOrigin-RevId: 360398175

#minor-release

PiperOrigin-RevId: 360384540

Issue: #8646
PiperOrigin-RevId: 360184586

Issue: #5246
PiperOrigin-RevId: 360132205

PiperOrigin-RevId: 359724874

Suggested in a comment on PR Issue: #8615

PiperOrigin-RevId: 359522217

targetLiveOffsetInMedia_unknownWindowStartTime_doesNotAdjustLiveOffset
is flaky on the release branch. It's not flaky on the dev-v2 branch
due to recent changes to FakeClock's behaviour which aren't yet present
on release-v2.

r2.13.2

PiperOrigin-RevId: 359486817

Latest LTS version is better than latest stable version because it will
be supported for longer.

#minor-release
Issue:#8581
PiperOrigin-RevId: 359467482

PiperOrigin-RevId: 359244236