SDK / exoplayer

Catching OOM errors is bad practise unless there is a specific known
cause that tried to allocate a large amount of memory. Without this
known cause with a large allocation, the source of the error is
likely somewhere else in the app and every random small further
allocation may lead to additional OOM errors (for example b/145134199).

We have three known causes in ExoPlayer:
 1. Source allocations based on unexpected values in streams. This is
    caught on the loader thread and reported as an
    UnexpectedLoaderException.
 2. Output buffer allocations by non-MediaCodec decoders. These are
    caught in SimpleDecoder on the decoder thread and reported as
    UnexpectedDecodeException.
 3. Input buffer allocations by non-MediaCodc decoders in their
    constructors. These are currently caught on a higher-level and
    reported as ExoPlaybackException.TYPE_OUT_OF_MEMORY.

For consistency and to prevent catching OOM errors without known cause
we can remove the generic TYPE_OUT_OF_MEMORY and catch the specific
exception where it occurs to report it as an
ExoPlaybackException.TYPE_RENDERER. This also has the added advantage
that the format metadata is added to the exception.

PiperOrigin-RevId: 351326688

PiperOrigin-RevId: 351305387

This potentially allows a caller to resize their buffers to take into account
the required size.

It's kept as an IllegalStateException, since most use cases where it's thrown
still reflect invalid states, and since making it a checked exception requires
marking a lot of methods with throws clauses.

PiperOrigin-RevId: 351216968

Issue: #7344
Issue: #8339
PiperOrigin-RevId: 351212047

#minor-release

PiperOrigin-RevId: 351169686

#minor-release

PiperOrigin-RevId: 351158541

#minor-release

PiperOrigin-RevId: 351144857

*** Original commit ***

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

*** 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 so...

***

PiperOrigin-RevId: 351139861

Whether a resource resolves to a known length or not is more than just
a property of the resource & data source - for example if
`DataSpec.flags` contains `ALLOW_GZIP` then the length might be
unresolved. More generally, a `DataSource` could randomly return
`C.UNKNOWN_LENGTH` from `open()` 50% of the time and still fulfil the
`DataSource` interface. This makes it ~impossible to write a meaningful
assertion aroun this.

So this change relaxes the assertion slightly to more closely match the
definition of the `DataSource` interface.

We leave the `resolveToUnknownLength` toggle in
`WebServerDispatcher.Resource` because this is still useful for
simulating the case of a server that is serving a file it doesn't
know the length of.

PiperOrigin-RevId: 351124246

PiperOrigin-RevId: 351117930

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