Apps need to set the target compatibility to VERSION_1_8 to enable the
automatic desugaring if they haven't done so already.
Issue:#4907
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=215733070
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
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
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 simplifies code skipping items in a playlist programatically.
Issue:#4863
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=214580742
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
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
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
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
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
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
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
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
- Try and put things into a vaguely sane order
- Remove/simplify overly-detailed release notes
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=211447350
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
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
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
The response headers of the last load are available from the loading source
when creating media source events and can be easily forwarded.
Issue:#4361
Issue:#4615
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=209900693
When playing a playlist where the exact maximum input size is known from the
container for each item, it may be necessary to recreate the decoder to increase
its maximum input buffer size at the point of transitioning from one item to the
next, which can make transitions non-seamless.
Scale up the initial video decoder maximum input size so playlist item
transitions with small increases in maximum sample size don't require
reinitialization.
Issue: #4510
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=208650244
