We are currently queuing periods in a way such that the new start position
lines up with the end of the previous period (to ensure continuous playback).
However, if the start position of the new period is larger than the total of
all previously played period durations, we may end up with negative renderer
timestamps when seeking back to the beginning of this new period. Negative
timestamps should be avoided as most decoders have problems handling them
correctly.
This change forces a renderer reset if we detect such a seek to a negative
renderer time and also resets the renderer offset to 0 every time all
renderers are disabled, as this is the only time where we can savely change
the offset of an existing media period.
Also, if playback starts with an ad, we choose the content position as
renderer offset to prevent the whole issue from occurring for the seek-behind-
midroll case.
Issue:#6009
Issue:#5323
PiperOrigin-RevId: 253790054
This permission has normal access right and can't be revoked by the user.
However, an app can choose to revoke it when using ExoPlayer, e.g. if
no network is required and the app doesn't want to list this permission.
Support this use case by gracefully catching the exception in the relevant
places.
Issue:#6019
PiperOrigin-RevId: 253759332
We currently report MediaCodec exceptions as unexpected exceptions instead of
as renderer error. All such exceptions are now wrapped in a new DecoderException
to allow adding more details to the exception.
PiperOrigin-RevId: 252054486
We currently don't display the last frame because the seek time is behind the
last frame's timestamps and it's thus marked as decodeOnly.
This case can be detected by checking whether all data sent to the codec is
marked as decodeOnly at the time we read the end of stream signal. If so, we
can re-enable the last frame. This should work for almost all cases because the
end-of-stream signal is read in the same feedInputBuffer loop as the last
frame and we therefore haven't released the last frame buffer yet.
Issue:#2568
PiperOrigin-RevId: 251425870
Using parallel adaptation for Formats without bitrate information currently
causes an exception. Handle this gracefully and also cases where all formats
have the same bitrate.
Issue:#5971
PiperOrigin-RevId: 250682127
cache() opens all connections with unset length to avoid position errors.
This makes more data then needed to be downloading by the underlying
network stack.
This fix makes makes it open connections for only required length.
Issue:#5927
PiperOrigin-RevId: 250546175
This prevents further unexpected updates if the MediaSource happens to
finish its preparation at a later point.
Issue:#5915
PiperOrigin-RevId: 249439246
Adding an explicit option to clear all downloads prevents repeated database
access in a loop when trying to delete all downloads.
However, we still create an arbitrary number of parallel Task threads for this
and seperate callbacks for each download.
PiperOrigin-RevId: 247234181
Can happen if the load position falls behind in every playlist and
when we try to load the next segment, the adaptive selection logic
decides to change variant.
Issue:#5816
PiperOrigin-RevId: 245923006
We currently toggle the view in onTouchEvent ACTION_DOWN which is non-standard
and causes problems when used in a ViewGroup intercepting touch events.
Switch to standard Android click handling instead which is also what most
other player apps are doing.
Issue:#5784
PiperOrigin-RevId: 245219728
Experiments show this is beneficial for rebuffers with only minor impact
on battery usage.
Configurations which explicitly set a minimum buffer duration are unaffected.
Issue:#2083
PiperOrigin-RevId: 244823642
Before this change we'd release the audio track and create a new one as soon
as audio processors had drained when reconfiguring.
Fix this behavior by stop()ing the AudioTrack to play out all written data.
Issue: #2446
PiperOrigin-RevId: 244812402
