A remove action will eventually just be the unique ID of the download
that should be removed. This is a step toward that goal.
PiperOrigin-RevId: 222832456
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
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
- 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
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
They don't need to be accessed publicly and are can be moved into the
respective chunk sources. This is the same structure used for Dash.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=209507217
The MediaPeriodId with index is only properly defined together with a
timeline containing the index. Changing it to the period uid allows to use
the MediaPeriodId independent of the corresponding timeline.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=209430257
All known instances use DataSource as generic type and thus code can be simplified
by removing the generic type altogether.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=205798542
As the manifest and media data sources can be the same now, we can provide
a simplified constructor with just one data source factory.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=205658046
This wires up recent changes of passing a transfer listener to the MediaSource and
allowing DataSources to accept new listeners.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=203280818
This allows to iterate through the available chunks of the stream.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=203105813
This allows to use this queue in the track selection in the future.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=202954871
In the future, this allows to register the BandwidthMeter (managed by the player)
as a listener to all media transfers related to this media source.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=202643946
This url is readily available when creating media source events (from the
data source) but so far not published to external listeners. This change
adds a new field to LoadEventInfo which corresponds to DataSource.getUri().
Issue:#2054
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=202459049
Also moved shared code to SegmentDownloadAction between its subclasses.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=202294880
The helper method only reported DATA_TYPE_UNKNOWN even if the actual type
is known.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=200067296
If a MediaPeriod uses a Loadable, then there are typically
reference chains of the form:
LoadingThread[GCroot]->Loadable->MediaPeriod->Player
Where the player is the MediaPeriod callback. When the
player is released, this reference chain prevents the
player from being GC'd until Loadable cancellation
completes, which may not always be fast. This in turn
will typically prevent the application's activity from
being GC'd, since it'll normally be registered as a
listener on the player (directly or indirectly via
something like a view).
This change mitigates the issue by removing references
that the MediaPeriod holds back to the player. The
MediaPeriod will still not be eligible for GC, but the
player and application activity will be, which in most
cases will be most of the leak (in terms of size).
Issue: #4249
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=199143646
The lint error suppression only works locally and not for external developers
who still see the lint error and need to suppress it themselves.
This changes 'implementation' to 'compileOnly' in gradle to prevent the
dependency from being exported. Also removes the local lint suppression.
Issue:#4234
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=196251407
This is useful to get hold of the manifest to then obtain DRM init data in
the download flow for protected content (without having to download the
manifest again).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=196168938
Also convert them to exposing periods and track groups, like
regular MediaSources do. This gets us much closer to being
able to use standard track selection components during offline
initialization. The helper is responsible for reverse mapping
selected tracks onto physical streams when generating the
download action. This is trivial except for the HLS case, which
is a TODO for now.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=195500826
This may be preferable for using custom binary data,
and it's still easy to store Strings if needed.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=195486817
- Made parts of DownloadActions public that were previously hidden.
This is necessary so that when an app is listening to the
DownloadManager, it can tell something about the tasks.
- Simplified DownloadActivity some more. The helpers may migrate
into their corresponding modules at some point, and also be
converted to return structured TrackGroupArrays rather than a
flat list of Formats.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=195269824
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
- 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
