SDK / exoplayer

The combination of pre-16 API levels accounting for ~0.5% of the device
population, and that the most important components in ExoPlayer (e.g.
the MediaCodec renderers) have always required API level 16, mean it's
very unlikely this will negatively impact on anyone.

PiperOrigin-RevId: 230701808

This interface will get an SQLite implementation in a subsequent CL

PiperOrigin-RevId: 230693881

We need to support serialization to/from an SQLite table. The
model of passing something around for each class to write into
doesn't work well for SQL, and it would be messy to have two
different structural designs for serialization. This change
centralizes the logic in CachedContentIndex, where a centralized
SQL based version can more easily sit alongside it.

PiperOrigin-RevId: 230692291

This method is a generalization of the existing hasReadStreamToEnd. It is
useful to determine whether a renderer already read beyond a new duration of
a period.

PiperOrigin-RevId: 230689165

Necessary in two scenarios:
+ When the demo app starts casting to a receiver app that already
  had a queue.
+ When two demo apps are connected to the same receiver app and
  both make modifications.

PiperOrigin-RevId: 230546851

1. The method kept track of the current period index to check if the next
period is still in the correct period. This is unneccessary since we no longer
use the period index but the actual uid in MediaPeriodId and mismatches are
already detected by canKeepMediaPeriodHolder.
2. We updated the MediaPeriodIndfo twice: once in getFollowingMediaPeriodInfo
and once in getUpdatedMediaPeriodInfo. That's confusing and difficult to
follow. The only difference is that getUpdatedMediaPeriodInfo keeps the
content position while getFollowingMediaPeriodInfo resets it. This is made more
explicit for readability.
3. The durations compatibility check for all following periods was broken as
it compared the same durations (partly due to the confusion caused by 2.)

PiperOrigin-RevId: 230519295

Issue: #4253
PiperOrigin-RevId: 230497544

PiperOrigin-RevId: 230496581

Seems like more useful default behaviour

PiperOrigin-RevId: 230356813

PiperOrigin-RevId: 230260266

This doesn't happen automatically after all on older devices

PiperOrigin-RevId: 230251258

PiperOrigin-RevId: 230220448

ExoPlaybackExceptions of type SOURCE are always associated with the loading
period and thus we can use the event time for the loading period in
onPlayerError. Renderer and unexpected exceptions are still associated with the
currently playing period.

Issue:#5407
PiperOrigin-RevId: 230216253

PiperOrigin-RevId: 230213842

PiperOrigin-RevId: 230209898

The Amlogic awesome decoder reduces the video size of interlaced videos by half
if the internal configuration isn't force reset with new maximum input size
values. The product of these new values must exceed 1920x1088 to force the
reset.

Issue:#5003
PiperOrigin-RevId: 230206675

PiperOrigin-RevId: 230203593

Prevents collisions with SCTE-35 subtitles.

Issue:#5330
PiperOrigin-RevId: 230195494

PiperOrigin-RevId: 229946997

PiperOrigin-RevId: 229934901

PiperOrigin-RevId: 229934333

Issue: #3561
PiperOrigin-RevId: 229934093

Allows testing DRM-protected content in the receiver app.

Includes the DRM-related data to the media items, but does not
add support for DRM content in the local player yet.

PiperOrigin-RevId: 229932329

Change the dependency to the new monolithic GVR SDK target.

PiperOrigin-RevId: 229931549

This mimicks a similar change in the default AdaptiveTrackSelection.
Also adds an option to cap initial format height.

PiperOrigin-RevId: 229923149

PiperOrigin-RevId: 229841782

Issue:#5402
PiperOrigin-RevId: 229758525

That's the same position set in MediaPeriod.prepare (where it may be removed
in the future).

Having the position at an earlier point is necessary to fix an
issue with lazy preparation in ConcatenatingMediaSource where the prepare
position was assumed to be known but MediaPeriod.prepare hasn't been called
yet.

Issue:#5350
PiperOrigin-RevId: 229756637

PiperOrigin-RevId: 229755532

This class includes helper methods to upgrade ActionFiles
and custom download records to DownloadIndex.

PiperOrigin-RevId: 229744441

Issue: #5301
Issue: #4988
Issue: #4813
Issue: #5344
Issue: #5117
PiperOrigin-RevId: 229603354

PiperOrigin-RevId: 229544734

Issue: #5344
PiperOrigin-RevId: 229527963

When the extra adaptation set of a switch group isn't defined in the manifest, we
currently assume it's the first adaptation group. This either leads to wrong grouping
or duplicate track groups.

Such a case may easily happen if the manifest is filtered such that only one of the
switch adaptation sets will be present in the manifest.

PiperOrigin-RevId: 229365379

PiperOrigin-RevId: 229365333

PiperOrigin-RevId: 229364563

PiperOrigin-RevId: 229364147

The buffered position is currently based on the mimimum queued timestamp of
all AV tracks. If the tracks have unequal lengths, one track continues loading
without bounds as the "buffered position" will always stay at the shorter
track's duration.

This change adds an optional buffer flag to mark the last sample of the
stream. This is set in the Mp4Extractor only so far. ExtractorMediaSource
uses this flag to ignore AV streams in the buffered duration calculation if
they already finished loading.

Issue:#3670
PiperOrigin-RevId: 229359899

That was previously handled by the player. But since we switched to Handler
messages instead of player messages, we should do that manually.

PiperOrigin-RevId: 229341747

This is not necessary as the track selection needs to be updated with
updateSelectedTrack anyway. It's also error-prone as the selection code
calls into a protected method of a not fully initialized class.

PiperOrigin-RevId: 229331669