SDK / exoplayer

This is a partial revert of
https://github.com/google/ExoPlayer/commit/46598a46fd3c13a9be906abd6c673b9487ba5d50

The change from reset(int) to setPosition/Limit() in this file was
incorrect, the reset(int) call is important because it ensures
`bitmapData` is large enough for the `buffer.readBytes` call on L188.

Issue: #8417
PiperOrigin-RevId: 351110038

1. Remove cookie manager logic from PlayerActivity, since it has
   no effect when Cronet is used (which is now the default)
2. Add toggle in DemoUtil to use Cronet or the default network
   stack. Configure the cookie manager only when using the default
   network stack

PiperOrigin-RevId: 350922671

- Support setting the user-agent in CronetDataSource
- Support setting the default user-agent in CronetEngineWrapper
- Use the underlying network stack's default user-agent by
  default. Many applications will configure the underlying
  CronetEngine or OkHttpClient with a user-agent that they
  expect to be used throughout their app, so always overriding
  this with our own default, on reflection, is not the best
  thing to do!

Issue: #8395
PiperOrigin-RevId: 350921963

BatchBuffer has three different clear methods (clear, flush,
batchWasConsumed), and it's not hugely clear what each of them
does. In general, BatchBuffer owning the sample buffer seems
more complicated than having the caller own it, particularly
when it can be "pending" inside of the batch buffer.

This change moves ownership of the sample buffer to the
caller. BatchBuffer is simplified as a result. There are also
two behaviour changes:

1. The buffer's timeUs field is now set to the first sample's
   timestamp, rather than the last sample's.
2. A key-frame in the middle of the batch no longer causes the
   batch buffer to be considered a key-frame. Which seems like
   the right thing to do, because the batched data cannot be
   decoded independently of whatever came before it.

PiperOrigin-RevId: 350921306

*** Original commit ***

Merge #8401: Initialize Format.codecs from HEVC SPS NAL unit (#8393)

Imported from GitHub PR https://github.com/google/ExoPlayer/pull/8401

This will allow ExoPlayer to check if video track's profile and level are supported by decoder when playing progressive media sources.
Merge e582fb91b73c7c95e754167140211d5473c36d14 into 1347d572

Issue: #8393

***

PiperOrigin-RevId: 350871621

PiperOrigin-RevId: 350797551

Issue: #8408
PiperOrigin-RevId: 350786430

#minor-release

PiperOrigin-RevId: 350782940

I think this was missed when integrating DefaultMediaSourceFactory with
SingleSampleMediaSource.Factory in
https://github.com/google/ExoPlayer/commit/315ba6f324b03ef651773a3bdb43386dcb1281ca

Issue: #8430
#minor-release
PiperOrigin-RevId: 350759580

The Palette Definition Segment is documented here, you can is it goes:
luminance (y), red (cr), blue (cb), alpha

http://blog.thescorpius.com/index.php/2017/07/15/presentation-graphic-stream-sup-files-bluray-subtitle-format/

