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
