SDK / exoplayer

We currently keep the sequence number if we don't reset the position. However,
the sequence number should be kept if we don't reset the state. Otherwise
re-prepare with position reset is counted as new playback although it's still
the same.

PiperOrigin-RevId: 261644924

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

PiperOrigin-RevId: 261312509

Two tests have very low propability flakiness (1:1000) due to not waiting for
a seek in one case and the chance of already being ended in another case.

Fix these and also adjust wrong comments about state changes.

PiperOrigin-RevId: 261309976

PiperOrigin-RevId: 261295173

This will be used in common video renderer and decoder classes.

PiperOrigin-RevId: 261287124

These values can easily default to the empty track group and the empty
selection. As a result we can remove restrictions about not calling
holder.getTrackGroups before the period finished preparation.

PiperOrigin-RevId: 261280927

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: #5938
PiperOrigin-RevId: 261150349

Issue: #6241
PiperOrigin-RevId: 261126968

PiperOrigin-RevId: 261125341

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

This class will be shared by both vp9 and av1 extension.

PiperOrigin-RevId: 261089225

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

This factory was only needed in the past when we didn't have
AnalyticsCollector.setPlayer. Code becomes easier to use without this factory.

PiperOrigin-RevId: 261081860

PiperOrigin-RevId: 260970865

PiperOrigin-RevId: 260947018

This could previously occur when seeking back to position=0

PiperOrigin-RevId: 260933636

They're not unexpected!

PiperOrigin-RevId: 260907687

This new annotation declares everything as non-null by default and can be
used as a package annotation in package-info.java.

In this change the core lib offline package and the mediasession extension is
annotated that way as initial example usage.

PiperOrigin-RevId: 260894548

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

PiperOrigin-RevId: 260718614

DefaultMediaClock has currently two non-ideal behaviours:
1. One part of checking if it should use the renderer clock is checking whether
   the associated renderer finished reading its stream. This only makes sense
   if the renderer isn't already reading ahead into the next period. This can
   be solved by forwarding if we are reading ahead to the sync command.
2. When switching from stand-alone to renderer clock we assume they are
   exactly at the same position. This is true in theory, but in practise there
   may be small differences due to the different natures of these clocks. To
   prevent jumping backwards in time, we can temporarily stop the stand-alone
   clock and only switch once the renderer clock reached the same position.

PiperOrigin-RevId: 260690468

PiperOrigin-RevId: 260682878

PiperOrigin-RevId: 260681773

PiperOrigin-RevId: 260583198

This will allow the Cast extension to reconstruct MediaItems from MediaQueueItems
obtained from the receiver's queue.

PiperOrigin-RevId: 260554381

PiperOrigin-RevId: 260553467

For now this just moves some code from the demo app to the extension.
Eventually the goal would be to have CastPlayer playlist methods take
MediaItem, have CastPlayer convert them internally to MediaQueueItem
for sending to the Cast SDK, and also allow reverse conversion so we
can reconstruct MediaItems from the Cast SDK's queue.

PiperOrigin-RevId: 260548020

This CL changes PlayerActivity's VIEW_LIST action intent contract:
Each media item configuration is provided by indexing the entries.
For example, the URI of the first item is passed as "uri_0", the
second one is "uri_1", etc. Optionally, the extra parameters, like
the extensions, are passed as "extension_1", where the intent extras
with matching indices, refer to the same media sample.

The VIEW action's contract remains unchanged.

PiperOrigin-RevId: 260518118