- SampleQueue.peek is replaced with SampleQueue.read with
FLAG_PEEK. This also exposes peek functionality through
SampleStream.
- Use of DecoderInputBuffer.isFlagsOnly is replaced with
FLAG_OMIT_SAMPLE_DATA. This flag can be used with or
without FLAG_PEEK, where-as previously the read position
would never be advanced for an isFlagsOnly buffer.
- formatRequired is replaced with FLAG_FORMAT_REQUIRED.
PiperOrigin-RevId: 363460105
This makes HLS playback less liable to become stuck if discontinuity
tags are inserted at different times across media playlists.
Issue: #8700
Issue: #8372
PiperOrigin-RevId: 362903428
Part of aligning HttpDataSource behavior will require adding
logic that's common across the DataSource implementations. This
change establishes a util class to house it, and moves a bit of
existing logic that's related and can be easily shared into it.
There is one small behavior change in this CL, which is that our
handling of Content-Range response headers can now parse the body
length if the "document size" part of the Content-Range is unknown,
for example "bytes 5-9/*". Previously the pattern we were matching
to required the "size" part to be set, for example "bytes 5-9/100",
despite the fact we don't need or use it.
PiperOrigin-RevId: 362396976
Adds a new Listener that extends all other listener.
This is part of the component flattening goal.
After components have been flattened in Player,
and clients transitioned, existing listeners will be deprecated.
PiperOrigin-RevId: 362287507
Includes fixes for the HTTP implementations, which previously
broke this contract specifically in the case when a server
responds to a range request with a HTTP 200 response. To fix
this case, skipping to the requested position is moved from
read() to open(). As a side effect, this nicely simplifies
CronetDataSource!
PiperOrigin-RevId: 359737301
The API is a lot more useful if apps can rely on the fact
that the gain is linear and applied to all channels.
This is already guaranty by AudioTrack and should be too
by any reasonable implementation.
PiperOrigin-RevId: 359706113
The concept of Renderers is not needed in the
Player interface. Move it to ExoPlayer.
This should not break most users as they use SimpleExoPlayer.
PiperOrigin-RevId: 359220977
- Ensure consistency between (Styled)PlayerControlView,
PlayerNotificationManager, TimelineQueueNavigator and
DefaultControlDispatcher.
- Handle the case where a live stream has ended when enabling previous
and next actions (window.isLive() is true and window.isDynamic is
false in that case)
#minor-release
PiperOrigin-RevId: 359063793
Assert that an exception is not thrown from DataSource.open
if the DataSpec's start position is valid but its end position
extends beyond the end of the data.
HTTP based DataSource implementations have no good way of
knowing when this is the case, so it makes sense to make this
the required behaviour, rather than requiring an exception to
be thrown or allowing both.
There are also use cases where the caller may want to use the
end position as an upper bound, without knowing for sure how
long the content is. An example of this use case is wanting to
pre-cache the first N bytes of a stream. This implies that any
exception should be thrown after reading to the end of the
data, rather than preemptively in open.
Issue: #7326
PiperOrigin-RevId: 359063721
When we add DRM pre-acquire support to SampleQueue, we'll dispatch
twice the number of acquire and release events. This is slightly
confusing, since there's the same number of
DrmSessionManager#acquireSession() calls.
We can mitigate this by only dispatching each acquire and release
event to at most one EventDispatcher.
This also changes the events fired when playing a stream with both audio
and video encrypted with the same keys (even without pre-acquisition).
Before: The EventDispatcher would see 2 aquires, 1 key load and 2
release events.
After: The EventDispatcher will see 1 acquire, 1 key load and 1 release.
PiperOrigin-RevId: 358804502
There are two different patterns we use at the moment:
1. Call both deprecated and non-deprecated method from call site with
no default method implementation body.
2. Use default method of non-deprecated method to call deprecated
method.
Pattern 1 is easier to reason about as it makes the calls more explicit,
so changing all usages of pattern 2 to pattern 1.
PiperOrigin-RevId: 358769803
This type is different to the selection reason, which is
dynamic (i.e., corresponds to the individual selected track,
which can change during playback). The static type is
exposed via TrackSelection, where-as the selection reason
will be internal to the core (i.e., player) module.
PiperOrigin-RevId: 357578201
It allows Bundleable classes throw a RuntimeException which is broader
than IAE. Now, Bundleable implementation may utilize checkNotNull for
brevity.
PiperOrigin-RevId: 357546375
It's used by the UI and mediasession modules. We may be able to move
it into the UI module if/when the mediasession module goes away.
PiperOrigin-RevId: 356734939
ControlDispatcher and DefaultControlDispatcher also need
to move to common for the UI module. As does PlaybackPreparer,
although that will be removed entirely in a future release.
PiperOrigin-RevId: 356467394
Also allow the player's prepared ad media period durations array to exceed the
length of the loaded ad URIs array, as it's possible for the player to buffer
an ad media period fully at the point where it's known that an ad is coming up
but its URI is still unknown.
#minor-release
PiperOrigin-RevId: 356249284
We currently block the loading thread until the calculated load
time has past and then unblock again by a message sent from the
playback thread. However, because the loading thread itself is not
using a Looper and runs freely, we don't control when the short
calculations on the loader thread that determine how long we have
to wait are happening, and we also don't control how long it takes
to start and stop this thread.
To solve these problems and to make the playback deterministic we
can
1. Send a message on the playback thread to block until the loader
thread has started.
2. Block the playback thread whenever a loading thread is doing its
short calculation of wait times. The playback thread knows when it
can continue because loading either enter a new waiting state for
a simulated load time or loading is finished completely.
3. Also wait on the playback thread until the loader has shut down.
As this is waiting for a message on the playback thread, we can
achieve this by sending messages to ourselves at the current time
until the loader is shut down.
All 3 steps together ensure that the loading thread interaction is
compeltely deterministic when simulating bandwidth profiles with the
BandwidthProfileDataSource. As we need to notify the source before and
after the load started/finished, we also need a small wrapper for the
chunk source when running the playback.
PiperOrigin-RevId: 355810408
- When throwing a recoverable error from a renderer, it's important to understand
exactly how the player will attempt recovery. Clarify the documentation to
make this explicit.
- Rename some methods/constants to make it clear that error recovery is specific
to renderer errors. The current recovery mechanism only makes sense for
renderer errors. Making the naming renderer specific avoids reader doubt that
the implementation doesn't appear to be generic enough for other types of
errors.
PiperOrigin-RevId: 355650945
It's for classes to clearly denote they support bundling and it gives
us a good place to document the best practice to implement fromBundle.
PiperOrigin-RevId: 355609942
Before, the level was set to null in this case.
MediaCodecUtil.getCodecProfileAndLevel() was therefore returning null
and the fallback to AVC/HEVC was not enabled in MediaCodecVideoRenderer.
Issue:#8530
#minor-release
PiperOrigin-RevId: 355574499
This also moves DefaultHttpDataSource to common, which seems
sensible, else non-player components that need a DataSource
don't have any useful concrete implementations. We should
think about moving some of the other concrete implementations
to common as well.
PiperOrigin-RevId: 354738925
This is achieved by only triggering one message at a time. After
triggering a message we send another to ourselves to know when the
following message can be triggered.
Other required changes:
- The messages need to be sorted correctly (by time and creation order)
- To prevent deadlocks when one thread is waiting for another,
we need to add new method to Clock to indicate that the current
thread is about to wait. This then allows us to trigger messages
from other threads in FakeClock.
- AnalyticsCollectorTest needed some adjustments:
- onTimelineChanged now deterministically arrives after the initial
timline is already known, so some of the period information changes
from window only to full period info.
- The playlistOperations test suffers from a bug that the first frame
is rendered too early and that's why we now get additional events.
PiperOrigin-RevId: 353877832
Currently only delayed messages are handled. Change this to handling
all messages so that we have more control over their execution order.
This requires adding a new wrapper type for the Message to support
the obtainMessage + sendToTarget use case.
PiperOrigin-RevId: 353876557
They only require common. This allows their use for non-playback networking
without requiring the user to depend on the whole of core. I will also make
the same change for Cronet, although this needs a little more work.
PiperOrigin-RevId: 353649388
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
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
- 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
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
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
- 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
*** 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
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
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
This will allow ExoPlayer to check if video track's profile
and level are supported by decoder when playing progressive media sources.
Also fix typo in AvcConfig.
