This change fixes playback of playlists where segments have the
extension and Content-Type of JPEG pictures (although in reality)
they are transport streams. File inferrence before this change will
cause an exception when assuming the inferred file type is one of
the allowed HLS containers.
#minor-release
Issue: #8733
PiperOrigin-RevId: 363641277
This makes HLS playback less liable to become stuck if discontinuity
tags are inserted at different times across media playlists.
Issue: #8700
Issue: #8372
PiperOrigin-RevId: 362903428
According to the spec (section 8.4.2), high numeric values represent low
priorities, so we need to flip this sort.
Issue: #8704
#minor-release
PiperOrigin-RevId: 362558370
`ImaAdsLoader` clears its `AdPlaybackState` when it's released but this could
cause `AdsMediaSource` to look up information in the ad playback state that is
no longer in bounds.
Issue: #8693
PiperOrigin-RevId: 362556286
In a period transition we pass the start time of the next period, for
the final period we pass the duration of the period or timeline, if
known.
This means sideloaded subtitles now respect the end point of
ClippingMediaSource and ensures that content subtitles aren't
incorrectly displayed over mid-roll ads.
When transitioning back into the subtitled content the subtitles still
appear slightly before the video transitions, meaning the first subtitle
of the content is shown with the last few frames of the ad. Resolving
this in a way that doesn't break anything else requires a deeper
investigation.
Issue: #5317
Issue: #8456
#minor-release
PiperOrigin-RevId: 361797118
MaskingMediaSource needs to resolve the prepare position set for a MaskingPeriod
while the source was still unprepared to the first actual prepare position.
It currently assumes that the period-window offset and the default position is
zero. This assumption is correct when a PlaceholderTimeline is used, but it
may not be true if the real timeline is already known (e.g. when re-preparing
a live stream after a playback error).
Fix this by using the known timeline at the time of the preparation.
Also:
- Update a test that should have caught this to use lazy re-preparation.
- Change the demo app code to use the recommended way to restart playback
after a BehindLiveWindowException.
Issue: #8675
PiperOrigin-RevId: 361604191
- Avoid having two onPositionDiscontinuity events (seek and transition)
sent after a seek to another media item.
- Avoid triggering an onPositionDiscontinuity event after a timeline
change.
#minor-release
PiperOrigin-RevId: 361092914
Latest LTS version is better than latest stable version because it will
be supported for longer.
#minor-release
Issue:#8581
PiperOrigin-RevId: 359467482
- Ensure consistency between (Styled)PlayerControlView,
PlayerNotificationManager, TimelineQueueNavigator and
DefaultControlDispatcher.
- Handle the case where a live stream has ended when enabling previous
and next actions (window.isLive() is true and window.isDynamic is
false in that case)
PiperOrigin-RevId: 359063793
`ImaAdsLoader` will preload the first ad of a subsequent media item, but the
preloaded ad might not actually play because the user could seek to a non-zero
position in that media item (which could trigger playback of a midroll, not the
preroll). In this case, playback would get stuck because the midroll ad
expected to play after the seek would never load, because the IMA SDK expected
the preroll to play first.
Fix this behavior by discarding the preloaded ad break. If there isn't a seek,
the transition to the next media item is still seamless.
#minor-release
PiperOrigin-RevId: 357682510
Previously it was safe to query the first period in the timeline, but
now we support using the ads loader in concatenations we need to use
the current period index instead.
PiperOrigin-RevId: 357578003
The available end time was accidentally substracted by the start time
of the last period.
To avoid similar time reference confusion in the future, also renaming
many variables and methods to clearly reflect the time reference point.
And to avoid constant conversion, the processManifest method also
attempts to converge to time relative to the start of the window as
quickly as possible.
Issue: #8537
PiperOrigin-RevId: 357001624
If keepalive is disabled the existing code over-eagerly releases
DrmSession instances. This is arguably OK since a (Default)DrmSession
should be released before its (Default)Manager is released
(since the underlying MediaDrm instance might be released when the
manager is released). And if all sessions are released before the
manager is released then `sessions` is empty, so the loop is a no-op.
Issue: #8576
PiperOrigin-RevId: 356955308
The `DrmConfiguration.sessionForClearTypes` property is often used
to ensure a secure decoder is used for clear ads played in encrypted
content. This is because some devices show black frames when switching
decoders.
Before this change the DRM config isn't propagated down when
constructing the ad media source, meaning
`DrmSessionManager.DRM_UNSUPPORTED` is always used, which will
cause playback to switch from secure to clear decoder when transitioning
to an ad break (ignoring the MediaItem `sessionForClearTypes` option.
Issue: #8568
PiperOrigin-RevId: 356951124
Without this a new manager is instantiated for every item in a playlist,
meaning the impact of caching improvements to DefaultDrmSessionManager
are reduced (since the cache doesn't persist across playlist items).
With this change, playlists of items with identical DRM config will use
the same manager instance (and thus share existing sessions).
Issue: #8523
PiperOrigin-RevId: 356690852
Also allow the player's prepared ad media period durations array to exceed the
length of the loaded ad URIs array, as it's possible for the player to buffer
an ad media period fully at the point where it's known that an ad is coming up
but its URI is still unknown.
PiperOrigin-RevId: 356249284
* Move cherrypicked changes from dev-v2 to 2.13.0
* Use a bulleted list instead of comma-separated.
* Standardise everything into present, imperative sentences.
* Remove a couple of mixed-font words (I left cases with a separating
apostrophe, as these seemed visually clearer).
* Merge multiple issue links into a single set of parentheses.
#minor-release
PiperOrigin-RevId: 355180143
Without this no error is currently logged or propagated to EventLogger.
The propagation doesn't happen because
MergingMediaSource.ForwardingEventListener only propagates events
originating from the "main" source in the merge:
<unknown commit>
#minor-release
PiperOrigin-RevId: 354902467
- Fix comparison between a byte and 0xFF to avoid conversion of 0xFF to
byte and to int again (due to numeric promotion).
- Fix addition of int and byte with most significant bit set. The byte
was incorrectly promoted to an int negative value.
Issue:#8496
#minor-release
PiperOrigin-RevId: 353865751
`TrackSelection` had mutation methods which were to be called only
internally by ExoPlayer components but were exposed in the
public `Player` interface.
The mutation methods have been moved out of `TrackSelection`
to a new class `ExoTrackSelection`.
Current track related read-only method have also been moved out,
because they are actually something quite unclear.
Even for a single item playlist, it's the track being buffered rather
than the track being played, which is unclear.
But when you have a playlist it starts to get really confusing,
because if the next item is being buffered, then it's actually
the last track to be buffered in the currently playing item.
As a final aside, the implementations don't do proper thread synchronization
to ensure visibility of updated state by the calling thread.
Exposing those mutable methods in the public `Player` interface
was problematic because they leaking internal concepts of `ExoPlayer`.
This is also required to minimize the `Player` interface for long term
stability.
`ExoTrackSelection` is a subclass of `TrackSelection`.
This is not ideal as an `TrackSelection` implementation could
break the current immutability.
This was done in order for this refactor to be simpler.
A future patch will fully split the two classes.
All `MediaPeriod` and `Sources` had to be updated to use the new
`TrackSelection` dynamic aspect class name.
An alternative would have been to break ExoPlayer's public API, keeping
`TrackSelection` as the dynamic aspect name, and calling the public static
aspect class `TrackSelectionState` or similar.
Nevertheless, while it would have impacted less files, it would have
many more small apps and casual users of ExoPlayer.
#player-to-common
PiperOrigin-RevId: 353637924
`ImaAdsLoader` only loads ad media URLs once playback of the preceding ad (if
any) has started, and this behavior is likely to be similar for other ad loader
implementations due to limits on how long before an ad plays it is meant to be
loaded. This is problematic for very short ads followed by an ad because the ad
will load to the end but load control may not allow playback to start due to
the total buffered duration being low.
Fix this by allowing playback to start regardless of load control if we are
waiting for an ad media period to prepare.
An alternative fix would be to fake the ad progress in the `ImaAdsLoader` to
trigger loading the next ad, but this would only allow one ad to load ahead (so
the problem would remain for two short ads in a row followed by another ad).
Issue: #8492
PiperOrigin-RevId: 353600088
This ensures the message devilery is governed by the clock.
Also replace setting a Handler with a Looper to facilititate this
change.
PiperOrigin-RevId: 353019729
The IMA SDK currently notifies `CONTENT_RESUME_REQUESTED` then
`CONTENT_PAUSE_REQUESTED` quickly afterwards when playing an ad for an initial
seek. This triggered the logic to skip VPAID ads added for Issue: #7832,
causing the ad to be skipped.
This change reverts the fix for that issue and extends the ad preload timeout
logic to cover the case of an initial seek as well. Incompatible VPAID ads will
still be skipped but only after the preload delay (this seems fine given that
they are documented not to be supported, and we are just making the failure
mode less bad on a best-effort basis!).
Issue: #8428
Issue: #7832
PiperOrigin-RevId: 353011270
