- Use Cache UID for CacheContentIndex and CacheFileMetadataIndex. This
enables SD card swapping for a single device.
- I'm hopeful of finding a way to get the Cache UID to DefaultDownloadIndex
so we can do the same there.
PiperOrigin-RevId: 234662753
Stop encoding/decoding presentation time as part of the message.
What's actually in emsg boxes is a presentation time delta,
which is why it's only 32 bits, and hence why it doesn't handle
large absolute timestamps. We were using this field to hold
absolute timestamps only for the purpose of passing presentation
times from DashManifestParser.parseEvent back to the calling
method. After this change, we return Pair<Long, EventMessage>
instead.
Issue: #5490
PiperOrigin-RevId: 233561731
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
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
