SDK / exoplayer

r2.15.1

#minor-release

PiperOrigin-RevId: 397976212

PiperOrigin-RevId: 397758146

The previous implementation did the following (after skipping any ID3
headers at the start of the stream):
1. Skip forward byte-by-byte looking for a sync word (0xFFF)
2. Assume this indicates the start of an ADTS frame and read the size
  a) If frameSize <= 6 immediately return false
3. Skip forward by frameSize and expect to find another ADTS sync word
   (with no further scanning).
   b) If we find one, great! Loop from step 2.
   a) If we don't find one then assume the **last** sync word we found
      wasn't actually one, so loop from step 1 starting one extra byte
      into the stream. This means we're looking for a sync word we would
      have skipped over in step 3.

The asymmetry here comes from the different handling of frameSize <= 6
(immediately return false) and frameSize being 'wrong because it doesn't
lead to another sync word' (scan the file again from the beginning for
alternative sync words).

With this change both these cases are handled symmetrically (always scan
for alternative sync words). Step 2a) becomes the same as 3b): Loop back
to the beginning of the stream with an incremented offset and scan for
another sync word.

#minor-release

PiperOrigin-RevId: 397285756

Issue: #9437
#minor-release
PiperOrigin-RevId: 397273931

Issue: #9428

PiperOrigin-RevId: 397064086

This was originally reported on #9390. There was a bug that when HLS
loads failed, the player would endlessly retry and never fail with a
player error.

This change fixes a bug in HlsSampleStreamWrapper.onPlaylistError()
which would return true for a playlist whose load encountered an error
but could not be excluded, whereas the method should return false.

Issue: #9390

PiperOrigin-RevId: 397045802

Previously the released preacquired sessions would start their keepalive
timeout, and so no additional resources would be freed in time for the
manager to retry the session acquisition.

This change adds an additional purge of keepalive sessions *after* the
preacquired sessions are released, which fixes the problem.

PiperOrigin-RevId: 396613352

This is was reported in #9257 where the PlaybackStatsListener may try to
access an emtpy ArrayList.

Issue: #9257

#minor-release
#exofixit

PiperOrigin-RevId: 396329373

This is a candidate fix for #8906. As mentioned in that issue,
negative positions within windows might be (kind of) valid in
live streaming scenarios, where the window starts at some
non-zero position within the period. However, negative positions
within periods are definitely not valid. Neither are positions
that exceed the period duration.

There was already logic in ExoPlayerImplInternal to prevent a
resolved seek position from exceeding the period duration. This
fix adds the equivalent constraint for the start of the period.
It also moves the application of the constraints into Timeline.
This has the advantage that the constraints are applied as part
of state masking in ExoPlayerImpl.seekTo, removing any UI flicker
where the invalid seek position is temporarily visible.

Issue: #8906
PiperOrigin-RevId: 395917413

Issue: #9416

The dash "-" in the brackets must be escaped, or it acts like a range
operator.

PiperOrigin-RevId: 395909845

PiperOrigin-RevId: 395727438

Instead of selecting the base URL initially or when a load error occurs,
it is now selected when a chunk or initialization chunk is created. The
selected base URL is then assigned to
`RepresentationHolder.lastUsedBaseUrl` that is excluded in case of a
load error. For a next chunk another base URL will be selected by using
the `BaseUrlExclusionList`.

PiperOrigin-RevId: 395721221

Since playlist support was added, it's possible for the player to "have media"
and be in STATE_IDLE. The STATE_IDLE documentation therefore became incorrect.

Issue: #8946
#exofixit
#minor-release
PiperOrigin-RevId: 395653716

I think this has been broken since https://github.com/google/ExoPlayer/commit/617267bfcf20c500fb4a3cfdff7104e4d88261a7 (which was trying to fix
the same problem).

This change initializes `rootDir` to always be the current project (i.e. ExoPlayer)
directory. From the [Gradle docs](https://docs.gradle.org/current/userguide/working_with_files.html#sec:single_file_paths):
> What happens in the case of multi-project builds? The file() method
> will always turn relative paths into paths that are relative to the
> current project directory, which may be a child project.

We can also then remove exoplayerRoot completely and simplify the local
dependency instructions.

* #minor-release
* #exofixit
* Issue: #9403

PiperOrigin-RevId: 395478121

Some server will send partial URIs in the RTP-Info header, while the RTSP spec
requires absolute URLs.

Issue: #9346

PiperOrigin-RevId: 395452741

PiperOrigin-RevId: 395444714

Issue #9284

PiperOrigin-RevId: 395443015

Issue: #9370
PiperOrigin-RevId: 395429794

The C2 MP3 decoder produces an extra output buffer when draining after
end-of-stream is queued. This output buffer has a later timestamp than the last
queued input buffer so we need to calculate its timestamp to detect a stream
change in the correct position.

Before this CL we used the original input buffer timestamp as the largest
queued timestamp, which caused the stream change to be detected at the correct
position because the original input buffer timestamp was slightly larger than
the actual last output buffer timestamp. After this change we use exact
calculated timestamp as the largest queued timestamp. I manually verified
gapless continues to work on a device using the C2 MP3 decoder by comparing
output of the MP3 gapless and MP3 gapless stripped playlists in the demo app,
and that the last buffer timestamp now matches.

#exofixit

PiperOrigin-RevId: 395428928

PiperOrigin-RevId: 395395015

- Fix focus when pausing and resuming
- Prevent repeated readout of the playback position when paused

Issue #9111

PiperOrigin-RevId: 395301765

The current detection logic checks that the two byte terminator starts
at an even position in the ID3 data, where-as it should check that it
starts at an even position relative to the start of the string.

Issue: #9087
PiperOrigin-RevId: 395274934

#minor-release
#exofixit

PiperOrigin-RevId: 395233639

Issue: #9379
PiperOrigin-RevId: 395226701

Issue #9024

PiperOrigin-RevId: 395224661

This typically happens if there's a discontinuity in the stream.
It's better to say we don't know, than it is to return a negative
position.

Issue: #8346
#exofixit
#minor-release
PiperOrigin-RevId: 395224088

Issue: #9002
PiperOrigin-RevId: 395221648

Before, this decoder was avoided on API levels < 30.

#minor-release
Issue:#9349
PiperOrigin-RevId: 395209684

PiperOrigin-RevId: 395004645

PiperOrigin-RevId: 394415421

#minor-release
Issue:#9350
PiperOrigin-RevId: 394112689

Issue: #6784
PiperOrigin-RevId: 393374139

These should have been updated as part of
https://github.com/google/ExoPlayer/commit/1affbf9357c061149b3cb287972ea0157d1b6735

#minor-release

PiperOrigin-RevId: 392913561

Issue: #9294
PiperOrigin-RevId: 392844983

These are unneeded for the external project

#minor-release

PiperOrigin-RevId: 392835942

Issue: #9303
#minor-release
PiperOrigin-RevId: 392022613

PiperOrigin-RevId: 391965200

PiperOrigin-RevId: 391952144

StyledPlayerControlView was checking whether the player is an ExoPlayer
instance to set the track selector. This means that, if apps were
wrapping an ExoPlayer in a ForwardingPlayer (to replace a
ControlDispatcher for example), the track selector wasn't set anymore.

PiperOrigin-RevId: 391776305