SDK / exoplayer

r2.10.3

PiperOrigin-RevId: 257630168

PiperOrigin-RevId: 257185017

PiperOrigin-RevId: 257184313

PiperOrigin-RevId: 257161518

Sending MESSAGE_PREPARE_SOURCE should happen last in the constructor.
It was previously happening before initialization finished (and in
particular before pendingMediaPeriods was instantiated).

Issue: #6146
PiperOrigin-RevId: 257158275

Currently, we sometimes apply new playback parameters directly and sometimes
through the list of playbackParameterCheckpoints. Only when using the checkpoints,
we also reset the offset and corresponding position for speedup position
calculation. However, these offsets need to be changed in all cases to prevent
calculation errors during speedup calculation[1].

This change channels all playback parameters changes through the checkpoints to
ensure the offsets get updated accordingly. This fixes an issue introduced in
https://github.com/google/ExoPlayer/commit/31911ca54a13b0003d6cf902b95c2ed445afa930.

[1] - The speed up is calculated using the ratio of input and output bytes in
SonicAudioProcessor.scaleDurationForSpeedUp. Whenever we set new playback
parameters to the audio processor these two counts are reset. If we don't reset
the offsets too, the scaled timestamp can be a large value compared to the input
and output bytes causing massive inaccuracies (like the +20 seconds in the
linked issue).

Issue:#6117
PiperOrigin-RevId: 256533780

Before this change we'd release the audio track and create a new one as soon
as audio processors had drained when reconfiguring.

Fix this behavior by stop()ing the AudioTrack to play out all written data.

Issue: #2446
PiperOrigin-RevId: 244812402

PiperOrigin-RevId: 257138448

We currently handle most the control code logic after handling special
characters. This includes filtering out repeated control codes and checking
for the correct channel. As the special character sets are control codes as well,
these checks should happen before parsing the characters.

Issue:#6133
PiperOrigin-RevId: 256993672

PiperOrigin-RevId: 256676196

PiperOrigin-RevId: 256147805

1. Only output video starting from a keyframe
2. When calculating the timestamp offset to adjust live streams to start
   at t=0, use the timestamp of the first tag from which a sample is actually
   output, rather than just the first audio/video tag. The test streams in
   the referenced GitHub issue start with a video tag whose packet type is
   AVC_PACKET_TYPE_SEQUENCE_HEADER (i.e. does not contain a sample) and whose
   timestamp is set to 0 (i.e. isn't set). The timestamp is set correctly on
   tags that from which a sample is actually output.

Issue: #6111
PiperOrigin-RevId: 256147747

Issue: #6047
PiperOrigin-RevId: 255992898

Issue:#6109
PiperOrigin-RevId: 255933121

PiperOrigin-RevId: 255584000

ISSUE: #6093
PiperOrigin-RevId: 255471282

PiperOrigin-RevId: 255380796

Also add layer of indirection between code and the guide, to
make moving content easier going forward.

PiperOrigin-RevId: 255182216

Fix a super tiny typo.

These are mostly nullability issues.

PiperOrigin-RevId: 253537068

This permission has normal access right and can't be revoked by the user.
However, an app can choose to revoke it when using ExoPlayer, e.g. if
no network is required and the app doesn't want to list this permission.

Support this use case by gracefully catching the exception in the relevant
places.

Issue:#6019
PiperOrigin-RevId: 253759332

PiperOrigin-RevId: 254182080

We currently don't display the last frame because the seek time is behind the
last frame's timestamps and it's thus marked as decodeOnly.

This case can be detected by checking whether all data sent to the codec is
marked as decodeOnly at the time we read the end of stream signal. If so, we
can re-enable the last frame. This should work for almost all cases because the
end-of-stream signal is read in the same feedInputBuffer loop as the last
frame and we therefore haven't released the last frame buffer yet.

Issue:#2568
PiperOrigin-RevId: 251425870

r2.10.2

Issue: #6016

Issue: #5928
PiperOrigin-RevId: 254379085

PiperOrigin-RevId: 254156143

Issue: #6073

PiperOrigin-RevId: 253959976

ISSUE: #6041
PiperOrigin-RevId: 253958225

PiperOrigin-RevId: 253808562

We are currently queuing periods in a way such that the new start position
lines up with the end of the previous period (to ensure continuous playback).
However, if the start position of the new period is larger than the total of
all previously played period durations, we may end up with negative renderer
timestamps when seeking back to the beginning of this new period. Negative
timestamps should be avoided as most decoders have problems handling them
correctly.

This change forces a renderer reset if we detect such a seek to a negative
renderer time and also resets the renderer offset to 0 every time all
renderers are disabled, as this is the only time where we can savely change
the offset of an existing media period.

Also, if playback starts with an ad, we choose the content position as
renderer offset to prevent the whole issue from occurring for the seek-behind-
midroll case.

Issue:#6009
Issue:#5323
PiperOrigin-RevId: 253790054

Issue: #6031
PiperOrigin-RevId: 253784986

Issue:#6006
PiperOrigin-RevId: 253781533

In some edge cases the renderer position may be slightly ahead of the
buffered position and the total buffered duration is thus negative. We already
filter that in ExoPlayerImpl for the publicly accessible value. However, we
forward the unfiltered value to other components like the LoadControl, which
may be confusing.

Issue:#6015
PiperOrigin-RevId: 253780460

PiperOrigin-RevId: 253762488