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
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
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
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
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
- 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
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
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
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 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
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
To report DRM session metrics in the future as part of the listener, we need
a callback at the end of the drm session to get the final metric state.
For completion, the session acquired callback is also added.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=211328412
Also make some javadocs more consistent with the rest of the library.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=211071559
The current structure tries to associate events to media periods and windows
based on the reported values and the current timeline. However the reported
EventTime may not always be consistent in case the timeline doesn't contain
windows or media periods yet or not anymore.
The recent changes to MediaPeriodId allow to use it as a unique identifer for
media periods independent of the timeline. This enables more accurate tracking
of the media period queue and prevents reporting events with inconsistent
data.
Issue:#4492
Issue:#4634
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=210713120
This provides the list of currently buffered media chunks and iterators over
the potential next chunks to the track selection. Having these two parameters
enables more advanced decision logic based on this data.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=210551812
This fixes or suppresses all reported issues by the code review linter tools.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=210107759
There are C.CLEARKEY_UUID.equals(uuid) checks in FrameworkMediaDrm,
so uuid needs to be CLEARKEY_UUID, not COMMON_PSSH_UUID
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=210094372
- Add @Deprecated on overrides of deprecated method.
- Suppress deprecation warnings where appropriate.
- Use non-deprecated alternatives where appropriate.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=210092434
This prevents problems caused by unintended double-registration of the same
transfer listener.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=210078454
This option is currently not available as a non-null adaptive track selection
has to be provided. Adds a parameter "forceHighestSupportedBitrate" which
corresponds to the default fixed track selection for audio and video.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=210073675
At the point of starting to play a postroll, source info refreshes for future
postroll ads in the same ad group would cause a seek that incorrectly identified
the media period to play as the content media period. Fix the logic in
getAdGroupIndexForPositionUs to address this.
Also handle empty postroll ad breaks by resetting the expected ad group index
when we send content complete.
Issue: #4710
Issue: #4681
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=210071054
