SDK / exoplayer

r2.10.4

If we keep streams in chunk sources after selecting new tracks, we also keep
a reference to a stale disabled TrackSelection object. Fix this by updating
the TrackSelection object when keeping the stream. The static part of the
selection (i.e. the subset of selected tracks) stays the same in all cases.

Issue:#6256
PiperOrigin-RevId: 261696082

Issue:#6260
PiperOrigin-RevId: 261647858

PiperOrigin-RevId: 261353271

PiperOrigin-RevId: 261341256

PiperOrigin-RevId: 261340526

PiperOrigin-RevId: 261328701

PiperOrigin-RevId: 261320318

- Test seeking to (timeUs=0, position=0), which should always work
  and produce the same output as initially reading from the start
  of the stream.
- Reset the input when testing seeking, to ensure IO errors are
  simulated for this case.

PiperOrigin-RevId: 261317898

- When in STATE_SEEK with targetGranule==0, seeking would exit
  without checking that the input was positioned at the correct
  place.
- Seeking could fail due to trying to read beyond the end of the
  stream.
- Seeking was not robust against IO errors during the skip phase
  that occurs after the binary search has sufficiently converged.

PiperOrigin-RevId: 261317035

A previous change switched to calculation of the bitrate based on the
first MPEG audio header in the stream. This had the effect of fixing
seeking to be consistent with playing from the start for streams where
every frame has the same padding value, but broke streams where the
encoder (correctly) modifies the padding value to match the declared
bitrate in the header.

Issue: #6238
PiperOrigin-RevId: 261163904

Issue: #6241
PiperOrigin-RevId: 261126968

PiperOrigin-RevId: 260970865

They're not unexpected!

PiperOrigin-RevId: 260907687

PiperOrigin-RevId: 244173887

Issue: #5938
PiperOrigin-RevId: 261150349

Android considers ALAC initialization data to consider of the magic
cookie only, where-as FFmpeg requires a full atom. Standardize around
the Android definition, since it makes more sense (the magic cookie
being contained within an atom is container specific, where-as the
decoder shouldn't care what container the media stream is carried in)

Issue: #5938
PiperOrigin-RevId: 261124155

PiperOrigin-RevId: 261102180

PiperOrigin-RevId: 261102008

ISSUE: #5938
PiperOrigin-RevId: 261097045

PiperOrigin-RevId: 261087432

Checking inputPosition == 0 isn't sufficient because the synchronization
at the top of read() may advance the input (i.e. in the case where there's
some garbage prior to the seek frame).

PiperOrigin-RevId: 261086901

PiperOrigin-RevId: 260947018

This could previously occur when seeking back to position=0

PiperOrigin-RevId: 260933636

Update javadoc for TrackOutput#sampleData to make it more clear that implementors aren't expected to rewind with setPosition()

PiperOrigin-RevId: 260718614

PiperOrigin-RevId: 260583198

Issue: #6229
PiperOrigin-RevId: 260500986

PiperOrigin-RevId: 249250184

PiperOrigin-RevId: 260164426

When using speed adjustment it was possible for playback to get stuck at a
period transition when the channel count changed: SonicAudioProcessor would be
drained at the point of the period transition in preparation for creating a new
AudioTrack with the new channel count, but during draining the incorrect (new)
channel count was used to calculate the output buffer size for pending data from
Sonic. This meant that, for example, if the channel count changed from stereo to
mono we could have an output buffer size that stored an non-integer number of
audio frames, and in turn this would cause writing to the AudioTrack to get
stuck as the AudioTrack would prevent writing a partial audio frame.

Use Sonic's current channel count when draining output to fix the issue.

PiperOrigin-RevId: 260156541

PiperOrigin-RevId: 258812820

Issue: #6222
PiperOrigin-RevId: 260146226

PiperOrigin-RevId: 259582498

1. Using the Locale on API<21 doesn't make any sense because it's a no-op
   anyway. Slightly restructured the code to avoid that.
2. API<21 often reports languages with non-standard underscores instead of
   dashes. Normalize that too.
3. Some invalid language tags on API>21 get normalized to "und". Use original
   tag in such a case.

Issue:#6153
PiperOrigin-RevId: 258773463