SDK / exoplayer

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

Issue: #6229
PiperOrigin-RevId: 260500986

PiperOrigin-RevId: 260479923

Both periods are rarely updated in the same iteration. If they are, advancing
the reading period first seems more logical and also more efficient as it may
avoid one extra doSomeWork iteration.

PiperOrigin-RevId: 260463735

Moved update of reading and playing periods in their own respective method.
This is a no-op change.

PiperOrigin-RevId: 260463668

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

Issue: #6222
PiperOrigin-RevId: 260146226

PiperOrigin-RevId: 260021990

PiperOrigin-RevId: 259918196

We keep track of the last publicly known playing period to report it as part
of events happening after the period has been released.

In cases where a period briefly becomes the playing one and is released
immediately afterwards, we currently don't save it as the "last known playing
one". Improve that by saving an explicit reference.

Issue:#5407
PiperOrigin-RevId: 259737218

Creating a period in MaskingMediaSource may result in delayed event reporting
depending on when the actual period gets created. To avoid event reporting
inaccuracies, report the mediaPeriodCreated and mediaPeriodReleased events
directly.

Issue:#5407
PiperOrigin-RevId: 259737170

Both tags allow any BCP47 compliant code, not just the ISO 639-2/T ones.

PiperOrigin-RevId: 259714587

This changes the logic in the following ways:
 - If no preferred language is matched, prefer better scores for the selected
   audio language.
 - If a preferred language is matched, always prefer the better match
   irrespective of default or forced flags.
 - If a preferred language score and the isForced flag is the same, prefer
   tracks with a better selected audio language match.

PiperOrigin-RevId: 259707430

PiperOrigin-RevId: 259707359

PiperOrigin-RevId: 259687632

PiperOrigin-RevId: 259608495

PiperOrigin-RevId: 259586520

PiperOrigin-RevId: 259582498

Some variables were defined although they are the default and other things
were set-up in a non-sensible way, e.g. asserting that audio is selected
although no audio renderer is available, or using unset duration for
everything.

PiperOrigin-RevId: 259532782

PiperOrigin-RevId: 259529691