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
Also added comments for all existing devices for easier reference.
Issue:#3835
Issue:#3236
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=185661900
Also make ad group skipping more robust. After calling onError for an ad, IMA
will sometimes trigger an ad group load error, so this needs to be handled in a
way that allows some ads to be loaded already for the ad group.
This change also fixes calculation of the expected ad index to take into account
whether the position is being faked to trigger loading an ad or is the actual
player position.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=185655844
Releasing the player released the internal playback thread once renderers were
released. Releasing a MediaPeriod queued a Loader.ReleaseTask on the loading
thread which would post back to the playback thread. If the playback thread had
been quit by the time this happened, the release task wouldn't be run.
Release on the loading thread instead of the playback thread. This avoids
needing to block releasing the player until the loading threads have ended, and
ensures that release tasks will run eventually. As part of this change,
ExtractorMediaPeriod's call to Extractor.release will now run on the loading
thread (which means that all Extractor methods are called on that thread) and
other cleanup in ReleaseCallback will run on the loading thread instead of the
playback thread.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=185651320
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
Allow skipping an ad group when requested by IMA, even if we aren't currently
playing one, to handle cases where no ads in an ad group will load (so IMA
requests resuming content but we never managed to start playing an ad).
Use the known ad group index (rather than the expected one) when handling ad
group load errors. This ensures we skip the right ad group if we notify IMA of
playback errors for every ad in the ad group, then IMA notifies that the ad
group is empty via a load error.
Also make some other miscellaneous small fixes to ads code:
- Avoid warning about unexpected ad group indices more than once.
- Output a warning if the ad count in an ad group decreases.
- Remove unnecessary assertion.
- Fix getting the ad duration for ad indices that haven't loaded yet.
- Allow setting an ad group state to its current value.
- Fix javadoc for setting the ad resume position.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=184831495
The ad index in the ad group may need to skip over ads that failed to load, so
it can't just be incremented any more.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=184812556
This feature is supported in the ConcatenatingMediaSource and is easily copied to this
media source. Also adding tests to check whether the atomic property works in normal
concatenation and in also in nested use.
Also fixes a bug where timeline methods of the DeferredTimeline were not correctly
forwarded.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=184526881
This could happen when a media source is removed from a
DynamicConcatenatingMediaSource and one of its media periods is still active.
This media period is only removed by the player after the player received
a timeline update and thus we shouldn't release the removed child source
as long as it has active media periods.
Issue:#3796
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=184522836
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
DefaultExtractorInput.SCRATCH_SPACE buffer is used to skip data by
reading it into this buffer and discarding.
Simultaneous use of skip methods corrupts this buffer. Normally the
read data is discarded so it doesn't matter but the underlying
DataSource may use the buffer too. If it's a CacheDataSource it uses
this buffer to read data from upstream then write to cache.
Issue: #3762
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=184502170
This avoids reading a format that is not equal because of switching between
NO_VALUE and 0.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=184298076
This makes assertion errors in code running on the Looper less easy to miss.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=184294290
For below API level 16, the logic copied from ConnectivityManagerCompat.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=184131406
Helper class to create notifications for downloads using DownloadManager.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=183225948
Even if a developer synchronizes every method, thread safety is still not guaranteed
because the internal callback methods can't be synced from outside.
Issue:#3773
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=184122072
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
I think (?) they're harmless, but lint doesn't like them.
Using them within the class body means the TargetApi
annotation applies, which makes lint happy.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=184117951
In MediaCodecRenderer, we currently uses codec.getInput/OutputBuffers event
though these APIs are deprecated and are not recommended from API 21+. This
change makes sure that:
- On API 20 and below, we will keep using codec.getInput/OutputBuffers.
- On API 21+, we will use getInput/OutputBuffer(index) APIs instead.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=184112329
*** 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
This make sure all media sources can be reprepared after being released.
Issue:#3498
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=183990416
When the dynamic media source contains multiple empty timelines in a row and some
of them dynamically change to a non-empty timeline, the window and period indices
are not updated correctly because the index of the changed child source is wrong.
To fix this bug, the child index is added to the media period holder to have direct
access on the current child index to prevent ambiguity.
Furthermore, the uid is changed to be the hash code of the MediaSourceHolder not the
MediaSource itself to allow adding the same MediaSource twice without violating the
unique uid policy.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=183973462
Also fixes a bug where deferred media periods were kept in the list for
an unprepared media source although the media period was already released.
Issue:#3498
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=183800889
This enables caching manifest files for DASH, HLS and SmoothStreaming.
To disable caching a non cache DataSource should be provided for reading
manifest to the used MediaSource.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=183794252
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
1. When we try and load something via reflection and find the
class, always throw rather than failing silently if we
subsequently fail to instantiate an instance. This is
indicative of a broken proguard setup, and failing silently
makes it hard to spot.
2. Add library/core proguard configuration to ensure extension
renderer constructors that we access via reflection are kept.
3. Add demos/main proguard configuration to ensure ImaAdsLoader
constructor that we access via reflection is kept.
4. Added IMA proguard file to hopefully fix#3723, although I
wasn't actually able to reproduce the issue.
Issue: #3723
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=183648187
- Renderers becoming ready is asynchronous, so the change wasn't
well thought through :(.
- This will bring back the possibility of getting stuck in the
buffering-but-not-loading anything state. This will need to be
addressed in a future CL.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=183646837
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
MediaPeriodInfoSequence has functionality for determining what MediaPeriod
should be loaded next. Move this into the queue as an initial step towards
moving logic concerning updating the queue of media periods out of
ExoPlayerImplInternal.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=183391114
This removes some boiler-plate code for compostite sources and will also
simplify resuing media source in the future (because this class can keep track
of child listeners).
Issue:#3498
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=183387123
- This gives LoadControl enough information in shouldContinueLoading
to know whether returning false will result in a terminal non-playback
state.
- DefaultLoadControl will always return true when returning false will
result in a terminal non-playback state, unless the target buffer size
is exceeded. This can help to avoid getting stuck in the case that a
MediaPeriod is providing samples from an unexpected starting time.
- Make the terminal state actually terminal. Previously the player would
end up in an indefinite buffering state. We now fail with an error.
- Also remove the opportunity for LoadControl implementations to livelock
playback. No sane LoadControl should simultaneously tell the player that
it doesn't want to load anything and that it doesn't want to start
playback. So this change removes the opportunity and starts playback in
EPII instead in this case.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=183114797
Try to delay failure for as long as possible. That is, propagate
DRM session failures only after an encrypted buffer arrives or clear
sample playback without session is not allowed.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=183076348
setBytesRemaining() doesn't work when called after closeCurrentSource()
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182999254
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
Also disable use of dummy surface for devices that require the
workaround. It's only useful in the case that we can use
setOutputSurfaceWorkaround, so if it's disabled the dummy surface
has no purpose (it actually makes things worse by consuming past
the key-frame prior to the current position, which doesn't happen
if you have no surface at all).
Issue: #3724
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182750068
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
As soon as the seek gets acknowledged by EPII, EPI returns the actual position
from the playback info again which is set by EPII. Thus, EPII needs to update
the position to reflect the changes expected by EPI.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182515106
- In IDLE, the button will now call a preparer. This allows
removal of the separate retry button from the demo app.
- In ENDED, the button will seek back to the default position
and play.
- Behavior is made consistent with LeanbackPlayerAdapter.
Issue: #3689
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182506855
When determining the next sample to load, the Mp4Extractor now takes
into account how far one stream is reading ahead of the others.
If one stream is reading ahead more than a threshold (default: 10 seconds),
the extractor continues reading the other stream even though it needs
to reload the source at a new position.
GitHub:#3481
GitHub:#3214
GitHub:#3670
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182504396
It seems good to have EventLogger available from the library.
In particular because when app developers use it and then
submit bug reports, it makes it much easier to work out what
happened. It will also allow EventLogger to be used across
our (now multiple) demo apps.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182389407
This gets rid of the manual tracking of this queue with reading, playing,
and loading period holders. Still keeping these names for queue access methods.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182378944
This avoids issues that can arise due to slight discrepancies between
chunk start times (obtained from the manifest of segment index) and
the timestamps of the samples contained within those chunks.
Issue: #2882
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182054959
For live streaming, there are several types of DASH `emsg' events that directly
target the player. These events can signal whether the manifest is expired, or
the live streaming has ended, and should be handle directly within the player.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182034591
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
ChunkSampleStream.seekToUs assumes that if we can seek within the
primary sample queue, we can also seek within the embedded queues.
This assumption can be violated fairly easily if discardBuffer is
called with toKeyframe=true, since this can cause samples to be
discarded from the embedded queues within the period for which a
seek in the primary sample queue will succeed. This change fixes
the issue.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=181965902
These haven't been included in the recent changes but can be reported as
soon as the first sample of each stream is read.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=181753141
We added the other callbacks some time ago, but didn't include onLoadStarted.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=181743764
This it to distinguish between actual period transitions and the
transitions occuring to and from ads within one timeline period.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=181606023
Partial reads were performed once using a partial size of 1 byte.
This was not enough to detect problems which only occur in combination
with IOExceptions. Partial reads are now only applied when no exception
is thrown.
Moreover, the tests didn't check whether the total number of sampled bytes
is what it is supposed to be. Added a field to the data dumps checking
the total number of bytes in the sampled data.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=181296545
----------------------------------
Original change description:
DRM fixes
- Parse multiple kids from default_KID. It's specified as a whitespace
separated list of UUIDs rather than a single UUID.
- Opportunistically proceed with playback in cases where the manifest
only defines a single SchemeData with the common PSSH UUID. In such
cases the manifest isn't saying anything about which specific DRM
schemes it supports.
Issue: #3630
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=181137621
This lets apps fail-fast when they try to reuse media source instances.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=180934445
In certain conditions CacheDataSource switch to reading from upstream
without writing back to cache. This change makes it detect the change of
these conditions and switch to reading from or writing to cache.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=180901463
- Parse multiple kids from default_KID. It's specified as a whitespace
separated list of UUIDs rather than a single UUID.
- Opportunistically proceed with playback in cases where the manifest
only defines a single SchemeData with the common PSSH UUID. In such
cases the manifest isn't saying anything about which specific DRM
schemes it supports.
Issue: #3630
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=180675056
This removes the need to calculate the time needed to run the doSomeWork
method. Consequently, we can use both the real Clock/Handler and the
FakeClock without changing the way the playback loop works and without
violating the interfaces of Clock or Handler.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=180665647
Some readability fixes for PlayerMessage and the handling in
ExoPlayerImplInternal.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=180544294
Whilst the previous behavior was WAI and had the advantage of
updating the position to be more exact when known, there were
a couple of disadvantages:
1. If seeking to the very end of a period in a playlist when
paused, the position adjustment could trigger a position
discontinuity to the next period.
2. We de-duplicate seeks to the current playback position.
The position adjustment can prevent this from being
effective. This is particularly important with the new
SeekParameters support. When seeking to nearest sync point
it's often possible to de-duplicate seeks, but we cannot
do so if the playback position adjusts away from the sync
point's time.
Issue: #2439
Issue: #2882
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=180540736
This ensures message order if multiple custom messages running on the
playback thread and direct player commands are called immedately after
each other.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=179925852
This allows to inject a FakeClock for tests. Other playback components
(e.g. some media sources) still use SystemClock but they can be amended
in the future if needed.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=179921889
Especially this removes the need for the Clock interface to directly
implement Handler methods. Instead, we have a separate Handler interface
and the FakeClock is able to construct such a Handler.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=179918255
If ClippingMediaSource contains a child MediaSource with embedded metadata
stream, and the embedded stream is being used, it can lead to
ClippingMediaSource not be able to stop after the clipping end point. The
reason being the metadata stream cannot read anymore sample, but it's also not
end of source at that point. This CL fix this by changing the condition to
check if the child stream cannot read anymore sample and it has read past the
clipping end point.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=179918038
This adds options to ExoPlayer.sendMessages which allow to specify a window index
and position at which the message should be sent. Additionally, the options can be
configured to use a custom Handler for the messages and whether the message should
be repeated when playback reaches the same position again.
The internal player converts these window positions to period index and position
at the earliest possibility. The internal player also attempts to update these
when the source info is refreshed. A sorted list of pending posts is kept and the
player triggers these posts when the playback position moves over the specified
position.
Issue:#2189
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=179683841
*** Original change description ***
Add possiblity to send messages at playback position.
This adds options to ExoPlayer.sendMessages which allow to specify a window index
and position at which the message should be sent. Additionally, the options can be
configured to use a custom Handler for the messages and whether the message should
be repeated when playback reaches the same position again.
The internal player converts these window positions to period index and position
at the earliest possibility. The internal player also at...
***
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=179666357
This adds options to ExoPlayer.sendMessages which allow to specify a window index
and position at which the message should be sent. Additionally, the options can be
configured to use a custom Handler for the messages and whether the message should
be repeated when playback reaches the same position again.
The internal player converts these window positions to period index and position
at the earliest possibility. The internal player also attempts to update these
when the source info is refreshed. A sorted list of pending posts is kept and the
player triggers these posts when the playback position moves over the specified
position.
Issue:#2189
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=179563355
- Lint doesn't like a static import of something not available on
the minimum API level.
- The method linked to in the Javadoc was incorrect (wrong signature).
I couldn't really work out why it was there, so I got rid of it
rather than updating.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=179222587
This adds a parameter to configure a maximum buffer size in bytes. If left
at its default of C.LENGTH_UNSET, the target buffer is determined using a
overridable method based on the track selection. Also adding a parameter
to decide whether to prioritize time or size constraints.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=179048554
Also fix ClippingMediaSource to consider the start position an
artificial key-frame, and to properly offset the value returned
by getAdjustedSeekPositionUs.
Issue: #2882
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=179032243
Skipping short periods in a while loop is conceptually a new operation
and thus we need to send out the updated playback info in between for
the listeners to receive multiple period transition discontinuities.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=179027334
This is a no-op change replacing the local variables in ExoPlayerImplInternal
with the new ones in PlaybackInfo.
***
Use playbackState, isLoading and trackSelectorResult from playbackInfo in ExoPlayerImpl.
***
Move duplicated listener notification in ExoPlayerImpl to new method.
Also split reset method in one parts which creates the new playback info
and one part which notifies the listeners. The increment of the pending
operation counter needs to happen in between.
***
Use only one pending operation counter in ExoPlayerImpl.
This also allows to move onSeekProcessed into the notification chain.
***
Replace playback info changing messages to ExoPlayerImpl by single message type.
As they are all handled in the same way, they can be summarized to one message.
***
Only send playback info change notifications once per playback thread message.
This ensures that all concurrent changes actually reach ExoPlayerImpl concurrently.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=178907165
- Convert the Builder into a Factory
- Have it use MediaSourceEventListener
- Also made some misc related fixes to other sources
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=178906521
1. The player doesn't acknowledge phantom stops when an exception is thrown anymore.
2. It also makes sure it doesn't reset the pendingPrepareCount unless it's actually
immediately acknowledging these prepares.
3. It ensures a seek is acknowledged even though an exception is thrown during seeking.
Added tests (which previously failed) for all three cases.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=178876362
This is in preparation for supporting non-extractor MediaSources for ads in
AdsMediaSource.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=178377627
This should be a no-op change. And it eliminates the need to use the index variable
which will be removed once the MediaPeriodHolderQueue is implemented.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=177963360
In some occasions, we may want to discard a part of the buffered media to
improve playback quality. This CL adds this functionality by allowing the
loading media period to re-evaluate its buffer periodically (every 2s) and discard
chunks as it needs.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=177958910
This is a step towards harmonizing the MediaSource Builders and (potentially)
providing MediaSource factories.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=177783157
Waiting for the timeline change didn't work correctly because the timeline was
already equal to Timeline.EMPTY (due to the masking). Now waiting explicitly
for the empty Timeline exposed by the source.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=177749292
- Remove skipping of the VBRI/XING frame before calculating position
offsets. This was incorrect. Instead, a constraint is used to ensure
we don't return positions within these frames, the difference being
that the constraint adjusts only positions that would fall within
the frames, where-as the previous approach shifted positions through
the whole stream.
- Excluded last entry in the VBRI table because it has an invalid
position (the length of the stream).
- Give variables in XingSeeker descriptive names.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=177451295
The set of active audio processors was only updated on reconfiguration and when
draining playback parameters completed. Draining playback parameters are cleared
in reset(), so if parameters were set while paused then the sink was quickly
reset, without draining completing, the set of active audio processors wouldn't
be updated. This means that a switch to or from speed or pitch = 1 would not be
handled correctly if made while paused and followed by a seek.
Move resetting active audio processors from configure (where if the active audio
processors were reset we'd always initialize a new AudioTrack) to initialize().
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=177442098
- This change snaps the seek position for constant bitrate MP3s
to the nearest frame boundary, avoiding the need to skip one
byte at a time to re-synchronize (this may still happen if the
MP3 does not really have fixed size frames).
- Tweaked both ConstantBitrateSeeker and WavHeader to ensure the
returned positions are valid.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=177441798
Support ad MediaSources that aren't prepared immediately by using
DeferredMediaPeriod, moved up from DynamicConcatenatingMediaSource.
In a later change the new interfaces will be made public so that apps
can provide their own MediaSource factories.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=177424172
captions fetcher architecture.
1. ManifestlessCaptionsMetadata
Other captions fetchers must first fetch a manifest (HLS or manifest) to
discover captions tracks. This process does not exist for manifestless. All
we need to do is scan the FormatStream's for the right itag, so this is an
all-static class.
2. ManifestlessSubtitleWindowProvider
Once a captions track is selected, a subtitles provider is instantiated. This
is the main interface used by the player to retrieve captions according to
playback position. This class stores fetched captions in a tree index by time
for efficient lookups. Background captions fetches are used to populate
the tree.
3. ManifestlessCaptionsFetch
Captions are fetched one segment at a time. One instance of this object
is required per fetch. It performs a blocking fetch on call(), and is
intended to be submitted to a background-thread executor.
4. ManifestlessCaptionsFetch.CaptionSegment
This is the result of the caption fetch. These values are used to populate
the captions tree.
Manifestlessness
The initial request is always a headm request. There is a separate tree
of every segment indexed by start time. This tree is used to improve
manifestless sequence number calculation. Once we have data for the current
timestamp, we walk forward through the tree to find the next unfetched
sequence number, and fetch that.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=177385094
Currently FragmentedMp4Extractor only parses and outputs emsg messages if the
flag FLAG_ENABLE_EMSG_TRACK is set (when there's a metadata renderer that
handles emsg messages). Since there are emsg messages that only targets the
player, which we want to handle independently from MetadateRenderer, this CL
adds the ability for FragmentedMp4Extractor to output emsg messages to an
additional TrackOutput if provided, independently from FLAG_ENABLED_EMSG_TRACK.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=177318983
- Avoid re-downloading data prior to the first mdat box when
seeking back to the start of an unseekable FMP4.
- Avoid re-downloading data prior to the first frame for
constant bitrate MP3.
- Update SeekMap.getPosition documentation to allow a non-zero
position for the unseekable case. Note that XingSeeker was
already returning a non-zero position if unseekable.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=177317256
There are still things broken about the seeker, but this
cleans up some of the weird bits.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=177315136
Makes it less error-prone to accidentatly forget to set the right overwrites.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=177282089
This allows to keep the state synced with ExoPlayerImpl after stopping the player,
but still releases the media source immediately as it needs to be reprepared.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=177167980
We can acknoledge seeks before preparation finished immediately now,
because ExoPlayerImpl won't leave the masking state until the first prepare
operation is processed.
As a side effect, it also cleans up the responsibility of the callbacks.
Prepares are always acknowledged with a SOURCE_INFO_REFRESHED, while seeks
are always acknowledged with a SEEK_ACK.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=177144089
The ExoPlayerImpl implementation forwards the stop request with this optional
parameter. To ensure correct masking (e.g. when timeline updates arrive after
calling reset in ExoPlayerImpl but before resetInternal in
ExoPlayerImplInternal), we use the existing prepareAck counter and extend it
also count stop operations. For this to work, we also return the updated
empty timeline after finishing the reset.
The CastPlayer doesn't support the two reset options so far.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=177132107
Unconditionally waiting for the action schedule to finish in ExoPlayerTestRunner
doesn't work if the action schedule is not intended to be finished.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=177024139
Also slightly improve language normalization/documentation.
For this CL, it is assumed that null and "und" languages are different
entities. Once we fully tackle language tag normalization, we can decide
whether to normalize the "undefined" language.
Issue:#2867
Issue:#2980
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=177008509
Update the default AdaptiveTrackSelection and DefaultLoadControl to use playback
speed information.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=176989168
currentTimeMillis is not guaranteed to be monotonic and elapsedRealtime is
recommend for interval timing.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=176853118
Fixed by explicitly waiting for the timeline update. This shouldn't be
necessary and will be removed as soon as the correct order of events
can be guaranteed (timeline change -> state change -> onSeekProcessed).
The waiting for the timeline update is implemented by introducing the
feature that the test runner also waits until the action schedule has
finished before stopping the test.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=176848540
This is mostly useful for suppressing the initial position
discontinuity reported by ClippingMediaPeriod.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=176758972
