Use PixelCopy API for the first SurfaceCapturer implementation. This supports
devices from API 24+.
Github: #3609.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=197732711
A new playback nonce is created for each playback of the same item. Thus we
need to inject the nonce dynamically into the data source factory.
This CL adds the DataSource which does the actual insertion into the request
URLs and a MediaSource which listens to new media periods, to request the
nonce and to configure the data source factory for this media period to use
this nonce.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=197134217
Currently, ExoPlayer only supports seeking for FLAC files with a SEEKTABLE.
This CL adds support seeking for cases when the FLAC files do not have a
SEEKTABLE by searching for individual frames within the file using binary
search.
Github: #1088.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=196816398
- This is needed to make DefaultTrackSelector properly thread
safe, and enable atomic changes to the selector that, for
example, disable a renderer and enable another one at the same
time.
- This change also saves/restores parameters and the start
position in PlayerActivity, resolving the ref'd issue.
Issue: #3915
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=193913350
*** Reason for rollback ***
Added the missing initialization to Timeline.EMPTY.
*** Original change description ***
Automated g4 rollback of changelist 192742299.
*** Reason for rollback ***
Culprit for b/78018932.
*** Original change description ***
Auto-register analytics collector in SimpleExoPlayer.
This automatically registers and deregisters an analytics collector in
SimpleExoPlayer. Doing this also allows to write integration tests checking
whether the reported window indices and media period ids are correct.
***
***
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=193006701
*** Reason for rollback ***
Culprit for b/78018932.
*** Original change description ***
Auto-register analytics collector in SimpleExoPlayer.
This automatically registers and deregisters an analytics collector in
SimpleExoPlayer. Doing this also allows to write integration tests checking
whether the reported window indices and media period ids are correct.
***
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=192816182
This automatically registers and deregisters an analytics collector in
SimpleExoPlayer. Doing this also allows to write integration tests checking
whether the reported window indices and media period ids are correct.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=192742299
These don't seem to be needed anymore. All tests run without them in gradle
and Blaze.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=191867518
This field (formerly "id") is almost impossible to use so far. Having setters
in the factories allows to specify custom tags for all media sources.
Also added a ExoPlayer.getCurrentTag() method to retrieve the tag of the
currently playing media source in a convenient way.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=191738754
In some situations, the timeline can't be specified because it is created
internally by the media source under test. If the test still needs to wait for
a timeline update, this change allows to do that by specifying an expected
timeline of null.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=190768386
Currently, MediaPeriod states that continueLoading may be called
during preparation. Some implementations would throw an error if
this happened.
Also make MediaPeriod documentation clearer.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=190596870
This will allow SimpleExoPlayer to auto-register its own listener before the
drm session manager is used to set-up the renderers.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=190478174
This adds callbacks for creating, releasing, and starting to read from media
periods.
Such events allow listeners to keep a list of active media periods. This is
useful to determine when no further events for a certain media period are
expected. It also allows listeners to associate renderer events unambigiously
with a reading media period.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=190462717
This gives the MediaSourceEventListener API a consistent look when new methods are
added which only have a window index and media period id.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=190450270
This allows to test sending events when using fake media sources.
The FakeMediaSource now simulates a manifest load when being prepared.
And the FakeMediaPeriod simulates a media load when being prepared.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=189205285
This allows to distinguish between media source events of multi-window and
multi-period media sources. In this change, only media sources currently reporting
events are changed. Proper support in composite sources will be added in a later
change.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=188847366
This is achieved by moving the listener registration and the creation of the
event dispatcher into BaseMediaSource.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=188461932
The start position was set to the old start position instead of the current
playback position. We need to set the start position to the current playback
position to ensure a repreperation with the same media starts from the last
playback position.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=188025439
- Change 'compile' configuration (deprecared) to using 'implementation'
and 'api' configurations instead.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=187311778
This is achieved by adding a BaseMediaSource which keeps a reference count of the
number of times the source has been prepared and forwards to the actual implementations
only once, such that only minimal changes are needed for each media source.
Issue:#3498
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=187186691
All media periods are part of a queue of windows buffered and played by
ExoPlayer. When repeating windows, the current MediaPeriodId is insufficient
to distinguish between the repetitions of the same period. This makes it hard
to see to which media period load events belong to, and it is also difficult to
determine whether two media periods belong to the same logical window or
whether they are part of different repetitions of the same window.
Therefore this change adds a unique sequence number to each window in the
sequence of windows and this sequence number is saved as part of the
MediaPeriodId.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=185829509
There are 4 tests which can't currently be moved:
- DownloadManagerTest explicitly uses the main looper which isn't easily
supported because the test runs on this thread.
- ContentDataSourceTest uses an AssetFileDescriptor which wraps a
ParcelFileDescriptor. It seems Robolectric doesn't correctly forward the
inner wrapped file descriptor leading to NPE.
- CacheContentIndexTest and SimpleCacheSpanTest both work fine with Gradle
but fail with seemingly valid test failures on Blaze.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=185366678
If the period uid doesn't match, the update procedure currently doesn't
remove the correct periods. This may cause the player to get stuck or to play
the wrong periods.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=185129503
Resolve the media period for ad playback when resolving a subsequent period and
when receiving a timeline where the playing period in range (but wasn't before).
Fix the seek position calculation when a current ad must be skipped and is
followed by another ad.
Check MediaPeriodInfos match when checking MediaPeriodHolders, to handle cases
where a future ad should no longer be played. This may involve playing two
content media periods consecutively.
Issue: #3584
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=184514558
1. Add string for STATE_CANCELED. Lint doesn't like that the
switch statement on the state IntDef doesn't have a case
for STATE_CANCELED. May as well add one, even if we're not
planning on our demo app showing notifications for this
state.
2. Replace non-human-readable error message with one provided
by ErrorMessageProvider.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=184120892
Note this case is special in that JUnit is an actual
compile dependency, as opposed to a testCompile or
androidTestCompile dependency.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=184119235
*** Reason for rollback ***
Broke everything
*** Original change description ***
Clean up message naming in EPII
***
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=184061352
In startReadWrite*() methods a new CachedContent is created if the there
isn't one already for the given key. If the span is release without
writing any content, this fix removes the added CachedContent.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=183666821
Before this change, the ad playback state stored the number of played ads in
each ad group. There was no way to represent that an ad had failed to load (and
it wouldn't be possible just to increment the played ad count to signal a load
error because there might be an unplayed ad before the ad that failed to load).
Represent the state of each ad (unavailable, available, skipped, played, error)
in each ad group. In a later change the player will use this information to
update its loaded MediaPeriods in response to future ads failing to load.
Also make the AdPlaybackState immutable and remove copying/duplication of its
fields in the ad timeline and period.
Issue: #3584
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=183655308
100ms is unrealistically short and, for example, causes the player to buffer
many periods ahead when looping.
Previously this was not feasible, because ExoPlayerTest as instrumentation test
actually needed to wait for the realtime playback duration.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=183646772
It's really spammy. Decided not to document tag as also
being nullable in case we ever use it for anything else
in the base action class.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=183632944
So far this wasn't possible because Robolectric's Looper and MessageQueue
implementations have multiple shortcomings:
1. The message loop of new HandlerThreads is an not an actual loop and
scheduled messages are executed on the thread the message is enqueued
(not the handler thread).
2. The scheduler used to replace the message queue is synchronizing all its
methods. Thus, when a test attempts to add messages to a Handler from
two different threads, it may easily run into a deadlock.
3. The scheduler doesn't correctly emulate the order of messages as they
would be in an actual MessageQueue:
a. If the message is enqueued on the handler thread, it gets executed
immediately (and not after all other messages at the same time).
b. The list of messages is always re-sorted by time, meaning that the
order of execution for messages at the same time is indeterminate.
4. Robolectric's SystemClock implementation returns the current scheduler
time of the main UI thread. So, unless this scheduler is used to add
messages in the future, the SystemClock time never advances.
This CL adds two helper classes which extend and replace Robolectric's
ShadowLooper and ShadowMessageQueue.
1. We intercept messages being enqueued or deleted in the message queue.
Thus Robolectric's faulty scheduler gets never used. Instead, we keep
a blocking priority queue of messages, sorted first by execution time
and then by FIFO order to correctly emulate the real MessageQueue.
2. We also keep a list of deleted messages to know which messages to ignore
when they come up in the looper.
3. When a new Looper is started, we override the dummy loop to an actual
eternal while loop which waits for new messages, checks if they haven't
been deleted, and runs the messages (similar to what Robolectric's
MessageQueue would have done at this point).
Because we don't actually use the main UI thread in our tests, we can't rely
on the SystemClock to progress in any sensible manner. To overcome this issue,
we can use the auto-advancing FakeClock also used for the simulation tests.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182912510
This achieves two things:
1. All our tests use the same type of assertions.
2. The tests currently run as instrumentation test can be moved to
Robolectric without changing the assertions.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182910542
These were caused by two issues:
1. The FakeMediaSource can be updated with a new timeline. The setNewSourceInfo
is called from a different thread than prepareSource and both access local
variables without synchronization.
2. For multi-window playback, the FakeRenderer claims that isReady and isEnded
are both set to false if it read the end of the stream. However isReady should be
true because it is able to "render" its data until the end of the stream.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182785169
This fixes a very specific case where the data read has non-cached gaps
and a read-only CDS switches to read from upstream in a gap then the
cached data is deleted. When the CDS reaches the end of the gap, it
tries to open the next source. As there is no cached data, it tries to
continue with the already opened upstream data source but as it reached
end of the gap range, the code starts looping.
Also fixes infinite lock which occurs when in the previous case CDS isn't
readonly. It locks the content while filling the gap in the cache. At the
end of the gap, as the following data is deleted it tries to lock the
content for writing but the content is already locked by itself.
The last fix is preventing removal of CachedContent entry from
CachedContentIndex while associated key is locked.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182595426
Some tests in ExoPlayerTest issue commands to the player from the test thread
while the player is actively playing media (playWhenReady=true). Due to the
indeterminate time taken to enqueue the commands on the playback thread, they
may arrive when the player already proceeded to another window or finished
playback.
To ensure the tests are always deterministic, this change pauses playback in
the tests where this may happen before issuing the commands.
Also, for tests where we need to wait for a new window before issuing the
next command, a new action is added which allows to play until a specified
position.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182535096
This allows listeners to get notified of any change to the embedded tracks.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=181969023
