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
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
When the extra adaptation set of a switch group isn't defined in the manifest, we
currently assume it's the first adaptation group. This either leads to wrong grouping
or duplicate track groups.
Such a case may easily happen if the manifest is filtered such that only one of the
switch adaptation sets will be present in the manifest.
PiperOrigin-RevId: 229365379
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
That was previously handled by the player. But since we switched to Handler
messages instead of player messages, we should do that manually.
PiperOrigin-RevId: 229341747
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
We currently forget whether a source is seekable at re-preparation. This was
implemented intentionally this way under the assumption that we really can't seek
until we have loaded the seek map again. However, seek operations are only
allowed after a media period is prepared. So there is no harm in remembering
whether a source is seekable.
This problem currently prevents reusing ClippingMediaSources with
ExtractorMediaSource and a non-zero start clip position.
Issue: #5351
PiperOrigin-RevId: 229169441
ExoMediaCrypto.requiresSecureDecoderComponent() is removed, and
FrameworkMediaCrypto.forceAllowInsecureDecoderComponents is made
public to allow determining whether a secure decoder is required
to be implemented in MediaCodecRenderer.
PiperOrigin-RevId: 228909771
There were some edge cases in which we'd forget to release DRM
sessions. For example if we read a format and acquired a
pendingDrmSession (in onInputFormatChanged), then immediately
read another format and overwrote pendingDrmSession, we'd
forget to release the one that's been overwritten.
This change hopefully makes release much clearer. We keep a list
of all drm sessions we're currently holding. Whenever we update
either drmSession or pendingDrmSession, we release any other
sessions that are in the list.
PiperOrigin-RevId: 228905465
The window object is used without being filled with data. This used to work
well for most cases as the same live stream is sending regular updates and the
first update is almost never used if it's not the first item in a playlist.
It causes problems when the first timeline update of a live stream is actually
used for playback (e.g. when the live stream is lazily prepared in a playlist
and played first).
PiperOrigin-RevId: 228530232
Reported in https://github.com/google/ExoPlayer/issues/3860
For failing examples see the github link above.
[Problem]
We drop matching control codes even if they are not received on
consecutive frames.
The specification says
"(4) If the first transmission of a control code pair passes parity,
it is acted upon within one video frame. If the NEXT frame contains
a perfect repeat of the same pair, the redundant code is ignored."
Keyword is the NEXT. The frames must arrive immediately after
each other.
See https://www.law.cornell.edu/cfr/text/47/79.101
[Solution]
Set an additional flag when any data is processed. Control code
duplication checks should be limited only for the first control
byte pairs processed after any control code.
[Test]
Sarnoff tests have equivalent CEA708 and CEA608 Streams.
This is the initialization part of mitigating issue #4253. The
remaining work is on the writing side, and is simply a case of
having startFile return File instances that are sharded into
sub-directories. We still need to decide what scheme we want
to use for doing that.
Issue: #4253
PiperOrigin-RevId: 228306327
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
Also configure the FFmpeg context to ignore errors as far as possible (this
appears to have an effect only for certain decoders).
Issue: #5293
PiperOrigin-RevId: 227851397
The top level requirement only tried to ensure that the entire timeline only
has one period. This is already asserted by ImaAdsLoader. AdsMediaSource
itself works fine as long as the wrapped timeline has one period only. This
is now asserted instead.
PiperOrigin-RevId: 227682141
Passing the player through MediaSource.prepare is only needed for the AdsLoader
and complicates other usages of MediaSource. Providing the player directly to
the AdsLoader is also in line with the usage pattern of PlayerView and other
components.
Also rename methods to start/stop to better reflect their usage.
PiperOrigin-RevId: 227682112
Made DownloadState top level class.
Replaced action field DownloadAction fields.
Added removing, removed and restarting states.
Renamed started state to downloading.
PiperOrigin-RevId: 227664735
ExoPlayer methods must not be called from any thread besides the specified
app thread. Therefore we shouldn't use them here. Using a regular Handler
instead is fully equivalent.
Issue:#5240
PiperOrigin-RevId: 227650489
- 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
CacheEvictor.onStartFile currently receives a length, which is the
maximum size of the content that might be written. The LRU cache
evictor will make sure there's sufficient space for the specified
size. If the actual size of the content is unknown, CacheDataSink
passes maxCacheFileSize.
The current behavior isn't ideal. It seems valid for a developer to
specify maxCacheFileSize=Long.MAX_VALUE if they don't want any
file fragmentation in the cache. However if they then attempt to
cache something with unknown length, LRU cache will try and make
room for content of length Long.MAX_VALUE, and end up evicting the
entire cache to do so.
This change alters the logic so a length is only passed if the
actual size of the content is known. In other cases C.LENGTH_UNSET
is now passed. The LRU evictor will not evict until after the file
is committed. Note a custom LRU evictor could still opt to evict to
ensure some application specified amount of space, if that's the
desired behavior.
PiperOrigin-RevId: 227509525
This also applies when seeking or transitioning to unprepared media, which
isn't clear from the current documentation.
Issue:#5267
PiperOrigin-RevId: 226486685
When a Download is created it's set to queued state but doesn't notify
listeners about this state. DownloadManager checks if it can start the
download. After this checks it notifies the listeners.
With this change Download can immediately check if it can be started and
sends correct notification.
PiperOrigin-RevId: 225967129
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
[Problem]
As the alignment of each lineas are calculated individually, the
artificially introduced CENTER and RIGHT alignments can be mixed
with each other and with the default LEFT alignment. The mixed results
look worse than just using the original DEFAULT, and the readability
is radically decreased.
[Solution]
Pre-calculate the alignment for each line, and use the leftmost of them
for all lines. The intention of caption provider could be different, but
the worst case scenario is that we revert back everything to LEFT
alignment that is the only option in the CEA608 standard so we
show everything at the exact location it is set in the content.
The readability is never worse than the one given by the content
provider.
[Test]
This should influence CEA608 pop-up cations only. (Not roll up).
Test various live channels with this change.
Note: Beginning of commercials tend to have PAINT-ON mode as that
is immediately showing incoming characters, not just at the end
of the line like POP-on mode.
This instantiates the renderers and extract the capabilities. None of the known
renderes incurs any overhead during instantiation.
PiperOrigin-RevId: 224118511
- Enable GZIP for media playlist + encryption key chunk requests in
HLS, as we do during playback
- Pass around DataSpecs rather than Uris. This will be needed for if
we add manifest cacheKey support (which seems like a good idea for
completeness, if nothing else)
PiperOrigin-RevId: 224057139
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
This is in line with how Player.EventListener and AnalyticsListener methods are
defined and helps to only implement the callbacks needed.
PiperOrigin-RevId: 223991262
Moving most of the logic to the base DownloaderHelper helps to implement track
selection for downloading in a single place instead of multiple places.
PiperOrigin-RevId: 223964869
This option to block bandwidth already exists on the AdaptiveTrackSelection itself
but it's not currently possible to forward the total fixed track bandwidth
automatically.
PiperOrigin-RevId: 223785139
- Asus ZenFone GO (ASUS_X00AD_2)
- Sugar S9 (i9031)
- Redmi Note 3 (kate)
These devices trigger native crashes similar to
https://github.com/google/ExoPlayer/issues/4460
I'm not sure why Asus Zenfone Go (model: ZB500KL, device: ASUS_X00AD_2) was removed here
73af056da3
PiperOrigin-RevId: 223580393
