SDK / exoplayer

PiperOrigin-RevId: 382277352

This affects the setter, getter and callback, as well as various
media 3 methods.

PiperOrigin-RevId: 382275672

PiperOrigin-RevId: 382139109

#minor-release

Issue:#7608
PiperOrigin-RevId: 382081687

PiperOrigin-RevId: 381941053

PiperOrigin-RevId: 381852972

PiperOrigin-RevId: 381852092

PiperOrigin-RevId: 381837274

PiperOrigin-RevId: 381833403

PiperOrigin-RevId: 381833313

PiperOrigin-RevId: 381472436

Also upgrade the RTMP extension to use an inner class
for its factory.

PiperOrigin-RevId: 381469114

Until now, we have stuck with the 3.12 long-term branch so as
to keep support for older API levels. However, this means that
the version we're using is 2.5 years old at this point. The
3.12 branch will stop receiving critical updates in December
2021.

Since use of the OkHttp extension is optional anyway, it seems
preferable to move to a modern version of OkHttp at this point.

PiperOrigin-RevId: 381465269

PiperOrigin-RevId: 381443205

Specifically:
- ERROR_CODE_IO_NETWORK_CONNECTION_TIMEOUT
- ERROR_CODE_IO_NETWORK_CONNECTION_FAILED
- ERROR_CODE_IO_NETWORK_CONNECTION_CLOSED
PiperOrigin-RevId: 381441329

And assign it to CleartextNotPermittedException.

PiperOrigin-RevId: 381247430

PiperOrigin-RevId: 381239971

PiperOrigin-RevId: 381236418

PiperOrigin-RevId: 381235721

Currently when a HTTP POST request receives a 302, CronetDataSource will change the request method from POST to GET for the redirected request, and drop the post body. This aligns with the behaviours of many user agents, but our use case would like to keep the POST method and the post body.

org.chromium.net.UrlRequest.followRedirect also changes POST to GET for 302, so should be avoided here.

PiperOrigin-RevId: 381233011

PiperOrigin-RevId: 381221669

A no-op change that changes the signature of the onChunkLoadError method of the ChunkSource. Implementors can get the exclusion duration directly from the LoadErrorHndlingPolicy instead of receiving it as an argument of the callback.

PiperOrigin-RevId: 381102935

No-op change that adds the @FallbackType IntDef and changes the signature of getBlacklistDurationMsFor(LoadErrorInfo) to getExclusionDurationMsFor(@FallbackType, LoadErrorInfo).

PiperOrigin-RevId: 381075496

A subsequent change will deprecate CronetEngineWrapper and move
all of the logic into a utility class for obtaining a suitable
CronetEngine.

This change also deprioritizes use of unknown cronet providers.

PiperOrigin-RevId: 381051164

PiperOrigin-RevId: 381021014

The way CronetDataSource.Factory can internally fall back to another
factory is confusing and unnecessary. In the case the application cannot
instantiate a CronetEngine, it should directly use another factory.

This makes CronetDataSource more consistent with OkHttpDataSource. In
both cases, their factory constructors take the component that the
respective libraries advise should only be created once by the application,
which are CronetEngine and OkHttpClient respectively.

CronetEngineWrapper will be deprecated in a subsequent change.

PiperOrigin-RevId: 381016504

PiperOrigin-RevId: 381016088

Before this change the `Format` on the image track output by the
`JpegExtractor` doesn't have a MIME type.

PiperOrigin-RevId: 381015819

Equivalent to onPlayerError, except it's also called for null.

PiperOrigin-RevId: 381015336

Previously, a SocketTimeourException is used to signal the end of the stream
that is caused by "no RTP packets received for a while". However, such
signaling is inappropriate under TransferRtpDataChannel, or FakeRtpDataChannel
in RtspPlaybackTests.

Hence, the signaling of end of stream is changed to use RESULT_END_OF_INPUT.
The RtpDataChannel implementations will Still block until a set timeout, but
will return a C.RESULT_END_OF_INPUT should a timeout occur, instead of
throwing a nested SocketTimeoutException.

This also allowed customization of the timeout amount, in
RtspMediaSource.Factory

PiperOrigin-RevId: 380981534

Those test are no longer flaky since the test clock
was made deterministic.

The removed assertions were introduced in https://github.com/google/ExoPlayer/commit/a4ad351fb15b60080ff53b345563e3f922464251.

PiperOrigin-RevId: 380793961

The current FLAG_REQUIRE_FORMAT documentation states: If an end of
stream buffer would be read were the flag not set, then behavior is
unchanged.

PiperOrigin-RevId: 380792251

The current FLAG_REQUIRE_FORMAT documentation states: If an end of
stream buffer would be read were the flag not set, then behavior is
unchanged.

PiperOrigin-RevId: 380781976

After this change, multiple BaseURL elements are parsed, but the player still only uses the first BaseURL element appearing in the manifest and its corresponding availabilityTimeOffsetUs.

PiperOrigin-RevId: 380775256

Amend release note for https://github.com/google/ExoPlayer/commit/46bc49a4f6e8194ddb28e7b17eb775157c3e241d.

PiperOrigin-RevId: 380766548

Issue: #9086
#minor-release
PiperOrigin-RevId: 380756562

The problem occurs when the primary media playlist URL switches
from one whose latest snapshot has not yet got the ended tag, to
one whose latest snapshot already has the ended tag. In this case:

- We trigger a redundant load of the ended playlist.
- When the redundant load completes,
  MediaPlaylistBundle.processLoadedPlaylist detects that the
  playlist is unchanged from the one it already has, and so
  doesn't call onPlaylistUpdated.
- PrimaryPlaylistListener.onPrimaryPlaylistRefreshed is never
  called with the new primary. Hence the externally visible primary
  is still the one that hasn't ended. HlsMediaSource therefore thinks
  the event hasn't ended, which in turn prevents the player from
  transitioning to the ended state.

This commit detects when the new primary already has the ended tag.
In this case, we call onPrimaryPlaylistRefreshed directly and remove
the unnecessary playlist load.

Issue: #9067
#minor-release
PiperOrigin-RevId: 380680532

The glitches were introduced in:
https://github.com/google/ExoPlayer/commit/6c31e34528

The problem is that Listener.onEvents is called in a later looper iteration
than the listener methods that were previously used. This created a gap on
the main thread between the UI component dispatching a seek operation to the
player, and onEvents being called to update the progress bar's position.

At the start of this gap the progress bar is rendering the new position,
but its position member variable is still set to the old position. If the
progress bar is re-drawn by another message on the main thread within the
gap, it will briefly show the old position until onEvents is called.

There are multiple possible fixes to this, and the best one is probably to
modify ListenerSet to remove the gap. That's high risk though, so for now we
fix the flicker by always updating the progress immediately after the seek
is dispatched, in addition to when onEvents is called.

Issue: #9049
#minor-release
PiperOrigin-RevId: 380678388