We currently fail the entire playback tests if we exceed a start timeout
or the test gets stopped forcefully. This is problematic as the start timeout
may happen from time to time for the ABR tests and we'd still like to have the
remaining playbacks.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=222406639
The input.getLength() check is invalid because the length may be
unknown (i.e. if the server doesn't include a Content-Length
response header when serving chunks).
Issue: #5063 (tangentially related only)
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=222406347
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
This allows to account for bandwidth used by fixed track selections.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=222383736
BandwidthProvider allows bandwidth allocation logic to be customized.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=222293581
1. Pull up all subclasses of DownloadAction into DownloadAction
2. Add DownloaderFactory for Downloader instantiation, and DefaultDownloaderFactory
to replace the instantiation logic being removed from the DownloadAction
subclasses.
This change will upgrade existing action files gracefully (i.e. it does not
lose compatibility with the existing offline implementation, other than some
minor breaking changes to the API).
TODOs:
1. Move test methods from the XDownloadActionTest classes into DownloadActionTest.
This will be done in a subsequent CL. There's a lot of consolidation that can
be done here, including de-duplicating some of the test code added in this CL.
2. Look at merging DownloaderConstructorHelper into DefaultDownloaderFactory.
3. Use customCacheKey in DASH/HLS/SS Downloaders, for completeness.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=222258983
createTrackSelections decides whether to create an adaptive or a fixed track seletion to create.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=222231011
Forwarding the listeners to the notification update is meant to ensure we
only notify the listeners which were registered at the time the event happened
However, we currently just copy the reference to the actual list instead of
doing a deep copy of the listeners.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=222227735
This ensures that all callbacks use the same notification mechanism.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=222226913
The update is actually unrelated and putting it all in one large update
object complicates adding the same update mechanism for other values.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=222226825
WindowedTrackBitrateEstimator, uses future and past chunks in a window
of time to estimate track bitrate values.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=222065409
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
LegacyVideoTrackSelection is the previous implementation (unchanged).
VideoTrackSelection is rewritten to extend AdaptiveTrackSelection.
An experiment is added to allow use of the new VideoTrackSelection
implementation. It's envisaged that this transition will be more or
less a no-op change. The experiment flag is only in case of bugs
during roll-out, and will be removed with LegacyVideoTrackSelection
upon successful transition.
VideoTrackSelection also implements discard-on-trick-play-exit, which
was a TODO in the previous implementation.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=221153827
- This brings it in line with PlayerControlView. The play action is displayed
instead, and pressing it seeks to the default position of the current window.
- Do the same for MediaSessionConnector
- Add support for PlaybackPreparer consistent with PlayerControlView
Issue: #5072
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=221076008
The extension cannot be used without also using support-media-compat
(e.g. to instantiate a MediaSessionCompat). So it may as well be an
API dependency.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=221072128
This change also paves the way for splitting out functionality into a utility class.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=221070262
- Make MediaSessionConnector use a ControlDispatcher and add setControlDispatcher,
setFastForwardIncrementMs and setRewindIncrementMs methods. This brings it in line
with our other UI components, including PlayerControlView and
PlayerNotificationManager.
- Collapsed DefaultPlaybackController into MediaSessionConnector, since I'm not
sure there's a legitimate alternative implementation (note ControlDispatcher does
provide some equivalent functionality e.g. to modify calls being made on the
player).
- Pass the Player and ControlDispatcher to command receivers and custom actions,
so they don't need their own references.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=220822082
- Simplify logic for dispatching to the rating callback
- Simplify CommandReceiver by removing getCommands. Simply calling
receivers is simpler, and more flexible because it doesn't force
implementations to define a static set of things that they handle
up front.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=220788423
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
