This is necessary for the child cl that `TrackSelection`
in two distinct class. It avoids to split the array
version of such class too.
TrackSelectionArray exist to have an immutable array of TrackSelection.
Internal users are trusted to not mutate the array.
One drawback of this approach is that a `TrackSelectionArray`
has to be allocated on the boundary of the `Player` interface.
This should not be a performance issue as this only happens
on trackSelection changes, when the user calls
`Player.getCurrentTrackSelections` and on
`updateLoadControlTrackSelection`.
#player-to-common
PiperOrigin-RevId: 353582654
This field changed name during the code review, but these names and
references weren't updated to match.
Also use an ImmutableSet since the field is a Set.
PiperOrigin-RevId: 353021268
This ensures the message devilery is governed by the clock.
Also replace setting a Handler with a Looper to facilititate this
change.
PiperOrigin-RevId: 353019729
Not checking it would force ExoPlayer to use the
global tmp dir which would expose it to
external file replacement attacks.
This is a theoretical vulnerability as this code is
only use in tests and cache dir always exist in the
AOSP android implementation.
PiperOrigin-RevId: 353013929
Codecs are not used by this test because PCM uses codec bypass,
but performing the setup is still necessary to have the test
verify that this is indeed the case!
PiperOrigin-RevId: 352965739
The output dumps are intentionally empty because the playback
is using bypass modes.
Still adding a AUDIO_RAW decoder to the ShadowMediaCodecConfig to
ensure that we would output samples if bypass mode were disabled.
PiperOrigin-RevId: 352794959
Also move it to the `drm` package, and extract a
`DrmSessionManagerProvider` interface.
I'll add `MediaSourceFactory.setDrmSessionProvider()` in a follow-up
change.
Issue: #8466
PiperOrigin-RevId: 352582559
Add a test to DataSourceContractTest that asserts the gzip flag is
either ignored or handled correctly.
Add a test resource to DefaultHttpDataSourceContracTest that enables
gzip compression on the 'server' and checks it's handled correctly by
the client.
PiperOrigin-RevId: 352574359
This prevents trying to post the response to possibly dead threads,
which causes an IllegalStateException to be logged.
Issue: #8328
PiperOrigin-RevId: 352388155
- Once the ability to add debug listeners is removed, analyticsCollector
is the only component that needs to receive the events. Hence it is
called directly.
- It seemed less confusing to do the same thing for (non-debug) video and
audio events, and to have AnalyticsCollector no longer implement
VideoListener and AudioListener directly. This clears up confusion that
arises as a result of the debug and non-debug interfaces defining the
same methods in some cases, and having to be careful not to end up
calling the corresponding AnalyticsCollector method twice.
PiperOrigin-RevId: 351835491
AnalyticsCollector is allowed to be subclassed to simplify adding
new events that make use of the EventTime generation.
Clean up the subclassing interface to simplify this:
- Make generateCurrentPlayerMediaPeriodEventTime protected. This is
arguably the most useful method for extended clients. Other
generateXXXEventTime methods are left private as they can't be
useful for extensions because they require some integration into
the ExoPlayer playback thread to make sense. So keeping them
private to cause less confusion.
- Some existing callback handling should be final as all the others.
- Adding @CallSuper to all lifecycle management methods that might
be helpful to subclasses but require to call the super method.
- Make sendEvent protected to let subclasses use the simple
event sending method.
PiperOrigin-RevId: 351766369
The VideoDecoderOutputBufferRenderer will be set
automatically when setVideoSurfaceView is called on a
VideoDecoderGLSurfaceView.
#player-to-common
PiperOrigin-RevId: 351742601
The cache, being static, is updated every time a new MimeType is encountered.
The static cache needs to be cleared between tests that register codecs through
ShadowMediaCodec, or the subsequent tests could possibly pick up a wrong codec.
PiperOrigin-RevId: 351576018
A previous release note has already noted to use ProgressiveMediaSource
instead of this whole class, so adding a specific release note seems
unnecessary for this one.
PiperOrigin-RevId: 351353979
- SimpleExoPlayer now always generates a session ID at
construction time. This ID is used indefinitely, including
for tunneling, unless a call to setAudioSessionId is made
to change it.
- DefaultTrackSelector support for enabling tunneling has
been changed to a boolean, since tunneling now uses the
same session ID as non-tunneled mode.
- Since the session ID is now always set at the top level,
internal propagation of generated session IDs is no longer
necessary, and so is removed.
PiperOrigin-RevId: 351349687
The ExoPlaybackException types are locations from where the exception
is coming from and not the type of exception itself, which should be
denoted by different exception classes.
To avoid a mixture of error types and class checks, the timeout
exceptions should use their own class and be of type RENDERER as this
is where the timeout actually happens.
PiperOrigin-RevId: 351337699
This allows the respective components to adapt to the speed changes
if desired.
To avoid frequent updates to the media codec operating rate, we also
forward the target speed to the renderers so that this value can be set
based on the target speed and not the current speed.
PiperOrigin-RevId: 351336401
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
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
*** Original commit ***
Rollback of ff8c8645ab
*** 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
This is a partial revert of
46598a46fd
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
- 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 1347d572ef
Issue: #8393
***
PiperOrigin-RevId: 350871621
I think this was missed when integrating DefaultMediaSourceFactory with
SingleSampleMediaSource.Factory in
315ba6f324
Issue: #8430
#minor-release
PiperOrigin-RevId: 350759580
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 1347d572ef
Issue: #8393
COPYBARA_INTEGRATE_REVIEW=https://github.com/google/ExoPlayer/pull/8401 from equeim:hevc-codecs e582fb91b73c7c95e754167140211d5473c36d14
PiperOrigin-RevId: 350738065
