We are currently defaulting to targetSdk=1 as no targetSdk is specified. Only
tests which explicitly ask for another SDK use another test SDK. With the
versioned manifest, all tests run using the targetSDK by default.
PiperOrigin-RevId: 249060796
- Listener based reporting of progress allows the content length
to be persisted into the download index (and notified via a
download state change) as soon as it's available.
- Moved contentLength back into Download proper. It should only
ever change once, so I'm not sure it belongs in the mutable part
of Download.
- Made a DownloadProgress class, for naming sanity.
PiperOrigin-RevId: 244242487
ShadowLooper -> ShadowLegacyLooper
ShadowRealisticLooper -> ShadowPausedLooper
ShadowBaseLooper -> ShadowLooper
And all public methods from ShadowLegacyLooper get pushed up to ShadowLooper
Pull Request: https://github.com/robolectric/robolectric/pull/4868
Copybara: OK
Also adjust Google3 tests using custom looper shadows where necessary.
Convert exoplayer to paused looper to eliminate reliance on custom shadows
PiperOrigin-RevId: 243839311
The old domain automatically forwards to the new one. For consistency, change
all doc and code references regardless.
Also adds GitHub CNAME config file which configures our page for the custom
domain.
PiperOrigin-RevId: 243592110
If the returned retry delay is unset, we should use a DONT_RETRY_FATAL action
instead and dispatch the event with the "canceled" flag.
PiperOrigin-RevId: 243251554
Both manifest loads currently use the default retry delay although a
LoadErrorHandlingPolicy is provided to the MediaSource.
PiperOrigin-RevId: 242852672
- Fix ID being dropped when DownloadAction is serialized and
de-serialized as it's passed to DownloadService
- Properly set DownloadAction.id when building an action from
a DownloadState
- Make ID a required constructor argument. Else it's too easy
to not propagate it by accident.
PiperOrigin-RevId: 242457831
This replaces the deprecated usages of RobolectricTestRunner and
RuntimeEnvironent and fully migrates the tests to androidx.
PiperOrigin-RevId: 238011667
This requires to prepare the media source and the periods in a small helper similar
to the metadata retriever. It also gets rid of the need to have abstract protected
methods to load the manifest, to extract the track groups and to convert to stream keys,
as this can now be handled by the media period.
PiperOrigin-RevId: 231385590
Converting a single track selection to stream keys is only possible if the output
is independent from other track selections being made.
This is not the case for DASH and HLS embedded track groups which should select the
already selected primary track if possible (and thus needs to know whether a primary
track group is selected).
Also, update the test method to take a period index.
PiperOrigin-RevId: 231385490
That's the same position set in MediaPeriod.prepare (where it may be removed
in the future).
Having the position at an earlier point is necessary to fix an
issue with lazy preparation in ConcatenatingMediaSource where the prepare
position was assumed to be known but MediaPeriod.prepare hasn't been called
yet.
Issue:#5350
PiperOrigin-RevId: 229756637
They are not longer needed anywhere, are error-prone (because of threading
requirements), and complicate testing and using MediaSources without a player.
PiperOrigin-RevId: 227871157
- Enable GZIP for media playlist + encryption key chunk requests in
HLS, as we do during playback
- Pass around DataSpecs rather than Uris. This will be needed for if
we add manifest cacheKey support (which seems like a good idea for
completeness, if nothing else)
PiperOrigin-RevId: 224057139
Moving most of the logic to the base DownloaderHelper helps to implement track
selection for downloading in a single place instead of multiple places.
PiperOrigin-RevId: 223964869
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
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
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
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
