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
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 1347d572ef9ce79aacd667cfffa7d7468c8408a4
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 1347d572ef9ce79aacd667cfffa7d7468c8408a4
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
