When calling releaseSource(), all pending messages will be removed. That means
that all action-on-completion callbacks which are somewhere in flight are
just dropped without being called. This change adds code to keep track of the
current state of each callback to allow all of them being called when the
source is released.
Issue:#5464
PiperOrigin-RevId: 232312528
We can keep the reading media period and continue playing if we haven't read
beyond the new duration. Otherwise, we can keep the period, but need to reset
the renderers as we already read too far.
PiperOrigin-RevId: 231406252
This requires to prepare the media source and the periods in a small helper similar
to the metadata retriever. It also gets rid of the need to have abstract protected
methods to load the manifest, to extract the track groups and to convert to stream keys,
as this can now be handled by the media period.
PiperOrigin-RevId: 231385590
The way it is currently, it's very unclear that an operation on the
version table will correctly belong to a transaction in code such as
this, taken from DefaultDownloadIndex:
writableDatabase.beginTransaction();
try {
writableDatabase.execSQL(...);
versionTable.setVersion(...);
writableDatabase.setTransactionSuccessful();
} finally {
writableDatabase.endTransaction();
}
This change explicitly passes the database, to make it obvious that
the operation will really go into the same transaction:
writableDatabase.beginTransaction();
try {
writableDatabase.execSQL(....);
VersionTable.setVersion(writableDatabase, ...);
writableDatabase.setTransactionSuccessful();
} finally {
writableDatabase.endTransaction();
}
PiperOrigin-RevId: 231374933
If are allowing changing durations of periods, we shouldn't use the end position
of clipped content as part of the id as it may change. This change moves the end
position back to MediaPeriodInfo and adds the next ad group index to the id
instead to ensure we still have unique ids for all content parts.
PiperOrigin-RevId: 230878389
The combination of pre-16 API levels accounting for ~0.5% of the device
population, and that the most important components in ExoPlayer (e.g.
the MediaCodec renderers) have always required API level 16, mean it's
very unlikely this will negatively impact on anyone.
PiperOrigin-RevId: 230701808
We need to support serialization to/from an SQLite table. The
model of passing something around for each class to write into
doesn't work well for SQL, and it would be messy to have two
different structural designs for serialization. This change
centralizes the logic in CachedContentIndex, where a centralized
SQL based version can more easily sit alongside it.
PiperOrigin-RevId: 230692291
1. The method kept track of the current period index to check if the next
period is still in the correct period. This is unneccessary since we no longer
use the period index but the actual uid in MediaPeriodId and mismatches are
already detected by canKeepMediaPeriodHolder.
2. We updated the MediaPeriodIndfo twice: once in getFollowingMediaPeriodInfo
and once in getUpdatedMediaPeriodInfo. That's confusing and difficult to
follow. The only difference is that getUpdatedMediaPeriodInfo keeps the
content position while getFollowingMediaPeriodInfo resets it. This is made more
explicit for readability.
3. The durations compatibility check for all following periods was broken as
it compared the same durations (partly due to the confusion caused by 2.)
PiperOrigin-RevId: 230519295
* Add AC-4 MIME type definition
* Add AC-4 format support in Mp4Extractor and TsExtractor
* Add AC-4 Extractor
* Add AC-4 playback support in MPEG-4, MPEG-DASH, TS and HLS
The buffered position is currently based on the mimimum queued timestamp of
all AV tracks. If the tracks have unequal lengths, one track continues loading
without bounds as the "buffered position" will always stay at the shorter
track's duration.
This change adds an optional buffer flag to mark the last sample of the
stream. This is set in the Mp4Extractor only so far. ExtractorMediaSource
uses this flag to ignore AV streams in the buffered duration calculation if
they already finished loading.
Issue:#3670
PiperOrigin-RevId: 229359899
This is not necessary as the track selection needs to be updated with
updateSelectedTrack anyway. It's also error-prone as the selection code
calls into a protected method of a not fully initialized class.
PiperOrigin-RevId: 229331669
DataSpec.FLAG_ALLOW_CACHE_FRAGMENTATION is added to indicate to the
cache when fragmentation is allowed. This flag is set for progressive
requests only.
To avoid breaking changes, CacheDataSink defaults to ignoring the flag
(and enabling fragmentation) for now. Respecting the flag can be
enabled manually. DownloaderConstructorHelper enables respecting of
the flag.
Issue: #4253
PiperOrigin-RevId: 229176835
Calls to File.length() can be O(N) where N is the number of files
in the containing folder. This is believed to be true for at least
FAT32. Repeated calls for the same file tend to be faster,
presumably due to caching in the file system, however are still
surprisingly expensive. Hence minimizing the number of calls is
preferable.
Issue: #4253
PiperOrigin-RevId: 228179921
They are not longer needed anywhere, are error-prone (because of threading
requirements), and complicate testing and using MediaSources without a player.
PiperOrigin-RevId: 227871157
We currently either use the app thread returned by the player or the thread
the commands are called on depending on whether the media source is already
prepared or not.
This change lets the application decide which callback thread to use. As a
side effect, we also don't longer need access the player instance passed to
MediaSource.prepare.
PiperOrigin-RevId: 227871111
Made DownloadState top level class.
Replaced action field DownloadAction fields.
Added removing, removed and restarting states.
Renamed started state to downloading.
PiperOrigin-RevId: 227664735
- Increase the default cache file size to 5MB
- Recommended a minimum cache file size of 2MB to discourage
applications from specifying values small enough such that
unreasonably large numbers of cache files are generated
- Allow maxCacheFileSize=C.LENGTH_UNSET, equivalent to setting it
to MAX_VALUE. This is just for API consistency with other APIs
we have that accept LENGTH_UNSET
Issue: #4253
PiperOrigin-RevId: 227524233
Problem: There is nothing in the Cache interface that enforces that
these methods are implemented by reading/writing content metadata,
however our own code (CacheDataSource) relies on this property since
it mixes use of [get|set]ContentLength and use of metadata. Using
metadata is the right approach because it minimizes the number of
index writes (e.g. it allows the redirect URI and the content length
to be committed by a single write).
Solution: Remove [get|set]ContentLength, which are redundant anyway,
and use metadata everywhere. Also expose the keys being used through
the public API; there's no particular reason why they shouldn't be.
We previously had an API for getting and setting content length, but
no API for getting and setting redirect uri.
PiperOrigin-RevId: 225383211
This adds the basic track selection capabilties (including tests).
The new capabilities are not exposed yet through the DownloadHelper implementations
and there will also be more helper methods (e.g. to select multiple audio lanuages at
once).
PiperOrigin-RevId: 224518477
We currently have two factory methods where it is completely unclear which one needs
to be overridden.
This change deprecates the old one, adds a Util method to easily map back from the new
to the old behaviour, and updates all implementations of the now deprecated method in
our code.
PiperOrigin-RevId: 224303560
We currently default to not caching data if the content length
cannot be resolved once the DataSource has been open. The
reason for this is to avoid caching progressive live streams.
By doing this we were accidentally not caching in other places
where caching is possible, such as DASH/SS/HLS segments during
playback if the server doesn't include a Content-Length header.
Also HLS encryption key chunks, which were very unlikely to be
cached during playback because we explicitly set FLAG_ALLOW_GZIP
(which normally stops content length from resolving) without
setting FLAG_ALLOW_CACHING_UNKNOWN_LENGTH.
It seems like a good idea to flip the default at this point,
and explicitly disable caching in the one case where we want
that to happen.
PiperOrigin-RevId: 223994110
A remove action will eventually just be the unique ID of the download
that should be removed. This is a step toward that goal.
PiperOrigin-RevId: 222832456
- Add DownloadAction.fromByteArray for symmetry with toByteArray
- Make DownloadService call fromByteArray, for symmetry with calls
to toByteArray
PiperOrigin-RevId: 222801703
This allows more efficient range removals and is consistent with addition,
which supports adding multiple elements in a single operation.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=222396310
1. Pull up all subclasses of DownloadAction into DownloadAction
2. Add DownloaderFactory for Downloader instantiation, and DefaultDownloaderFactory
to replace the instantiation logic being removed from the DownloadAction
subclasses.
This change will upgrade existing action files gracefully (i.e. it does not
lose compatibility with the existing offline implementation, other than some
minor breaking changes to the API).
TODOs:
1. Move test methods from the XDownloadActionTest classes into DownloadActionTest.
This will be done in a subsequent CL. There's a lot of consolidation that can
be done here, including de-duplicating some of the test code added in this CL.
2. Look at merging DownloaderConstructorHelper into DefaultDownloaderFactory.
3. Use customCacheKey in DASH/HLS/SS Downloaders, for completeness.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=222258983
createTrackSelections decides whether to create an adaptive or a fixed track seletion to create.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=222231011
This ensures that all callbacks use the same notification mechanism.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=222226913
WindowedTrackBitrateEstimator, uses future and past chunks in a window
of time to estimate track bitrate values.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=222065409
Currently no path may be chosen if
minBufferUs == maxBufferUs == bufferedDurationUs.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=221639199
- Increase the search window size to fix TS seeking for problematic
media we've had provided to us.
- As per my comments on the issue, we should look at doing more here
to better fix the problem. This will solve the worst of the
immediate problem, however.
- The memory usage is non-trivial, particularly with the increased
search window size. I've made the allocations only live whilst
determining duration and seeking to address this. I've done the same
for PS just for consistency.
Issue: #5097
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=221449988
This fixes an issue where disabling audio focus handling
while audio focus is held would not release audio focus.
A new test was added for this situation.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=220316866
It's no longer guaranteed that onOutputFormatChanged will always be
called when the renderer is re-enabled, since the codec may be kept
and its output format may not change. Hence we need to avoid resetting
state in onDisabled that we need when the renderer is enabled again.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=219821519
This prevents leaving an inconsistent state after a EOF exception.
Issue:#5039
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=219785275
Before this change, the player state would be STATE_ENDED then
STATE_BUFFERING (when the postroll ad was marked as played) then
STATE_ENDED again.
Queueing a final content media period with start point equal to
the content duration after a postroll ensures that the player
state doesn't change to STATE_ENDED transiently.
Switch from using C.TIME_END_OF_SOURCE to C.TIME_UNSET for media
periods that should not have an end point and are not followed
by an ad.
Content media periods before postrolls have end position
C.TIME_END_OF_SOURCE. If the postroll ad loads, its content
position is set to the content duration, which should be known
at the point of loading the postroll, then a final 'empty'
content media period with start position equal to its duration
is queued. If the postroll fails to load, this empty content
media period is queued up directly after the preceding content
media period.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=219443683
In ConcatenatingMediaSource, the source may be removed before it started
preparing (this may happen if lazyPreparation=true). In this case, we
shouldn't call releaseSource as the preparation didn't start.
Issue:#4986
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=218141658
- It's a no-op for now
- Renderers that want to support retaining resources will move
some functionality from their disable() implementations into
reset()
- ExoPlayerImplInternal will be updated to not always call reset()
immediately after disable(), which is what will enable resources
to actually be retained.
Issue: #2826
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=215729783
This makes the following changes to improve consistency among the PlaybackInfo
values:
1. Update buffered position and total buffered duration after loading period
is set as both values are affected by a loading period update.
2. Add copyWithPosition to allow updating the position without resetting the
loading period.
3. Forward the total buffered duration to playing position updates
as it may have changed with the new playing position.
Issue:#4899
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=215712328
This removes the experimental bandwidth meter and uses it as the new default.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=215404065
If we prepare a deferred media period before the actual timeline is available,
we either prepare with position zero (= the default) or with a non-zero
initial seek position.
So far, the zero (default) position got replaced by the actual default position
(including any potential non-zero window offset) when the timeline became known.
However, a non-zero initial seek position was not corrected by the non-zero
window offset. This is fixed by this change.
Related to that, we always assumed that the deferred media period will the
first period in the actual timeline. This is not true if we prepare with an
offset (either because of an initial seek position or because of a default
window position). So, we also determine the actual first period when the
timeline becomes known.
Issue:#4873
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=215213030
If a source is removed from the playlist, the player may still call createPeriod
for a period of the removed source as long as the new timeline hasn't been handled
by the player. These events are stale and can be ignored by using a dummy media
source. The stale media period will be released when the player handles the updated
timeline.
Issue:#4871
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=214787090
Not having this annotation may cause Kotlin implementations to fail.
Issue:#4802
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=212980643
If we can select a track that has a strictly higher score than a
selection already made for a renderer of the same type, we should
prefer it.
Issue: #4711
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=212835895
This allows to update the shuffle order after the ConcatenatingMediaSource
has been created. ShuffleOrder objects should be immutable to ensure thread
safety and thus there is no way to do this currently.
Issue:#4791
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=212443146
The default character set is always UTF-8 anyway on Android, but
we don't want our code to behave any differently where it's not
(e.g. robolectric test runs could potentially run in an environment
where UTF-8 isn't the default?).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=211953885
1. Currently, we may throw source info refresh errors while the previous media
period is still playing.
2. We don't throw if the next period in a playlist fails to prepare and the
previous renderers are all disabled.
3. We throw source info refresh errors for playlists before playback reaches
the culprit source.
This change:
1. Defers the exceptions until all existing media periods have been played.
2. Checks for period preparation exception if the next period is not
getting prepared and the renderer time reached the next period.
3. Does no longer throw from ConcatenatingMediaSource.maybeThrowSourceInfo
RefreshError. The deferred media periods take care of that for each source
individually.
Issue:#4661
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=211819436
To report DRM session metrics in the future as part of the listener, we need
a callback at the end of the drm session to get the final metric state.
For completion, the session acquired callback is also added.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=211328412
Also make some javadocs more consistent with the rest of the library.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=211071559
The current structure tries to associate events to media periods and windows
based on the reported values and the current timeline. However the reported
EventTime may not always be consistent in case the timeline doesn't contain
windows or media periods yet or not anymore.
The recent changes to MediaPeriodId allow to use it as a unique identifer for
media periods independent of the timeline. This enables more accurate tracking
of the media period queue and prevents reporting events with inconsistent
data.
Issue:#4492
Issue:#4634
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=210713120
This provides the list of currently buffered media chunks and iterators over
the potential next chunks to the track selection. Having these two parameters
enables more advanced decision logic based on this data.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=210551812
- Add @Deprecated on overrides of deprecated method.
- Suppress deprecation warnings where appropriate.
- Use non-deprecated alternatives where appropriate.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=210092434
This option is currently not available as a non-null adaptive track selection
has to be provided. Adds a parameter "forceHighestSupportedBitrate" which
corresponds to the default fixed track selection for audio and video.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=210073675
Some tests were flaky because of the PlayUntilPosition action which called
player.setPlayWhenReady from the wrong thread. Also fixed some other misc
flakiness.
ExoPlayerTest seems to be non-flaky now (tested with 10000 runs).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=209743076
The MediaPeriodId with index is only properly defined together with a
timeline containing the index. Changing it to the period uid allows to use
the MediaPeriodId independent of the corresponding timeline.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=209430257
This CL adds support for seeking witin TS streams by using binary search. For
any seek timestamp, it tries to find the location in the stream where PCR
timestamp is close to the target timestamp, and return this position as the
seek position.
Github: #966.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=207529906
- Use ConstantBitrateSeeker to implement seeking for ADTS format. Since most
ADTS streams are VBR, we use the average bitrate of the first 1000 frames as
the average bit rate.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=207509651
When user seeks to an unprepared period, since there is no period being played, currently the track groups and track selections are still the ones from previous period. This CL changes it so that when such seeking happens, PlaybackInfo's track groups and track selections are changed to empty.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=206916109
This is needed for implementing (optional) support for audio focus handling in a
later change.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=206899837
This CL adds support for seeking within PS streams by using binary search. For
any seek timestamp, it tries to find the location in the stream where SCR
timestamp is close to the target timestamp, and return this position as the
seek position.
Github: #4476.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=206787691
MatroskaExtractor was checking for INDEX_UNSET as the sample count for buffers
not containing syncframes, but actually 0 was returned for these. Theoretically
this could prevent us starting to play a TrueHD stream as we wait until we can
read the sample count from a syncframe before accepting the audio in
DefaultAudioSink, but it seems that rechunking avoided this issue arising in
practice.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=206575462
The looping media source doesn't convert the media period id to the externally
visible media period id. And the merging media source reports media period
creations multiple times which will break listeners assuming a media period
with a specific id will only be created once.
Also amend the doc for MediaSource.createPeriod to reflect that media periods
created in parallel do not actually have the same id.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=206327241
Period transitions with non-zero start position happen too early as the
playing period is advanced as soon as the renderer offset is reached not
taking into account that the start position needs to be added to that.
Issue:#4583
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=206310328
Remove minLoadableRetryCount from HLS components in favor of
LoadErrorHandlingPolicy#getMinimumLoadableRetryCount.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=206298419
This changes the default initial bitrate estimate to be country (group) and
network type specific. The existing overwrite still works as before and new
overwrites for the country or specific network types are provided for
customization.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=205972705
