The value is increased to 50 seconds. With that the player can better handle
short network problems. This does NOT increase the maximum memory used as we
still apply the seperate DEFAULT_TARGET_BUFFER_BYTES.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=188335603
When creating a new AC-3 passthrough AudioTrack the position
may advance from an old AudioTrack's position. The workaround
checked for the playback head position returning to zero, but
a subsequent change meant that we'd always start writing data
to the new track immediately (rather than waiting for its
position to 'stabilize' at zero).
Fix the issue by using the AudioTrack position directly. (Nb.
this doesn't handle the case of the stale position before
unwrapping being zero, but it is very unlikely to occur.)
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=188319795
Also simplified shouldContinueLoading condition code and added a builder for DefaultLoadControl.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=188306213
This allows to know the duration immediately and fixes the temporary unknown
duration in the UI when repreparing the same extractor media source.
The isSeekable property is still reset to false as we can't actually seek
until the seek map has been reloaded.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=188145860
Also remove logic for tracking the next output buffer in LibvpxVideoRenderer, as
this allowed many consecutive frames to be rendered that were actually late
after dropping to keyframe. It looks better to show frames at a consistent
100 ms rate.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=188144739
The playback state in ExoPlayerImpl and ExoPlayerImplInternal is usually kept
in sync. Only the timeline was so far not updated in the same way with the
internal player using a null timeline while ExoPlayerImpl keeps the previous
timeline.
This change removes the need to keep a null timeline which allows to update
the internal timeline in the same way as the external one. This fixes problems
when retrying a failed playback multiple times.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=188034988
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
Previously, child source ids were reassigned when the media source is reused.
Now the creation of the ids moved to outer level to stay in sync with the list
of child media sources.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=188014739
This restores functionality that was lost when we added
support for general timed message delivery.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=187866807
This value can now be set in the DefaultBandwidthMeter instead. As a result
NO_VALUE can be removed from BandwidthMeter as we now always provide an
estimate.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=187865341
This simplifies clearing a playlist without having to call removeMediaSource
repeatedly. It will also update the timeline only once.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=187863857
There is a large number of repeated arguments in the callback methods of
MediaSourceEventListener. Grouping them into load related data and media
related data allows to significantly reduce the amount of boiler plate code
and also simplifies future extensions of either set of data.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=187857252
This value is logically part of the bandwidth estimation and will eventually be
moved there from the adaptive track selection.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=187597038
1. Allow retaining a decoder without any reconfiguration, in addition
to retaining with reconfiguration (and not retaining)
2. Fix retention logic for video decoders to take into account changing
ColorInfo
3. Allow retention of audio decoders when possible
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=187500285
- Change 'compile' configuration (deprecared) to using 'implementation'
and 'api' configurations instead.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=187311778
The non-dynamic media source has a strict subset of features of the dynamic one and
thus can be replaced.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=187299432
Without child sources, the timeline can't possibly updated again within the
current looper message. Thus, we can send the empty timeline immediately.
This fixes a recently introduced flakiness in the test.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=187295700
ClippingMediaSource provides a timeline where the period and window have the
same start/end positions, so when clipping a child timeline with a non-zero
offset between the window and period it is necessary to clear the offset then
apply the offset to the start/end positions used in the ClippingMediaPeriod.
Also add a message to clipping exceptions.
Also fix adjustment of seeks to the start of the clipped view.
Issue: #3888
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=187292506
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
Up to now we use a boolean "preventListenerNotification" to suppress updates
while other operations are still in progress. This ensures, for example, that
only one initial timeline is issued even for multiple child sources.
As soon as we allow to reuse the same instance, it becomes increasingly difficult
to manage this manual listener notification suppression. Therefore, this change
schedules an update as a new message on the playback thread immediately after the
current message. This way, we also ensure that all simultaneous updates within one
looper message iteration are reported together.
Issue:#3498
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=187180342
The util package is, in practice, for things that are misc enough
to not warrant their own package. If something is deserving of a
package, it's IMO best placed somewhere else (I know you could
argue it's a util, but you could argue that about almost anything
else as well).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=187010018
Allow the position to jump on receiving the first presentable input buffer,
if and only if the buffer timestamp differs significantly from what was
expected. This prevents a stuck buffering case for streams that are thought
to start at t=0, but actually start at t=large_value.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=186990214
The waiting for a ConditionVariable to be false was replaced by a
CountDownLatch whose count is asserted to be one. The timeout of a
ConditionVariable doesn't work in Robolectric unless someone is
manually increasing the SystemClock time.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=186003125
If an exception is thrown in an IMA callback it crashes the process with lots of
logging from WebView (including several stack traces, etc.). This change wraps
ImaAdsLoader code that might throw, skips any remaining ads (as the errors are
not recoverable, in general) and notifies a new load error callback so that the
application can implement its own handling. The intention is to make the loader
robust to unexpected requests from IMA and avoid crashes.
Also handle IMA loading an ad in an ad group that has no available ads. In rare
cases IMA will try to load an ad for which an error was previously notified, so
this drops those load requests allowing playback of the content to continue.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=185985850
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
In the case of the components we deliberately access via
reflection, it's normal that they might not be resolved
due to proguarding (i.e. if the app isn't being built to
include them). Don't note their omission.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=184120611
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
