When in REPEAT_MODE_ONE, it's unlikely apps want next/previous methods
on the player to keep them in the same window. Music apps in particular
tend to implement next/previous functionality as though repeat mode were
off when in this mode (i.e. current song loops forever during playback,
but next/previous navigation still navigates to next/previous items).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=220469655
This fixes an issue where disabling audio focus handling
while audio focus is held would not release audio focus.
A new test was added for this situation.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=220316866
*** Reason for rollback ***
Rolling forward again as [] should fix issue that prompted the rollback
*** Original change description ***
Automated g4 rollback of changelist 219130576.
*** Original change description ***
Re-enable codec re-use
Issue: #2826
***
***
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=220124362
It's no longer guaranteed that onOutputFormatChanged will always be
called when the renderer is re-enabled, since the codec may be kept
and its output format may not change. Hence we need to avoid resetting
state in onDisabled that we need when the renderer is enabled again.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=219821519
Currently, MediaCodecRenderer's render loop does not have any time limit. We
always try to drain and feed as much buffers as possible. This may lead to a
pattern of feeding phase takes too much time from previous loop, which makes
the next draining phase drops all buffers, making these buffers available for
feeding all at once, and the pattern keeps repeating.
This CL adds an experimental parameter for setting a time limit. If the time
limit is exceeded, the feeding process stops even if more input could be fed.
The default behavior is unchanged
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=219820386
This makes extractor selection a bit more efficient for some CMAF files.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=219795105
This prevents leaving an inconsistent state after a EOF exception.
Issue:#5039
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=219785275
Before this change, the player state would be STATE_ENDED then
STATE_BUFFERING (when the postroll ad was marked as played) then
STATE_ENDED again.
Queueing a final content media period with start point equal to
the content duration after a postroll ensures that the player
state doesn't change to STATE_ENDED transiently.
Switch from using C.TIME_END_OF_SOURCE to C.TIME_UNSET for media
periods that should not have an end point and are not followed
by an ad.
Content media periods before postrolls have end position
C.TIME_END_OF_SOURCE. If the postroll ad loads, its content
position is set to the content duration, which should be known
at the point of loading the postroll, then a final 'empty'
content media period with start position equal to its duration
is queued. If the postroll fails to load, this empty content
media period is queued up directly after the preceding content
media period.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=219443683
- Handling EVENT_PROVISION_REQUIRED is unnecessary because we handle
it via NotProvisionedException, which was thrown on all API levels.
- Handling EVENT_KEY_EXPIRED during playback is unnecessary. All it
does is cause an error to be thrown, but an error will be thrown
anyway out of the MediaCodec when it tries to use the expired keys.
It's currently a race condition where the error gets thrown from,
where-as having it always be thrown from one place is preferable.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=219172021
This paves the way to cleanly fix the first two issues
listed in [] onDisabled will null inputFormat,
but nulling of codecFormat will remain tied to the codec
being released.
Issue: #2826
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=219125458
ExoCastMessage contains all player management messages that the sender app can
send to the receiver app. ExoCastMessages can be serialized as JSON strings.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=218846977
- Only use bitrate when comparing two tracks if their bitrates are
actually different.
- For audio, prefer to use bitrate over selection flags.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=218660886
- Improve variable naming
- In the edge case that bytes are transferred in a sample that
has 0 elapsed time, carry the bytes forward into the next
sample. If we don't do this then the estimate will be calculated
as though those bytes were never transferred. In practice I
suspect this very rarely occurs.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=218551208
If EventDispatcher.removeListener is called to remove a listener,
and if the call is made from the same thread that said listener
handles events on, then it should be guaranteed that the listener
will not be subsequently invoked on that thread.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=218331427
In ConcatenatingMediaSource, the source may be removed before it started
preparing (this may happen if lazyPreparation=true). In this case, we
shouldn't call releaseSource as the preparation didn't start.
Issue:#4986
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=218141658
There are multiple subtle issues with the current implementation:
1. setOperatingRate can cause a codec initialization even if the
renderer is disabled. This is not supposed to happen.
2. If the codec is released whilst the renderer is disabled, the
renderer can instantiate a new codec using the old format when
it's enabled again, only to immediately have to reconfigure or
release it if the actual format to be played is different.
3. Codec reuse does not take into account renderer configuration.
The specific case where this is problematic is if the video
renderer is re-enabled with a different tunneling session id.
The reused codec is then not configured correctly.
Also moved availableCodecInfos reset into releaseCodec for sanity.
Issue: #2826
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=217924592
This is a no-op change as the respective values are not used so far but
the change makes the current state cleaner and is less error-prone.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=217892421
- Added ability to override the DefaultBandwidthMeter network type.
- These methods currently only work properly if called before the
meter is used, but the plan is for them to be handled in the same
way as internally detected network changes.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=217887019
This method only ensured backward compatibility while the new version was not
public yet. Now ExoPlayer 2.9.0. is public, this workaround can be removed.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=217881691
I don't think there's any particular reason for releasing
dummySurface when we release the codec. It seems to make
more sense to decouple the two, and treat a dummySurface as
a resource that should be released on reset.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=217711788
setSurface only sets the output surface on the codec if the
renderer is enabled or started. This was fine in the past
because the codec was always null in other states, however
the recent codec reuse work means this is no longer the case.
The output surface should always be set if the codec is
non-null. If setting the surface requires releasing the codec
instance, we should only instantiate the new instance if
enabled or started. This is in line with what onDisabled does
if flushing requires releasing the codec
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=217676434
Just not doing it seems simplier and more obviously correct
than suppressing the warnings in our proguard file.
Issue: #4890
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=217675527
1. Remove option to pass null context to Util.getNetworkType. IMO it's
clearer for the caller to just not call the method in this case.
2. Stop using deprecated DefaultBandwidthMeter.Builder constructor in
all but one place.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=217147091
The assertion was so weak it probably wouldn't detect genuine
misuse of the DefaultAllocator API, so it seems fine just to
remove it.
We don't really know what happens when the player is allowed to
continue on the affected devices, but hopefully it either "just
works" or fails in a more graceful way.
Issue: #4532
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=217113060
Robustness fix to make sure we ignore tags with known names, but
which are nested inside of unknown tags. For example we don't want
to parse the third period in:
<Period>...</Period>
<Period>...</Period>
<CustomTag>
<Period>...</Period>
</CustomTag>
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=217101630
For decoder reuse, we want disable() to flush the decoder. However,
if the flush needs to release the decoder for some reason, it seems
non-ideal to immediately re-initialize it. Re-initialization can
also throw ExoPlaybackException, which we don't want for disabling.
This change allows a variant of flush that wont re-initialize the
decoder if it has to be released, which will be used from disable().
Issue: #2826
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=216834862
reloading frmo snapshots. b/117347850. This is a no-op change as the current
default == _fullboot. When we globally flip and make snapshots the default,
these tests would fail and we are moving them over so that when we flip your
tests still pass.
https://groups.google.com[]forum/#!topic/mobile-ninjas/Y69PTAT5GyY
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=216634430
- Always clip to period duration for the last chunk. We previously
did this only when the last chunk explicitly exceeded the period
end time. We now also do it when the chunk claims to end at the
period boundary, but still contains samples that exceed it.
- If pendingResetPositionUs == chunk.startTimeUs == 0 but the
chunk still contains samples with negative timestamps, we now
clip them by setting the decode only flag. Previously we only
clipped such samples if the first chunk explicitly preceeded the
start of the period.
Issue: #4899
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=215763467
- It's a no-op for now
- Renderers that want to support retaining resources will move
some functionality from their disable() implementations into
reset()
- ExoPlayerImplInternal will be updated to not always call reset()
immediately after disable(), which is what will enable resources
to actually be retained.
Issue: #2826
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=215729783
This makes the following changes to improve consistency among the PlaybackInfo
values:
1. Update buffered position and total buffered duration after loading period
is set as both values are affected by a loading period update.
2. Add copyWithPosition to allow updating the position without resetting the
loading period.
3. Forward the total buffered duration to playing position updates
as it may have changed with the new playing position.
Issue:#4899
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=215712328
When SubtitlePainter positions the cues centred in the given box, it must add
the left offset of the box to get the correct position.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=215535289
SubtitleView forwards the cue box position to SubtitlePainter. This should be
the position relative to the canvas of the SubtitleView. Currently, however,
we forward the position relative to the parent of SubtitleView. That causes
problems if SubtitleView has a non-zero offset position to its parent.
Issue:#4788
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=215535281
This removes the experimental bandwidth meter and uses it as the new default.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=215404065
A lot of methods just forward to other methods and there is no conceivable
way a player should implement it another way. Moving these methods to a
base player class allows to remove duplicated code across our player
implementations.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=215374192
For example, using ExoPlayer.STATE_IDLE falls back to the Player.STATE_IDLE
automatically and thus there is no need to keep the deprecated members.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=215363841
If we prepare a deferred media period before the actual timeline is available,
we either prepare with position zero (= the default) or with a non-zero
initial seek position.
So far, the zero (default) position got replaced by the actual default position
(including any potential non-zero window offset) when the timeline became known.
However, a non-zero initial seek position was not corrected by the non-zero
window offset. This is fixed by this change.
Related to that, we always assumed that the deferred media period will the
first period in the actual timeline. This is not true if we prepare with an
offset (either because of an initial seek position or because of a default
window position). So, we also determine the actual first period when the
timeline becomes known.
Issue:#4873
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=215213030
These two methods are meant to indicate to the track selection that it's
started or stopped being used. This is helpful to schedule background tasks
related to track selection (e.g. register network change listeners etc.).
This intention is not clearly stated in the method docs.
Also, all track selections of all prebuffered periods stay enabled in
parallel at the moment. As the whole purpose of these methods is to know
whether dynamic updates via updateSelectedTrack may happen, it's better to
only enable track selections of the current loading media period. That's
similar to how we always forward the loading track selections to the
LoadControl.
This change:
1. Improves the JavaDoc of TrackSelection.
2. Disables track selections if loading moves to another period.
3. Reenables track selection if loading moves back to a previous period.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=215199987
Switch to the recommended way of checking whether the app is running on a TV
device.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=215177587
Extend Sony workaround up to and including Oreo.
Due to a platform issue the Display API couldn't report 1080p UI
and 4k SurfaceView support until Oreo. Since Oreo it is still
common for devices to misreport their display sizes via Display,
so this change switches to using system properties up to and
including Pie.
On Pie treble may prevent writing sys.display-size so check for
vendor.display-size instead.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=214987203
More specifically, if the parts of the Format that are used
for decoder configuration are unchanged.
Issue: #2826
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=214791234
If a source is removed from the playlist, the player may still call createPeriod
for a period of the removed source as long as the new timeline hasn't been handled
by the player. These events are stale and can be ignored by using a dummy media
source. The stale media period will be released when the player handles the updated
timeline.
Issue:#4871
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=214787090
This simplifies code skipping items in a playlist programatically.
Issue:#4863
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=214580742
This method needs to be called whenever the track selection of the current
loading period changes, but also when the loading period itself (and thus
the "loading track selection") changes. These are the same situations in which
we update the loading media period id and thus we can move both updates in
a common helper method.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=213959982
From API 23 this uses the timed format queue. Before API 23 the
format is notified as soon as the buffer is queued.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=213830729
Before this change we would reset the start trim to zero after initial
configuration (at the start of playback) and after seeking to any position. The
fact that no trimming was applied at the start of playback meant that after the
first period transition we'd see a mismatch between the next buffer timestamp
(equal to the duration of the period taking into account edits) and the duration
of audio submitted to the sink.
This change modifies the behavior so that we reset the start trim to zero only
if some audio was queued since configuration. This is incorrect in the case of
starting playback at a non-zero position, but fixes the common case of starting
at zero. As before, a later seek to any position is handled via a flush and
resets the trim as required.
Transitions from one period to the next are unaffected by this change.
One way to implement start trimming correctly would be to provide the input
buffer timestamp to the audio processors and only trim when handling audio from
the start of the stream, but that is a larger change so left for later.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=213828511
After a period transition the first buffer queued has the sum of previous period
durations added to its source presentation timestamp. These durations take into
account gapless edits, but the check on the timestamp was based on the submitted
frame count, not the frame count after trimming.
This change fixes an issue where audio/video would gradually drift apart due to
accumulated error in the audio track position, which could lead to freezing due
to the audio renderer stopping being ready and switching to the standalone media
clock.
Issue: #4559
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=213819908
Fixed and random track selection were still overriding the deprecated version
of updateSelectedTrack.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=213637728
The only use of track selection factories is as adaptive track selection factories
in the DefaultTrackSelector. Using the fixed track selection factory here is dangerous
as it will throw if more than one track is selected.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=213637500
With default of value set to -1, every single dropped frame is reported because of expression: if (droppedFrames >= maxDroppedFramesToNotify) { maybeNotifyDroppedFrames(); }
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=213502573
The decoder doesn't claim to be adaptive, but if we're staying
in the same resolution we'll try and re-use the decoder anyway.
The H264 decoder can't handle this case on the Tab 4 can't deal
with this case.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=213478378
This doesn't break apps which violate this policy. But it creates a clear
warning which is also likely to be reported in analytics tools.
Issue:#4463
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=213442510
The DefaultTrackSelector can now be constructed without leaving out a
vital part of the initialization. This allows this new simple factory method.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=213438163
Currently there is no way to disable (or reduce) the logcat output generated
by ExoPlayer.
Issue:#4665
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=213421072
This allows creating multiple HLS media sources from a single Factory, as
required by the interface.
Issue:#4814
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=213297850
ExoPlayer can be run on a background thread, but some components (UI and IMA)
only support players on the main thread. This adds some documentation and
assertions for that.
To simplify assertions, this also moves the getApplicationLooper method from
ExoPlayer to Player.
Issue:#4439
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=213280359
Kotlin will throw NPE whenever a method returns null or an interface is
called with a null parameter and the respective values are not marked as
@Nullable.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=213262886
To check the validity of a window index it needs to be compared with a greater
or equal sign to the window count.
Issue:#4822
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=213234403
Also prevent an unnecessary allocation when the removed range is empty.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=212993427
Not having this annotation may cause Kotlin implementations to fail.
Issue:#4802
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=212980643
If we can select a track that has a strictly higher score than a
selection already made for a renderer of the same type, we should
prefer it.
Issue: #4711
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=212835895
- Make addMediaSource a specific case of addMediaSources.
- Make clear a specific case of removeMediaSourceRange.
- Make removeMediaSource a specific case of removeMediaSourceRange.
- Remove the unnecessary message handling and constants.
- Move a method so that depending appears before depended.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=212809667
This allows to update the shuffle order after the ConcatenatingMediaSource
has been created. ShuffleOrder objects should be immutable to ensure thread
safety and thus there is no way to do this currently.
Issue:#4791
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=212443146
- Fixes the referenced issue.
- Provides more consistent behavior for the edge case of empty
chunks (i.e. chunks containing now samples). Format changes
will now always be reported for such chunks, unless the empty
chunk is discarded from upstream before there's a chance to
do so.
Issue: #4533
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=212443043
When the stream is changed in the audio renderer, the timestamps of the
samples can no longer be expected to match the calculations in the AudioSink.
This change tracks the samples at which the stream is changed and notifies the
AudioSink of the discontinuity.
Issue:#4559
Issue:#3829
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=212435859
When a reset is pending the sample queues normally contain pre-seek
samples (which will be emptied when a pending load is canceled). The
position passed to discard will be a post-seek position. I don't
think anything bad happened in any of the cases being changed, but
discarding is unnecessary in such cases, and reasoning about such
cases is difficult.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=212435556
- This makes it so that onDownstreamFormatChanged will occur before the corresponding
renderer event. This was not previously the case, since the renderer would typically
read the format (and report its event), then a sample (causing the
onDownstreamFormatChanged event).
- The remaining ones to update are ChunkSampleStream (DASH + HLS), which will be done
in a way that fixes#4533, and HLS.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=212434874
If there's already a pending reset, we need only update the pending
reset position. We can currently end up calling cancelLoading more
than once on the loader for the same task, which is hard to reason
about (although I don't think anything actually broke in practice).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=212432266
We currently apply the track.timescale whereas we should be applying the
track.movieTimescale. The parsing for the trak atom does this correctly
and the duration from the trak atom currently always takes precedence over the
durations from the stbl atoms as it's always larger.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=212421687
Ignoring all edit lists if they don't start with a keyframe causes A/V sync
issues when valid edit lists are applied at the beginning.
This change allows such edit lists again but removes all samples before the
first keyframe (these samples would be ignored by the renderer anyway if at
the beginning OR cause visible distortions when appended to an unrelated
keyframe).
Issue:#4774
Issue:#4348
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=212244407
- There's no particular need to read or skip a sample before notifying
- Add missing isPendingReset check
Issue: #4533
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=211959762
The default character set is always UTF-8 anyway on Android, but
we don't want our code to behave any differently where it's not
(e.g. robolectric test runs could potentially run in an environment
where UTF-8 isn't the default?).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=211953885
1. Currently, we may throw source info refresh errors while the previous media
period is still playing.
2. We don't throw if the next period in a playlist fails to prepare and the
previous renderers are all disabled.
3. We throw source info refresh errors for playlists before playback reaches
the culprit source.
This change:
1. Defers the exceptions until all existing media periods have been played.
2. Checks for period preparation exception if the next period is not
getting prepared and the renderer time reached the next period.
3. Does no longer throw from ConcatenatingMediaSource.maybeThrowSourceInfo
RefreshError. The deferred media periods take care of that for each source
individually.
Issue:#4661
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=211819436
