SDK / exoplayer

PiperOrigin-RevId: 266676413

PiperOrigin-RevId: 266407058

PiperOrigin-RevId: 266396506

DefaultHttpDataSource.open() also includes the request parameters that
are inside the DataSpec.

PiperOrigin-RevId: 266350573

This is a no-op interim change to introduce key request error
handling customization. Following changes will allow users to
inject their own LoadErrorHandlingPolicy implementations.

Issue:#6334
PiperOrigin-RevId: 266344399

- Surface information provided by methods isHardwareAccelerated,
  isSoftwareOnly and isVendor added in Android Q in MediaCodecInfo
  class.
- Estimate this information based on the codec name for earlier API
  levels.

Issue:#5839
PiperOrigin-RevId: 266334850

Add HttpDataSource.getResponseCode to provide the status code associated with the most recent HTTP response.

PiperOrigin-RevId: 266218104

PiperOrigin-RevId: 266216274

PiperOrigin-RevId: 266085854

This generalizes our "does file still exist" check to also check
that the file is the expected length. If it's not, we don't trust
it. This avoids infinite recursion in CacheDataSource if a cache
file is truncated underneath the cache.

Issue: #6165
PiperOrigin-RevId: 265707928

PiperOrigin-RevId: 265662686

Implementations of ForwardingTimeline may override any of the two variants of
this method. We need to ensure that the customized override is always called.

Add back the deprecated method and make it final to forward to the
non-deprecated method in all cases for ForwardingTimelines.

PiperOrigin-RevId: 265419830

Adds HTTP request parameters in DataSpec. Keeps DataSpec behavior to be immutable as before.

PiperOrigin-RevId: 265087782

The last selection criteria is the audio bitrate to prefer higher-quality
streams. We shouldn't apply this criterium though if the languages of the
tracks are different.

Issue:#6335
PiperOrigin-RevId: 265064756

If the app seeks after we get an ads manager but before the player exposes the
timeline with ads, we would end up expecting to play a preroll even after the
seek request arrived. This caused the player to get stuck.

Wait until a non-empty timeline has been exposed via onTimelineChanged before
initializing IMA (at which point it can start polling the player position). Seek
requests are not handled while an ad is playing.

PiperOrigin-RevId: 265058325

PiperOrigin-RevId: 265018783

The implementation can't work properly unless these methods are called by
subclasses, so annotate them to require calling the super implementation when
overriding.

PiperOrigin-RevId: 265017433

The error is closely related to the playback state IDLE and should be updated
in sync with the state to prevent unexpected event ordering and/or keeping the
error after re-preparation.

Issue:#5407
PiperOrigin-RevId: 265014630

Update comment to indicate correct int value of "FLAG_ALLOW_CACHE_FRAGMENTATION" in ExoPlayer2 upstream DataSpec

Currently the value of FLAG_ALLOW_CACHE_FRAGMENTATION is defined as "1 << 4" but commented as "8". Either the value of FLAG_ALLOW_CACHE_FRAGMENTATION should be "1 << 3", or the comment should be 16. Here I am modifying the comment since it does not affect any current behavior.

PiperOrigin-RevId: 265011839

The app is able to pass a more specialized array type, so the Arrays.copyOf call
produces an array into which it's not valid to store arbitrary AudioProcessors.

Create a new array and copy into it to avoid this problem.

PiperOrigin-RevId: 264779164

Any seek before the first timeline becomes available will result in a NPE.
Change it to handle that case gracefully.

Issue:#5831
PiperOrigin-RevId: 264603061

This situation happens if the first chunk to load is already behind the end
of the stream. In this case, the preparation never completes because
HlsSampleStreamWrapper gets stuck in a prepared=false and loadingFinished=true
state.

Gracefully handle this situation by attempting to load the last chunk if still
unprepared to ensure that track information is obtained as far as possible.
Otherwise, it wouldn't be possible to play anything even when seeking back.

Issue:#6314
PiperOrigin-RevId: 264599465

Extract supplemental data from block additions in WebM/Matroska.

Allow storing supplemental data alongside samples in the SampleQueue and write
it as a separate field in DecoderInputBuffers.

Handle supplemental data in the VP9 extension by propagating it to the output
buffer.

Handle supplemental data for HDR10+ in MediaCodecVideoRenderer by passing it to
MediaCodec.setParameters, if supported by the component.

PiperOrigin-RevId: 264582805

AdsMediaSource posts AdsLoader.start to the main thread during preparation, but
the app may call AdsLoader.setPlayer(null) before it actually runs (e.g., if
initializing then quickly backgrounding the player).

This is valid usage of the API so handle this case instead of asserting. Because
not calling setPlayer at all is a pitfall of the API, track whether setPlayer
has been called and still assert that in AdsLoader.start.

PiperOrigin-RevId: 264329632

Both values are needed to set-up the ExoPlayer instances for playlists.

PiperOrigin-RevId: 264146052

https://developer.apple.com/documentation/http_live_streaming/about_the_common_media_application_format_with_http_live_streaming

PiperOrigin-RevId: 264126140

There is no point in having this parameter as the tag should always be a single
immutable object instantiated at the time the Timeline is created or earlier.

So there is no preformance benefit and it's error-prone in case people
forget to set setTag=true.

PiperOrigin-RevId: 264117041

This solves various issues around event association for buffering and
error throwing around period discontinuities.

The main changes are:
 - Logic around being "ready" at the end of a period no longer checks if the
   next period is prepared.
 - Advancing the playing period no longer checks if the next one is prepared.
 - Prepare errors are always thrown for the playing period.

This changes the semantics and assumptions about the "playing" period:
 1. The playing period can no longer assumed to be prepared.
 2. We no longer have a case where the queue is non-empty and the playing or
    reading periods are unassigned (=null).
Most other code changes ensure that these changed assumptions are handled.

Issue:#5407
PiperOrigin-RevId: 263776304

PiperOrigin-RevId: 263768428

This field is used in .equals(), so it makes sense to include it in toString() too.

PiperOrigin-RevId: 263768329

This matches the documentation on MetadataDecoder.decode:
"@return The decoded metadata object, or null if the metadata could not be decoded."

PiperOrigin-RevId: 263767144

Most users are likely to be only interested in the playlist items. So put the
Window definition first and explicitly mention that this is a playlist
item.

PiperOrigin-RevId: 263764515

*** Original commit ***

Rollback of https://github.com/google/ExoPlayer/commit/bbe681a904d58fe1f84f6c7c6e3390d932c86249

*** Original commit ***

PiperOrigin-RevId: 263736897

PiperOrigin-RevId: 263718527

PiperOrigin-RevId: 263552552

Currently we fail silently for high bit depth output when using ANativeWindow
output mode.

PiperOrigin-RevId: 263549384