- 18 Feb, 2019 1 commit
-
-
They may prepare immediately and let pendingMediaPeriods become empty before all other periods are even created. PiperOrigin-RevId: 232675283
tonihei committed
-
- 06 Feb, 2019 14 commits
-
-
PiperOrigin-RevId: 232670039
olly committed -
Also removed STOP_FLAG_DOWNLOAD_MANAGER_NOT_READY. PiperOrigin-RevId: 232669463
eguven committed -
When SimpleCache uses a CacheFileMetadataIndex, it will be able to avoid querying file.length() and renaming files, both of which are expensive operations on some file systems. PiperOrigin-RevId: 232664255
olly committed -
Issue: #4253 PiperOrigin-RevId: 232659869
olly committed -
PiperOrigin-RevId: 232651944
andrewlewis committed -
Now we're reusing the builder, it's necessary to set maxProgress back to 0 to avoid the progress bar appearing for end state notifications. PiperOrigin-RevId: 232520007
olly committed -
PiperOrigin-RevId: 232507469
andrewlewis committed -
After this change, multiple HlsSampleStreamWrappers may contain an apdaptive track group. PiperOrigin-RevId: 232507292
aquilescanta committed -
onContinueLoadingRequested can occur during preparation, so MediaPreparer needs to handle it. PiperOrigin-RevId: 232507267
olly committed -
Issue: #5476 PiperOrigin-RevId: 232503736
andrewlewis committed -
On KitKat you need to reuse the same notification builder when generating a notification that's intended to replace a previous one. See: https://stackoverflow.com/questions/6406730/updating-an-ongoing-notification-quietly PiperOrigin-RevId: 232503682
olly committed -
DefaultDownloadIndex is currently just forwarding all calls to its inner class. getDownloadTable() handles initialization, but this doesn't really seem different to having an initialization method. It doesn't guarantee initialization happens, since a bad method implementation could try and access downloadTable directly, just as a bad method implementation could forget to call the initialization method. Hence this change removes the indirection. PiperOrigin-RevId: 232482228
olly committed -
PiperOrigin-RevId: 232481580
olly committed -
This method is needed by DownloadManager. PiperOrigin-RevId: 232447145
eguven committed
-
- 04 Feb, 2019 9 commits
-
-
Imported from GitHub PR https://github.com/google/ExoPlayer/pull/5462 Pull request for the following issue: #5421 Merge d9d88b079c4ca0533a836b2715a65b924babbb89 into a7381916 PiperOrigin-RevId: 232335113
olly committed -
This combines all the different listeners in ExoVideosPlayerV2 into one and moves the PlaybackLogger class towards ExoPlayer's AnalyticsCollector with the same purpose. In the future this allows two things: 1. Gradually move LogginClient implementations to AnalyticsListener to prevent custom event forwarding. 2. Using ExoPlayer's QoE extension (which is also an AnalyticsListener). PiperOrigin-RevId: 232321182tonihei committed -
When calling releaseSource(), all pending messages will be removed. That means that all action-on-completion callbacks which are somewhere in flight are just dropped without being called. This change adds code to keep track of the current state of each callback to allow all of them being called when the source is released. Issue:#5464 PiperOrigin-RevId: 232312528
tonihei committed -
The Util class already handles removeMessages calls but so far ignored calls to removeCallbacksAndMessages. PiperOrigin-RevId: 232312458
tonihei committed -
DownloadTracker will stop updating DownloadIndex when DownloadManager starts using the same DownloadIndex. PiperOrigin-RevId: 232306803
eguven committed -
This change enables transitioning to/from different Storage implementations, to allow experimentally enabling (and if necessary, disabling) SQLiteStorage. All that's left to do is the final wiring to turn it on PiperOrigin-RevId: 232304458
olly committed -
Issue: #4519 PiperOrigin-RevId: 232299233
olly committed -
Now DownloadManager is responsible for starting and stopping DownloadThreads. PiperOrigin-RevId: 232278072
eguven committed -
PiperOrigin-RevId: 231801562
aquilescanta committed
-
- 31 Jan, 2019 4 commits
-
-
PiperOrigin-RevId: 231772920
andrewlewis committed -
PiperOrigin-RevId: 231764284
aquilescanta committed -
Issue: #4468 PiperOrigin-RevId: 231759438
olly committed -
PiperOrigin-RevId: 231744540
olly committed
-
- 30 Jan, 2019 7 commits
-
-
PiperOrigin-RevId: 231644908
olly committed -
Including ParametersBuilder and TrackSelectionOverride. PiperOrigin-RevId: 231609249
aquilescanta committed -
PiperOrigin-RevId: 231600104
olly committed -
PiperOrigin-RevId: 231586206
eguven committed -
PiperOrigin-RevId: 231578828
andrewlewis committed -
PiperOrigin-RevId: 231567138
aquilescanta committed -
PiperOrigin-RevId: 231425073
olly committed
-
- 29 Jan, 2019 5 commits
-
-
If there is data after the last samples in the container, we may request continue loading after the last samples have been read but before the load has completed. In this situation the buffered position is returned as Long.MAX_VALUE, which prevents continuing loading, yet the media period is not treated as fully buffered because its buffered position is not C.TIME_END_OF_SOURCE. PiperOrigin-RevId: 231406964
andrewlewis committed -
We can keep the reading media period and continue playing if we haven't read beyond the new duration. Otherwise, we can keep the period, but need to reset the renderers as we already read too far. PiperOrigin-RevId: 231406252
tonihei committed -
PiperOrigin-RevId: 231396213
olly committed -
On older API levels it's also necessary to implement openOrCreateDatabase, to be called by SQLiteOpenHelper. PiperOrigin-RevId: 231387559
olly committed -
It better describes what the class does. More importantly, we've had inconsistent class names since we added offline support, for which we added ProgressiveDownloader ("ExtractorDownloader" doesn't make any sense). We could really do with aligning the names for clarity. (Sorry) PiperOrigin-RevId: 231387268olly committed
-