This includes only the (hopefully) non-debatable changes for the DASH module
and all needed changes for call into the core library.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=195097791
A single master version prevents app developers from providing
custom download functionality (because they can't increment the
version). It's also error prone to expect someone modifying the
DASH action to remember to update the ActionFile master version.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=194981886
This was adding a lot of code, and the multiple use cases
for Downloader was pretty confusing (in particular the
ordering of method calls was unclear). It's also not
performant (e.g. it requires loading/parsing manifest(s)
and initialization segments from disk).
In practice I think apps will need to keep a record of
what's offlined in their app's database (or equivalent),
which they can update by registering as a listener on
DownloadManager. This will be done for the demo app in
a subsequent change.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=194932876
- It's much cleaner to split completed/error notification methods.
- Make error notification show the content title in the demo app.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=194920507
This change is intended to resolve overloading of "Download",
where a DownloadTask could be an actual download task, or a
remove task.
Also cleaned up some documentation.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=194815058
- Redefine Scheduler interface to better describe what implementations
do. The previous version was too general, in that it allowed concrete
DownloadService implementations to pass different Requirements to
the base class and to the Scheduler. It's also difficult to see how
that version could ever support dynamic updates to Requirements, which
is probably a feature we'll need to add quite soon.
- Fix a (probably theoretical) problem where static fields in
DownloadService assumed only a single concrete implementation.
- Stop using PlatformScheduler pre-API-21 in demo app, because it will
fail.
- Define default Requirements that require network.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=194785751
- When calculating the downloaded percentage in DASH, there was no
way to disambiguate between 0 of 0 segments being downloaded because
there are no cached indexes (i.e. 0% downloaded) and 0 of 0 segments
being downloaded because the index defines 0 segments (i.e. 100%
downloaded).
- Also replace use of NaN with a named constant.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=194453202
When we play downloaded content, we rely on the manifest filters
to produce a manifest that contains only the content that was
downloaded. It makes sense just to use the same filters during
download too, so we don't have to worry about any implementation
differences.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=194380704
ProgressiveDownloader never implemented this properly, and we
don't use it in DownloadManager/DownloadService, both of which
use a polling model. A polling model is also what's used elsewhere,
for example to query the current playback position.
This is effectively doing the TODO in ProgressiveDownloader.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=194214579
This removes a fair chunk of code. The line delta would
be more negative if it not for adding all the /* x= */
comments in DashDownloadActionTest!
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=194136689
This makes DownloadService easier to use in general and when only single
notification is used for all downloads.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=193165982
These don't seem to be needed anymore. All tests run without them in gradle
and Blaze.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=191867518
This field (formerly "id") is almost impossible to use so far. Having setters
in the factories allows to specify custom tags for all media sources.
Also added a ExoPlayer.getCurrentTag() method to retrieve the tag of the
currently playing media source in a convenient way.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=191738754
We currently refresh repeatedly in this case. According to the
DASH spec omitting minUpdatePeriod indicates that the manifest
does not change, and therefore we should not refresh. I think
it might be valid to omit minUpdatePeriod in a dynamic manifest
if relying exclusively on EMSGs to trigger manifest refresh.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=191420247
This change enables feeding decoders from the closest sync frame
before a specified seek position, where-as previously we'd
always feed decoders from the start of the chunk. This avoids
decoding and discarding many audio samples during each seek. The
same benefit also applies to video chunks containing more than
one key-frame.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=190539547
This adds callbacks for creating, releasing, and starting to read from media
periods.
Such events allow listeners to keep a list of active media periods. This is
useful to determine when no further events for a certain media period are
expected. It also allows listeners to associate renderer events unambigiously
with a reading media period.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=190462717
Also convert left side from milliseconds to microseconds for comparison
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=189784833
This allows to distinguish between media source events of multi-window and
multi-period media sources. In this change, only media sources currently reporting
events are changed. Proper support in composite sources will be added in a later
change.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=188847366
This is achieved by moving the listener registration and the creation of the
event dispatcher into BaseMediaSource.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=188461932
- Change 'compile' configuration (deprecared) to using 'implementation'
and 'api' configurations instead.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=187311778
This is achieved by adding a BaseMediaSource which keeps a reference count of the
number of times the source has been prepared and forwards to the actual implementations
only once, such that only minimal changes are needed for each media source.
Issue:#3498
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=187186691
The util package is, in practice, for things that are misc enough
to not warrant their own package. If something is deserving of a
package, it's IMO best placed somewhere else (I know you could
argue it's a util, but you could argue that about almost anything
else as well).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=187010018
Releasing the player released the internal playback thread once renderers were
released. Releasing a MediaPeriod queued a Loader.ReleaseTask on the loading
thread which would post back to the playback thread. If the playback thread had
been quit by the time this happened, the release task wouldn't be run.
Release on the loading thread instead of the playback thread. This avoids
needing to block releasing the player until the loading threads have ended, and
ensures that release tasks will run eventually. As part of this change,
ExtractorMediaPeriod's call to Extractor.release will now run on the loading
thread (which means that all Extractor methods are called on that thread) and
other cleanup in ReleaseCallback will run on the loading thread instead of the
playback thread.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=185651320
Lint recommends switching to SparseArray<X> instead.
This is done for the DASH case. For the Cast case it's
easier to use a switch statement.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=184119312
This is only allowed for user-replaced manifest uris. If the manifest
itself forwards to another manifest, we keep the original manifest in
case the forwarding changes.
Also removed the initialManifest as it can be simplified by using the
sideloadedManifest indicator.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=183376209
These parsers can be used to get a manifest which includes only the
representations identified by the given keys.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182932874
This achieves two things:
1. All our tests use the same type of assertions.
2. The tests currently run as instrumentation test can be moved to
Robolectric without changing the assertions.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182910542
When a loaded DASH manifest is invalid (either some periods were removed
illegally, or a manifest for a live event is stale), we will retry using 1
logic:
- Retry loading with back-off up-to a limit.
- Throw a DashManifestExpiredException() if we exceed retry limit.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182770028
