- 06 Feb, 2019 4 commits
-
-
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 16 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 -
Issue:#2867 PiperOrigin-RevId: 231385677
tonihei committed -
These methods take a list of languages to be downloaded and add selections for each of the languages. PiperOrigin-RevId: 231385632
tonihei committed -
The subclasses only call specific constructor combinations and can easily replaced by static methods. PiperOrigin-RevId: 231385606
tonihei committed -
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
tonihei committed -
PiperOrigin-RevId: 231385563
tonihei committed -
Currently, we remove all variants if none of the stream keys contains any variants. This causes HlsMediaPeriod to throw exceptions as it expects at least one variant. Change it to support master playlists without variants. PiperOrigin-RevId: 231385547
tonihei committed -
PiperOrigin-RevId: 231385518
tonihei committed -
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
tonihei committed -
This should be removed after releasing. PiperOrigin-RevId: 231380393
tonihei committed -
The way it is currently, it's very unclear that an operation on the version table will correctly belong to a transaction in code such as this, taken from DefaultDownloadIndex: writableDatabase.beginTransaction(); try { writableDatabase.execSQL(...); versionTable.setVersion(...); writableDatabase.setTransactionSuccessful(); } finally { writableDatabase.endTransaction(); } This change explicitly passes the database, to make it obvious that the operation will really go into the same transaction: writableDatabase.beginTransaction(); try { writableDatabase.execSQL(....); VersionTable.setVersion(writableDatabase, ...); writableDatabase.setTransactionSuccessful(); } finally { writableDatabase.endTransaction(); } PiperOrigin-RevId: 231374933olly committed -
PiperOrigin-RevId: 231223201
eguven committed
-