We already allow mixed mime type and mixed sample rate adaptation on request,
so for completeness, we can also allow mixed channel count adaptation.
Issue:#6257
PiperOrigin-RevId: 261930046
If we keep streams in chunk sources after selecting new tracks, we also keep
a reference to a stale disabled TrackSelection object. Fix this by updating
the TrackSelection object when keeping the stream. The static part of the
selection (i.e. the subset of selected tracks) stays the same in all cases.
Issue:#6256
PiperOrigin-RevId: 261696082
A previous change switched to calculation of the bitrate based on the
first MPEG audio header in the stream. This had the effect of fixing
seeking to be consistent with playing from the start for streams where
every frame has the same padding value, but broke streams where the
encoder (correctly) modifies the padding value to match the declared
bitrate in the header.
Issue: #6238
PiperOrigin-RevId: 261163904
This factory was only needed in the past when we didn't have
AnalyticsCollector.setPlayer. Code becomes easier to use without this factory.
PiperOrigin-RevId: 261081860
This changes the logic in the following ways:
- If no preferred language is matched, prefer better scores for the selected
audio language.
- If a preferred language is matched, always prefer the better match
irrespective of default or forced flags.
- If a preferred language score and the isForced flag is the same, prefer
tracks with a better selected audio language match.
PiperOrigin-RevId: 259707430
1. Using the Locale on API<21 doesn't make any sense because it's a no-op
anyway. Slightly restructured the code to avoid that.
2. API<21 often reports languages with non-standard underscores instead of
dashes. Normalize that too.
3. Some invalid language tags on API>21 get normalized to "und". Use original
tag in such a case.
Issue:#6153
PiperOrigin-RevId: 258773463
2-letter codes (ISO 639-1) are the standard Android normalization and thus we
should prefer them to 3-letter codes (although both are technically allowed
according the BCP47).
This helps in two ways:
1. It simplifies app interaction with our normalized language codes as the
Locale class makes it easy to convert a 2-letter to a 3-letter code but
not the other way round.
2. It better normalizes codes on API<21 where we previously had issues with
language+country codes (see tests).
3. It allows us to normalize both ISO 639-2/T and ISO 639-2/B codes to the same
language.
PiperOrigin-RevId: 258729728
If we use the default start position, we currently resolve it immediately
even if we need to play an ad first, and later try to project forward again
if we believe that the default start position should be used.
This causes problems if a specific start position is set and the later
projection after the preroll ad shouldn't take place.
The problem is solved by keeping the content position as TIME_UNSET (= default
position) if an ad needs to be played first. The content after the ad can
then be resolved to its current default position if needed.
PiperOrigin-RevId: 258583948
These methods helps to indicate that a media source isn't used to create new
periods in the immediate term and thus limited resources can be released.
PiperOrigin-RevId: 258373069
- Remove manifest argument from callbacks of Player.EventListener and
SourceInfoRefreshListener. Instead make it accessible through
Player.getCurrentManifest() and Timeline.Window.manifest.
- Fix all MediaSource implementation to include the manifest in the
Timeline instead of passing it to the SourceInfoRefreshListener.
- Refactor ExoPlayerTestRunner, FakeTimeline, FakeMediaSource to
reflect these changes and make tests pass.
PiperOrigin-RevId: 257359662
We currently handle most the control code logic after handling special
characters. This includes filtering out repeated control codes and checking
for the correct channel. As the special character sets are control codes as well,
these checks should happen before parsing the characters.
Issue:#6133
PiperOrigin-RevId: 256993672
Currently, we sometimes apply new playback parameters directly and sometimes
through the list of playbackParameterCheckpoints. Only when using the checkpoints,
we also reset the offset and corresponding position for speedup position
calculation. However, these offsets need to be changed in all cases to prevent
calculation errors during speedup calculation[1].
This change channels all playback parameters changes through the checkpoints to
ensure the offsets get updated accordingly. This fixes an issue introduced in
31911ca54a.
[1] - The speed up is calculated using the ratio of input and output bytes in
SonicAudioProcessor.scaleDurationForSpeedUp. Whenever we set new playback
parameters to the audio processor these two counts are reset. If we don't reset
the offsets too, the scaled timestamp can be a large value compared to the input
and output bytes causing massive inaccuracies (like the +20 seconds in the
linked issue).
Issue:#6117
PiperOrigin-RevId: 256533780
1. Only output video starting from a keyframe
2. When calculating the timestamp offset to adjust live streams to start
at t=0, use the timestamp of the first tag from which a sample is actually
output, rather than just the first audio/video tag. The test streams in
the referenced GitHub issue start with a video tag whose packet type is
AVC_PACKET_TYPE_SEQUENCE_HEADER (i.e. does not contain a sample) and whose
timestamp is set to 0 (i.e. isn't set). The timestamp is set correctly on
tags that from which a sample is actually output.
Issue: #6111
PiperOrigin-RevId: 256147747
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
