We already have tests for comment blocks, and they already
pass because we discard the comment when we fail to parse it
as a cue. We should just skip it directly, however.
This allows more efficient range removals and is consistent with addition,
which supports adding multiple elements in a single operation.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=222396310
Currently no path may be chosen if
minBufferUs == maxBufferUs == bufferedDurationUs.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=221639199
This is needed because the allocator can't be reused for example.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=221638233
- Increase the search window size to fix TS seeking for problematic
media we've had provided to us.
- As per my comments on the issue, we should look at doing more here
to better fix the problem. This will solve the worst of the
immediate problem, however.
- The memory usage is non-trivial, particularly with the increased
search window size. I've made the allocations only live whilst
determining duration and seeking to address this. I've done the same
for PS just for consistency.
Issue: #5097
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=221449988
The remaining work is to split Window.isDynamic so that it's
possible to represent a window that wont be appended to, but
may still be removed from.
Issue: #4780
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=221439220
This is a precursor for fixing the ref'd issue. These classes are
well tested, so the tests passing should give you reasonable
confidence I didn't break anything :).
Issue: #5097
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=221435824
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
This prevents leaving an inconsistent state after a EOF exception.
Issue:#5039
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=219785275
This simplifies code skipping items in a playlist programatically.
Issue:#4863
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=214580742
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
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
