The dokka javadoc generation tool complains when parameter names don't match between a method and its override. This change updates occurrences where there is currently a mismatch.
Notable renamings that might be controversial:
- `onPlaybackStateChanged(int state)` to `onPlaybackStateChanged(int playbackState)` affected a lot of lines but seems more consistent with other '-Changed' methods.
- `handleMessage(int messageType, Object payload)` to `handleMessage(int messageType, Object message)`
- `ExtractorInput` and `DataSource` inherit `DataReader` which had `read(byte[] target, ...`, while data sources normally called the first parameter `buffer`. I have standardized these all to use `buffer` even though it looks out of place in the `ExtractorInput` interface (which has more `read` methods with `target`).
PiperOrigin-RevId: 387290360
The types (open/close/read) does not provide extra information about the thrown
playback exception, and they are not utilized at higher levels.
PiperOrigin-RevId: 384219870
- Use `PlaybackException.ErrorCode` IntDef for `DataSourceException` error code
- Deprecate `DataSourceException.POSITION_OUT_OF_RANGE`
- All other changes are related to replacing the deprecated constant and
constructor
PiperOrigin-RevId: 382683522
A no-op change that changes the signature of the onChunkLoadError method of the ChunkSource. Implementors can get the exclusion duration directly from the LoadErrorHndlingPolicy instead of receiving it as an argument of the callback.
PiperOrigin-RevId: 381102935
This softens the language around suppressing individual test methods.
There are some legitimate cases where this is needed, e.g.
ByteArrayDataSourceContractTest has to suppress all the tests related
to non-existent resources because it's not possible to simulate that
case.
#minor-release
PiperOrigin-RevId: 380570017
* Constructors and methods with the same name should appear sequentially with no other code in between, even when modifiers such as static or private differ between the methods. Please re-order or re-name methods.
(see http://go/bugpattern/UngroupedOverloads) (2 times)
This CL looks good? Just LGTM and Approve it!
This CL doesn’t look good? This is what you can do:
* Suggest a fix on the CL (go/how-to-suggest-fix).
* Revert this CL, by replying "REVERT: <provide reason>"
* File a bug under go/error-prone-bug for category ErrorProneStyle if the change looks generally problematic.
* Revert this CL and not get a CL that cleans up these paths in the future by
replying "BLOCKLIST: <provide reason>". This is not reversible! We recommend to
opt out the respective paths in your CL Robot configuration instead:
go/clrobot-opt-out.
This CL was generated by CL Robot - a tool that cleans up code findings
(go/clrobot). The affected code paths have been enabled for CL Robot in //depot/google3/java/com/google/android/libraries/media/METADATA which is reachable following include_presubmits from //depot/google3/third_party/java_src/android_libs/media/METADATA.
Anything wrong with the signup? File a bug at go/clrobot-bug.
#codehealth
PiperOrigin-RevId: 380544425
Also change to explicitly track the provisioning session, which makes
the code easier to reason about than always using the zero'th element
of the list.
PiperOrigin-RevId: 380181453
Add the `needsReconfiguration` API on the `MediaCodecAdapter` interface so that `MediaCodecRenderer` can reconfigure the `MediaCodec` in case a `MediaCodecAdapter` needs to be reconfigured immediately after being obtained from the `MediaCodecAdapter.Factory`.
PiperOrigin-RevId: 376944334
This change introduces a third 'state' for `DefaultDrmSessionManager`:
It's been fully released (prepareCount == 0) but at least one of its
sessions is still active.
In this state new acquisitions are rejected (`(pre)acquireSession()`
calls will fail) but the machinery to support the existing sessions
(ExoMediaDrm and MediaDrmHandler) is kept until they're all released.
This change will allow us to remove the TODO in MediaCodecRenderer
that resolves Issue: #8842.
PiperOrigin-RevId: 376193952
In a follow-up change I will add an additional test to ensure these
events continue to be correctly handled when DefaultDrmSessionManager
has prepareCount==0 but a non-null ExoMediaDrm instance.
PiperOrigin-RevId: 376190225
Also make future similar issues less likely by adding isPlaceholder
to the set method of Period (in case forwarding Timeline
implementations use this instead of just updating values selectively)
#minor-release
PiperOrigin-RevId: 372138523
Move VideoSize in the common module and have the Player return it.
`Listener` and `AnalyticsListener` `onVideoSizeChanged` are updated
with the old method deprecated.
`VideoRendererEventListener.onVideoSizeChanged` was also migrated to
`VideoSize` but the old method is removed, not deprecated.
This is because:
- apps calling/listening to this method is a rare and niche use-case.
- it would introduce hard to diagnostic issues where if only the caller
or the callee is updated to use the new method, the event will be lost.
This doesn't occur with the other 2 listeners as the caller is always
in ExoPlayer library and was updated to call both the old and new methods.
VideoSize is used everywhere except in `Format` as this would lead to
too much refactoring and backward compatibility breakage for little gain.
#minor-release
PiperOrigin-RevId: 371087419
Add method getAvailableCommands() in Player interface to return
the available commands. Method isCommandAvailable() moved to
BasePlayer since it can be implelented by calling
getAvailableCommands().
PiperOrigin-RevId: 370059328
A subsequent change will make the UI module access
SphericalGLSurfaceView and VideoDecoderGLSurfaceView
using reflection, now we're at the point where we only
need to reflect the constructors.
PiperOrigin-RevId: 369630102
The original cl has been fixed by not implementing
VideoListener but Player.Listener in
StyledPlayerView.
VideoFrameMetadataListener and CameraMotionListener are still part
of the Player interface as a good way to break the UI dependency
on them has not yet been finalised.
PiperOrigin-RevId: 369417682
This change moves the responsibility of creating, configuring and starting the MediaCodec from the MediaCodecRender to the MediaCodecAdapter.Factory.
This move allows ExoPlayer's client to decide how and when codecs are created and/or reused.
To allow the move, this CL replaces MediaCodecRenderer.ConfigureCodec with MediaCodecRenderer.getCodecConfiguration
PiperOrigin-RevId: 369273887
*** Original commit ***
Move VideoComponent in ExoPlayer
VideoFrameMetadataListener and CameraMotionListener are still part
of the Player interface as a good way to break the UI dependency
on them has not yet been finalised.
***
PiperOrigin-RevId: 369194309
VideoFrameMetadataListener and CameraMotionListener are still part
of the Player interface as a good way to break the UI dependency
on them has not yet been finalised.
PiperOrigin-RevId: 368863829
Previously, we had separate MSG_SET_SURFACE and
MSG_SET_VIDEO_DECODER_OUTPUT_BUFFER_RENDERER messages for
setting different types of supported output. Use of these
constants to switch between outputs during use of a player
was confusing because not all video renderers support both
message types.
To switch from VideoDecoderOutputBufferRenderer to a Surface,
it was sufficient just to send MSG_SET_SURFACE, since all
video renderers support this and clear any other output that
might be set. Conversely, to switch in the opposite direction,
just sending a MSG_SET_VIDEO_DECODER_OUTPUT_BUFFER_RENDERER was
not sufficient, because not all video renderers handle this
message to clear any previous output. Hence it was necessary to
explicitly clear a previously set surface using a separate
MSG_SET_SURFACE message. Passing two messages to switch the
output may prevent renderers from implementing the output switch
efficiently.
This change passes all outputs using a single message type, and
requires that all renderers treat unsupported outputs as though
null were passed (i.e., they clear any existing output). There
are some other miscellaneous improvements:
1. Non-surface outputs are now passed to onRenderedFirstFrame.
This fixes a bug in SimpleExoPlayer's onRenderedFirstFrame,
where previously it could not correctly equality check the
output corresponding to the event to its current output in
the VideoDecoderOutputBufferRenderer case.
2. Fix SimpleExoPlayer to report surface size changes for the
VideoDecoderOutputBufferRenderer case. Even though the
surface is rendered to indirectly in this case, we can still
query (and listen to changes to) the surface's size.
PiperOrigin-RevId: 368215850
Prior to this change, there were some unrealistic quirks in
our Robolectric tests. For example, onRenderedFirstFrame would
be called when using FakeVideoRenderer, despite no output to
render the frame to ever being set. This change improves the
realism of these tests. These changes are required for some
improvements being made to how outputs are set on video
renderers.
PiperOrigin-RevId: 367652169
We added a source that allows mixed placeholder and non-placeholder
periods, but have no way to denote that in the Timeline because the
placeholder flag only exists on Window level. This causes a bug if
the first item in a concatenation has a window-period offset and the
player can't detect whether it's still a placeholder or not.
Adding this flag to Period allows the player to detect this reliably.
In addition we need to make sure that re-resolving pending positions
only happens for the first placeholder period where the window-offset
can actually change. As all subsequent periods have to start at position
0, so they don't need to be re-resolved (and shouldn't).
PiperOrigin-RevId: 367171518
The BasePlayer implementation of add/remove
Listener knows about Components.
As those are removed from the Player
interface, the implementation of those
methods needs to be moved down in Player
implementations.
This commit makes no functional change.
PiperOrigin-RevId: 364985291
All Player methods should throw
NotSupportedException.
Making it abstract prevents the compiler catching
non implemented methods.
PiperOrigin-RevId: 364974387
Null was an alias for DEFAULT. Remove this for nullness
safety in the API.
The ExoPlayer implementation still checks for null and
replaces it by DEFAULT, so this is ABI compatible.
PiperOrigin-RevId: 364370017
- Update the three `HttpDataSource` implementations to use the
Content-Range response header to determine when this is the
case. The Content-Range header is included when the status
code is 416. See [here](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/416).
- Update `ByteArrayDataSource` to conform to the requirement.
- Update `DataSourceContractTest` to enforce the requirement.
PiperOrigin-RevId: 363642114
- 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
Assert that opening the DataSource at the end of the resource
results in only RESULT_END_OF_INPUT being read.
open() and read() are still permitted to throw, although this
permissiveness will be removed in subsequent commits.
PiperOrigin-RevId: 362905314
TransferListener has the contract to have exactly one onTransferEnd per
onTransferStart, so the test can both assert that onTransferInitializing
is called, but not onTransferEnd (even after calling close).
PiperOrigin-RevId: 362262078
MaskingMediaSource needs to resolve the prepare position set for a MaskingPeriod
while the source was still unprepared to the first actual prepare position.
It currently assumes that the period-window offset and the default position is
zero. This assumption is correct when a PlaceholderTimeline is used, but it
may not be true if the real timeline is already known (e.g. when re-preparing
a live stream after a playback error).
Fix this by using the known timeline at the time of the preparation.
Also:
- Update a test that should have caught this to use lazy re-preparation.
- Change the demo app code to use the recommended way to restart playback
after a BehindLiveWindowException.
Issue: #8675
PiperOrigin-RevId: 361604191
- Split text emphasis mark and style into two IntDefs
- Represent textEmphasis="none" with a span rather than null
- Fixed bugs in the style parsing logic
- Refactor TextEmphasis class to support different ordering of styles
- Merge RubySpan.Position and TextEmphasisSpan.Position
- Remove TTML constructs from Spanned classes
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
Given we're proposing to make reading from the end a non-error case,
it's important to check that we return the right thing from open(),
and that we read the right thing (i.e., nothing) once opened.
For now, this test allows quite a bit of permissiveness, in line
with other related tests. This will be tightened up in due course.
PiperOrigin-RevId: 359504075
Currently, this only asserts that *if* an exception is thrown, it
must be a position-out-of-range exception as determined by
DataSourceException.isCausedByPositionOutOfRange.
Issue: #7326
PiperOrigin-RevId: 359092124
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
- If DataSource.close fails then it's unknown whether the underlying file was
written to the cache. We should assume that it has not been.
- Always re-query cachedBytes at the start of CacheWriter.cache, since its
current value may be incorrect if a previous failure was the result of a
file not being written to the cache.
PiperOrigin-RevId: 359039109
- Make it a property of the DataSource, not of the resource.
- Apply it only when a contract test reads using an
unbounded DataSpec.
PiperOrigin-RevId: 358997735
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
This parameterized test execute a single playback with a variety of
specified network conditions, user country and network types, and then
compares some basic ABR performance data against a dump file to detect
changes.
PiperOrigin-RevId: 356468304
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
Main improvement is to switch away from ExoPlayerTestRunner and to
split out the waiting component so that the same class can be used
from Robolectric tests in the future.
The only functional difference is that that BufferLengthLogAction
is removed completely because the data isn't used downstream and the
method of collecting this data is a bit arbitrary.
PiperOrigin-RevId: 355117850
This can happen for instrumented tests that are run on a non-Looper
thread. If these tests send a message to a Looper thread to start the
test procedure, they should just triger the message directly as before.
PiperOrigin-RevId: 354066836
- The order of sample stream (and thus the order in which loads are
triggered) currently depends on a Set and thus on the hash codes
of the objects that change with every run. Changing to a List solves
this problem.
- The FakeAdaptiveDataSet directly created a static Random (with random
seed) to compute the variation of chunk sizes. Changing this to an
injected Random object that can always be initialized with the same
seed also removed this randomness from the tests.
PiperOrigin-RevId: 353878661
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
We currently only remove messages that have already been sent
to the actual Handler, not the pending ones that are only kept
in the FakeClock. Fix this by also removing matching messages
from the FakeClock list.
PiperOrigin-RevId: 353877049
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
`TrackSelection` had mutation methods which were to be called only
internally by ExoPlayer components but were exposed in the
public `Player` interface.
The mutation methods have been moved out of `TrackSelection`
to a new class `ExoTrackSelection`.
Current track related read-only method have also been moved out,
because they are actually something quite unclear.
Even for a single item playlist, it's the track being buffered rather
than the track being played, which is unclear.
But when you have a playlist it starts to get really confusing,
because if the next item is being buffered, then it's actually
the last track to be buffered in the currently playing item.
As a final aside, the implementations don't do proper thread synchronization
to ensure visibility of updated state by the calling thread.
Exposing those mutable methods in the public `Player` interface
was problematic because they leaking internal concepts of `ExoPlayer`.
This is also required to minimize the `Player` interface for long term
stability.
`ExoTrackSelection` is a subclass of `TrackSelection`.
This is not ideal as an `TrackSelection` implementation could
break the current immutability.
This was done in order for this refactor to be simpler.
A future patch will fully split the two classes.
All `MediaPeriod` and `Sources` had to be updated to use the new
`TrackSelection` dynamic aspect class name.
An alternative would have been to break ExoPlayer's public API, keeping
`TrackSelection` as the dynamic aspect name, and calling the public static
aspect class `TrackSelectionState` or similar.
Nevertheless, while it would have impacted less files, it would have
many more small apps and casual users of ExoPlayer.
#player-to-common
PiperOrigin-RevId: 353637924
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
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
- 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
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
The length needs to change depending on the positition/length parameters
passed to DataSpec, so it doesn't really make sense to keep this private
method - it's clearer to in-line the calls in each test.
PiperOrigin-RevId: 348749254
This replaces all the duplicated logic previously implemented in
FakeSampleStream and more closely follows the pattern of how
SampleStreams are used from real MediaPeriods.
Some tests needed adjustments because using real the SampleQueue
improved behaviour:
- Waiting for isLoading is only needed once even across period
boundaries because the real SampleQueue doesn't have the on/off
pattern.
- AnalyticsCollectorTest.playlistOperations() was wrongly asserting
that some pre-buffering events. The new version is more intuitively
correct we pre-buffer the second item during the initial loading
phase (thus period1seq1) and keep the buffer in the queue after
the removal operation.
PiperOrigin-RevId: 348440255
I decided not to migrate all the tests in one CL to keep the diff
manageable. I'll make follow-up CLs to migrate the tests, and eventually
delete TeeCodec and all associated logic.
I couldn't completely remove the dump diff because
ShadowMediaCodec.getCodecInfo() (which would give me access to the MIME
type) doesn't seem to work properly - it returned video/avc when
name=exotest.audio.aac, and looking into the code it looks like there's
some native methods that are missing shadow implementations.
PiperOrigin-RevId: 347991956
The adaptive period currently extends the base (non-adaptive) period
to share common MediaPeriod boilerplate code.
However, once we start using the real SampleQueue in FakeMediaPeriod
the common code becomes even less and the overhead to support
multiple stream implementation from the base class is no longer
worth it. Thus, this change removes the class hierarchy and copies
the common parts to FakeAdaptiveMediaPeriod.
PiperOrigin-RevId: 347990468
Before this we added the resource info to Truth assertions, but the
same info is missing if an exception bubbles out of the SUT.
PiperOrigin-RevId: 346757960
Changes MetadataRetriever and Transformer so that their
respective tests don't need to manually control the SystemClock
in order to execute taks posted with delay from Loader.
PiperOrigin-RevId: 345024140
The workaround to post a message was needed to ensure we
receive any final onIsPlayingChanged event before the test
is finished (to record the correct playing time).
Using onEvents allows us to do this synchronously as the
callback guarantees that there is no other pending event.
#exofixit
PiperOrigin-RevId: 344436180
In many cases it doesn't matter for the test itself how many windows
a timeline has, or even how the timeline of a MediaSource looks like.
And since we introduced the MediaItem-based APIs, single-window
Timelines are the only fully supported Timelines. Thus there is no
point in specifiying this explicitly.
Using these assumptions, we can remove some boilerplate when setting
up standard FakeTimelines or FakeMediaSources with a standard
FakeTimeline.
#exofixit
PiperOrigin-RevId: 344210395
This only has a couple of simple tests for now. We'll add more tests
after we've written some concrete sub-class tests for various
DataSource implementations.
I've included a concrete FileDataSourceContractTest as a demonstration.
PiperOrigin-RevId: 342851187
This information is already available in the MappingTrackSelector,
but not currently forwarded to the TrackSelection.Factory.
This makes it more complicated (or impossible) to depend on period
or manifest information in the track selection (for example to only
select tracks which are cached for the current format).
PiperOrigin-RevId: 340605886
ExoHostedTest was calculating the total play time by solely listening
to onIsPlayingChanged. The last update to false (when playback ends) was relying
on a callback that was always called after the player has already been released.
This happened because of a now fixed bug where callbacks were still issued if
player.release() is called from within another callback (as in ExoHostedTest).
Fix the currently broken test by posting the release call so that all pending
events are still delivered first.
PiperOrigin-RevId: 339438863
This moves TestUtil#runMainLooperUntil and
TestUtil#createRobolectricConditionVariable to a new RobolectricUtil
class.
Also move testutil classes that use Robolectric-related utils classes
(e.g. TestPlayerRunHelper, TestDownloadManagerListener).
PiperOrigin-RevId: 336864959
TestExoPlayerBuilder can be used from both emulator and robolectric
tests, TestPlayerRunHelper uses Robolectric Looper behaviour, meaning
it can be moved to the robolectricutils module in a follow-up change.
PiperOrigin-RevId: 336634225
Otherwise, some extractor tests are seeking without making sure that the
extractor has retrieved the formats.
This is needed for PR Issue: #7378.
PiperOrigin-RevId: 335934326