(I think it's important to be really precise here, because YCbCr is a
very common format, so this ordering is slightly unusual:
https://en.wikipedia.org/wiki/YCbCr)

PiperOrigin-RevId: 350747808

There is a race condition when initializing the downloads database. The
constructor of the DownloadManager kicks-off the database initialization
in its internal thread, but at the same time an app can try to access
the database directly through the manager's download index, e.g. doing

DonwloadManager manager = new ...
manager.getDownloadIndex().getDownload("id");

might enter DefaultDownloadIndex.ensureInitialized() from two threads.
When upgrading the downloads table from version 2 to version 3, the
first thread that enters the database transaction in ensureInitialized()
will drop and recreate the table using the v3 schema. Then, the second
thread will attempt to read from the newly created table using the v2
schema, which will fail.

This race condition was not introduced in 2.12 but was there already.
However, prior to 2.12, the code only dropped and re-created and the
table and did not attempt to read any data. Hence, if the race condition
happened, the code would drop and create the table twice, but no error
would occur.

Issue: #8420
#minor-release
PiperOrigin-RevId: 350745463

Imported from GitHub PR https://github.com/google/ExoPlayer/pull/8401

This will allow ExoPlayer to check if video track's profile and level are supported by decoder when playing progressive media sources.
Merge e582fb91b73c7c95e754167140211d5473c36d14 into 1347d572

Issue: #8393
COPYBARA_INTEGRATE_REVIEW=https://github.com/google/ExoPlayer/pull/8401 from equeim:hevc-codecs e582fb91b73c7c95e754167140211d5473c36d14
PiperOrigin-RevId: 350738065

This requires the parent of the background to draw and have padding large enough to support the size of the ripple.

The bottom buttons must remained bordered as the space around them is constrained.

PiperOrigin-RevId: 350590722

PiperOrigin-RevId: 350578598

Without this feature it's impossible to nicely merge multiple sources
with different durations if these durations are not known exactly
before the start of playback.

Issue: #8422
PiperOrigin-RevId: 350567625

This helps to better disambiguate the file from other mpd files in the
directory.

PiperOrigin-RevId: 350552168

These tests are performing offline-centric assertions using a streaming
licence. They need to be reconfigured to use a new offline-centric
licence that sets the correct duration fields (rental_duration_seconds
and playback_duration_seconds).

PiperOrigin-RevId: 350550971

This allows to set preferences based on MIME type for video and audio.
The MIME type preference is applied after other explicit preferences
and restrictions (e.g. language or max resolution), but before implicit
preferences like bitrate.

Issue: #8320
PiperOrigin-RevId: 350550543

Issue: #5011
PiperOrigin-RevId: 350550204

Reported by https://github.com/google/ExoPlayer/issues/8329.

PiperOrigin-RevId: 350547523

*** Original commit ***

Restore old SampleQueue exoMediaCryptoType behavior

***

PiperOrigin-RevId: 350545215

Issue: #5011
PiperOrigin-RevId: 350540152

Add assertion to check an output format has been propagated before
returning an output buffer when operating MediaCodec in asynchronous
mode.

PiperOrigin-RevId: 350534918

`stop(true)` is almost the same as `clearMediaItems(); stop();`, except that
any player error isn't cleared. Clearing media items more clearly expresses the
intent.

PiperOrigin-RevId: 350516748

The flag compared against the nowTime in the period that is only
set to a positive value for live streams.

PiperOrigin-RevId: 350514934

PiperOrigin-RevId: 350442843

In many cases we just used "playback speed" as a detailed Javadoc
parameter or return type definition. This doesn't define which scale
the speed is using.

PlaybackParameters as the main point to set the speed already uses a
more precise wording to describe the value as a factor by which playback
will be sped up.

This change replaces other usages of "playback speed" with this wording
whereever we would usually add a unit, keeping "playback speed" for
summary statements etc to reference the general concept that doesn't
usually require a unit.

PiperOrigin-RevId: 350379139

Issue: #8190
PiperOrigin-RevId: 350357825

The experimental setting shows positive results and can be turned
on by default. To avoid adaptation between HLS audio formats without
bitrates, we need to ensure that only formats with bitrates are
considered for adaptation.

Also added tests for these features.

Issue: #5111
PiperOrigin-RevId: 350315296

The AsynchronousMediaCodecCallback has logic to retain a pending
output format in case flush() is called. This commit fixes a case where
calling flush() again while an output format is pending would nullify
the pending output format.

A unit test is added in AsynchronousMediaCodecCallback but not the
AsynchronousMediaCodecAdapter. That is because the adapter operates
directly on top of MediaCodec, but Robolectric's ShadowMediaCodec
produces an output format on every MediaCodec.start(). This is
unrealistic when operating MediaCodec in asynchronous mode where we
need to call MediaCodec.start() after every MediaCodec.flush().

PiperOrigin-RevId: 350176659

 - The AdaptiveTrackSelection doesn't need to use the experimental
terminolgy because the code is always triggered if there are multiple
adaptive selections.

- It's also confusing to pass the state on the outside after the object
creation, so moving everything into a simple control flow again where
the adaptation checkpoints are passed in via the constructor.

- Instead of triple arrays, we can use more readable named structures.

- The calculation of the checkpoints can be cleaned up to be more
readable by moving things to helper methods.

- The reserved bandwidth from all fixed track selections is really just
a special case of multiple parallel adaptataions. So this logic doesn't
need to be separate.

- The whole logic also didn't have test coverage so far. Added tests
for the actual adaptation using these checkpoints and the builder
calculating the checkpoints.

Overall this should be a no-op change.

PiperOrigin-RevId: 350162834

Overriding this method will never be necessary or advisable once we
improve routing of audio session IDs

Issue: #8190
PiperOrigin-RevId: 350146302

set responseBody to Util.EMPTY_BYTE_ARRAY when an IOException occurs trying to get his value from inputStream

set responseBody to Util.EMPTY_BYTE_ARRAY when an IOException occurs trying to get his value from inputStream

Issue: #8419
#minor-release
PiperOrigin-RevId: 350134719

PiperOrigin-RevId: 350105847

PiperOrigin-RevId: 350100601

This is in preparation for using them from the extractor module.

PiperOrigin-RevId: 349571390