SDK / exoplayer

A previous change added these getters to CacheDataSource, but it can
also be useful to retrieve these components directly from the factory.
This is useful for tasks where we're going to need to build multiple
CacheDataSource instances (e.g., to make requests in parallel), and
also need to operate directly on the same components. It's a bit more
natural to retrieve them from the factory than from an arbitrary
CacheDataSource in this case, since it can avoid unnatural code where
you create a CacheDataSource instance earlier than you would otherwise
just to use its getters, and/or create one just to use its getters and
then throw it away.

PiperOrigin-RevId: 308606020

PiperOrigin-RevId: 308597964

- Executor is a superclass of ExecutorService, so this is arguably a little
  more flexible.
- It removes the need to use null for direct execution, because Runnable::run
  is a direct executor that can be trivially used instead.
- Removing the error-prone "cannot be a direct executor" restriction in the
  parallel version of SegmentDownloader requires not relying on the futures
  returned from ExecutorService.submit() anyway.

Issue: #5978
PiperOrigin-RevId: 308586620

When pausing and resuming a playback using an AdsLoader
it is necessary to call setPlayer again. This fixes an
issue where playback was stuck in the buffering state
when pausing and resuming an ad playback in the demo app.

PiperOrigin-RevId: 308582143

Notes: this doesn't fix the current issue where the component containing the
ad overlay view leaks, but is good practice anyway.
PiperOrigin-RevId: 308582036

PiperOrigin-RevId: 308229206

Currently, this method is only supposed to be called before removing
the listener from the player or when releasing the player.

If called at other times, it will throw an exception later when
a playback session is ended automatically.

issue:#7193
PiperOrigin-RevId: 308254993

PiperOrigin-RevId: 308246116

The error type thrown when acquiring a license that has already
been released changed from MediaDrmStateException to IllegalStateException
from API 29.

Update the tests to assert the correct type of error based on API version.

PiperOrigin-RevId: 308239508

Issue: #7273
PiperOrigin-RevId: 308238035

The method is used to finish a brief "seeking" state that can be removed entirely
now state changes for seeking are masked.

PiperOrigin-RevId: 308237009

This changes fixes issue #7181.  Removing CEA-608 captions that timeout after 16 seconds without a
clear.

This makes the distinction more clear between the methods that test
a specific behaviour (and are meant to be used with parameterized
tests) and those that test everything in one go.

Also add a TODO to FlacExtractorTest to migrate it when we can

PiperOrigin-RevId: 308228421

Also mark the two assertOutput methods private, to make the API surface
smaller.

PiperOrigin-RevId: 308228186

Unmarshal from json to MediaItem instead of Sample. Further the playlist
of MediaItems is converted to Intent extras which are read by the
PlayerActivity.

PiperOrigin-RevId: 308141231

While most ExoPlayer code parsing ByteBuffers is called with buffers in big
endian, in certain situation, buffers in little endian are used too.

MediaCodec produced ByteBuffers are in little endian, while buffers
receive from the sources are in big endian (ByteBuffer's default).

As a result, some code called from AudioSink in passthrough parsed
bytebuffer in little endian. This is not correct because those
format are specified in BigEndian.

Changing the endianness of the ByteBuffer returned from MediaCodec
would impact a lot more code that can currently be tested in the
current COVID lockdown situation.

As a result, this patch instead make the parsing code independent
of the ByteBuffer.order() set. All the code that is called from
DefaultAudioSink now parses the buffer explicitly in Big Endian.

Additionally, the MPEG big endian header data of size 4 bytes was
retrieved with ByteBuffer.get, which only returns one byte.

PiperOrigin-RevId: 308116173

PiperOrigin-RevId: 308115863

The first session should only be created once we have the media items
and/or called prepare. Otherwise the first session is created with
an EventTime having an empty timeline making it less useful.

issue:#7193
PiperOrigin-RevId: 308100555

Issue: #5978
PiperOrigin-RevId: 308076851

LoadEventInfo needs to also be sent to the LoadErrorHandlingPolicy.

PiperOrigin-RevId: 308066998

This better supports custom listener types defined by MediaSource
subclasses.

Part of issue:#6765

PiperOrigin-RevId: 308050575

This is just some trivial cleanup to get things into a better state to
implement parallel segment downloads.

Issue: #5978
PiperOrigin-RevId: 308041996

PiperOrigin-RevId: 308041841

PiperOrigin-RevId: 308031992

The MediaSessionConnector gets a Bundle passed to the MediaSession.Callback
from the framework which can be null. This needs to be properly annotated
with @Nullable.

Issue: #7234
PiperOrigin-RevId: 307822764

Issue: #5978
PiperOrigin-RevId: 307819608

Handles pixel aspect ratio changes in playlists where video
resolution does not change.

Issue:#6646
PiperOrigin-RevId: 307817028

PiperOrigin-RevId: 307789384

This avoids the non-parameterized tests being run repeatedly for every
combination of parameters.

PiperOrigin-RevId: 307785770

Part of what makes these tests hard to deal with (imo) is being
unable to easily run a specific config, or seeing exactly which one
failed (because you always see only the first failure).

I put the parameters as a method on ExtractorAsserts to
reduce the boiler-plate required in each test class.

I'll migrate the extension FlacExtractorTest in a follow-up CL

PiperOrigin-RevId: 307785380

PiperOrigin-RevId: 307777265

PiperOrigin-RevId: 307776363

PiperOrigin-RevId: 307764457

PiperOrigin-RevId: 307684243

Something that helps a constructor always seemed a bit strange.
It's now possible to use CacheDataSource.Factory directly instead.

PiperOrigin-RevId: 307661930

In the same way it made sense to tie CacheKeyFactory and CacheDataSource
together in
https://github.com/google/ExoPlayer/commit/7ea83d7167d0b021fb280fca2b5dfa4a5616b5c1,
it makes sense to tie the PriorityTaskManager to the CacheDataSource as
well. This prevents error prone scenarios where one can end up being
passed around without (or with the wrong instance of) the other.

This change also internalizes use of PriorityDataSource directly into
CacheDataSource, rather than requiring the caller to chain things
themselves.

PiperOrigin-RevId: 307647290

PiperOrigin-RevId: 307636959