If there is data after the last samples in the container, we may request
continue loading after the last samples have been read but before the load has
completed. In this situation the buffered position is returned as
Long.MAX_VALUE, which prevents continuing loading, yet the media period is not
treated as fully buffered because its buffered position is not
C.TIME_END_OF_SOURCE.
PiperOrigin-RevId: 231406964
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
It better describes what the class does. More importantly, we've had
inconsistent class names since we added offline support, for which we
added ProgressiveDownloader ("ExtractorDownloader" doesn't make any
sense). We could really do with aligning the names for clarity.
(Sorry)
PiperOrigin-RevId: 231387268
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
Converting a single track selection to stream keys is only possible if the output
is independent from other track selections being made.
This is not the case for DASH and HLS embedded track groups which should select the
already selected primary track if possible (and thus needs to know whether a primary
track group is selected).
Also, update the test method to take a period index.
PiperOrigin-RevId: 231385490
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
Float output is only possible from API 21, but the high-res int
to float conversion path was checking for 32-bit PCM not float
output capability.
PiperOrigin-RevId: 231172495
This will allow CachedContentIndex to start using database
storage without us having to change the SimpleCache and
CachedContentIndex constructors to require a Context or a
DatabaseProvider.
PiperOrigin-RevId: 230884501
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
This method is a generalization of the existing hasReadStreamToEnd. It is
useful to determine whether a renderer already read beyond a new duration of
a period.
PiperOrigin-RevId: 230689165
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
ExoPlaybackExceptions of type SOURCE are always associated with the loading
period and thus we can use the event time for the loading period in
onPlayerError. Renderer and unexpected exceptions are still associated with the
currently playing period.
Issue:#5407
PiperOrigin-RevId: 230216253
The Amlogic awesome decoder reduces the video size of interlaced videos by half
if the internal configuration isn't force reset with new maximum input size
values. The product of these new values must exceed 1920x1088 to force the
reset.
Issue:#5003
PiperOrigin-RevId: 230206675
That's the same position set in MediaPeriod.prepare (where it may be removed
in the future).
Having the position at an earlier point is necessary to fix an
issue with lazy preparation in ConcatenatingMediaSource where the prepare
position was assumed to be known but MediaPeriod.prepare hasn't been called
yet.
Issue:#5350
PiperOrigin-RevId: 229756637
[Problem]
CC1 is shown even when CC2-3-4 is selected
[Solution]
* use incoming channel and frame information
* Misc Codes need to handle use Frame information
* Add checks everywhere
[Test]
* Live channels and already existing test should not show any difference
in behavior when CC1 is selected.
* Live channels might have CC2-CC3-CC4
* Sarnoff test content has specific test cases for channel support
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
