- 04 Jun, 2020 3 commits
-
-
This change makes the media item of Timeline.Window non-null by providing a fallback media item in window.set(...). After having migrated all media sources this should not be needed anymore, but a fallback makes it more safe than just making the mediaItem argument of window.set(...) non-null (which is done in a following CL in this chain of CLs). PiperOrigin-RevId: 314527983
bachinger committed -
This allows to handle the last segment retrieval and process the case where the filename is null in the method. PiperOrigin-RevId: 314512974
kimvde committed -
PiperOrigin-RevId: 314508481
kimvde committed
-
- 02 Jun, 2020 10 commits
-
-
Issue: #6901 PiperOrigin-RevId: 314418536
olly committed -
Issue: #7456 PiperOrigin-RevId: 314408767
olly committed -
Issue:#7325 PiperOrigin-RevId: 314321914
aquilescanta committed -
Before loading a new chunk, the player will call reevaluateBuffer anyway, so we don't have to do this directly after cancelation. This simplifies some logic because we can remove the pending queue size variable. PiperOrigin-RevId: 314313268
tonihei committed -
PiperOrigin-RevId: 314304928
olly committed -
Extractor#sniff() javadoc says: "If true is returned, the input's reading position may have been modified. Otherwise, only its peek position may have been modified." https://exoplayer.dev/doc/reference/com/google/android/exoplayer2/extractor/Extractor.html#sniff-com.google.android.exoplayer2.extractor.ExtractorInput- PiperOrigin-RevId: 314296922
ibaker committed -
This will allow to use the file extension in DefaultExtractorsFactory. PiperOrigin-RevId: 314296640
kimvde committed -
#exo-offload PiperOrigin-RevId: 314288300
krocard committed -
If no deprecated methods on the factory is called, the media item instance that is passed to the createMediaSource method must be passed down to the constructor of the media source. PiperOrigin-RevId: 314193865
bachinger committed -
Issue: #5978 PiperOrigin-RevId: 314175257
olly committed
-
- 01 Jun, 2020 2 commits
-
-
Merge pull request #6861 from chrisfillmore:feature/responseBodyForInvalidResponseCodeException_6853 PiperOrigin-RevId: 314105612
Ian Baker committed -
PiperOrigin-RevId: 314100932
andrewlewis committed
-
- 29 May, 2020 14 commits
-
-
PiperOrigin-RevId: 313806075
olly committed -
PiperOrigin-RevId: 313804207
Oliver Woodman committed -
Issue: #5978 PiperOrigin-RevId: 313802629
olly committed -
This change applies the same approach of handling tag/streamKeys from factories like in the SmoothStreaming and Hls factories. It is functionally equivalent but improves readability. PiperOrigin-RevId: 313771318
bachinger committed -
I was trying to understand why this isn't always checked and didn't realise there was already a bug tracking this - this way a future confused reader knows something isn't working quite as intended. PiperOrigin-RevId: 313765935
ibaker committed -
PiperOrigin-RevId: 313630376
olly committed -
This fixes an issue where the output track's sample format is null for rawCC captions when endTracks method is called. PiperOrigin-RevId: 313622631
olly committed -
PiperOrigin-RevId: 313605791
bachinger committed -
PiperOrigin-RevId: 313596831
tonihei committed -
If the sample times don't overlap and are independent, splicing makes no difference because all samples (starting from the first one, which must be a keyframe) will be appended to the end of the queue anyway. PiperOrigin-RevId: 313594372
tonihei committed -
PiperOrigin-RevId: 313573424
bachinger committed -
PiperOrigin-RevId: 313566474
olly committed -
PiperOrigin-RevId: 313556143
tonihei committed -
PiperOrigin-RevId: 313481722
olly committed
-
- 28 May, 2020 1 commit
-
-
Joris de Groot committed
-
- 27 May, 2020 10 commits
-
-
We aim to have the same media item instance published in the timeline that is passed to the createMediaSource(mediaItem) method. This means when the manifest uri is manually replaced by a developer, the media item published in the next timeline update is still the same. Note: This leads to the fact that the manifest published in that timeline is loaded from a different URI than the URI of the media item in the same timeline. PiperOrigin-RevId: 313375421
bachinger committed -
PiperOrigin-RevId: 313372995
Oliver Woodman committed -
A future implementation will depend on MediaParser. PiperOrigin-RevId: 313367998
aquilescanta committed -
- The new CacheWriter is simplified somewhat - Blocking on PriorityTaskManager.proceed is moved out of CacheWriter and into the Downloader tasks. This is because we want to shift only the caching parts of the Downloaders onto their Executors, whilst keeping the blocking parts on the main Downloader threads. Else we can end up "using" the Executor threads indefinitely whilst they're blocked. Issue: #5978 PiperOrigin-RevId: 313222923
olly committed -
I skipped it where it didn't make sense (e.g. singleton lists, or lists where all elements are identical). PiperOrigin-RevId: 313217398
ibaker committed -
Add an `_` in long constants. Eg: 10000 => 10_000. I'm proposing this change because I have had multiple missread due to confusing the number of 0 in a long number. More specifically, added an underscore to all number matching: `final.*\ [0-9]{2,}000;` PiperOrigin-RevId: 313186920krocard committed -
The test was flaky because it didn't wait for pending commands to finish after pausing the test playback. Also add more debug information to the toString() method because the expected and actual state only differed in the nextAdGroupIndex in the flaky case. PiperOrigin-RevId: 313175919
tonihei committed -
PiperOrigin-RevId: 313171970
tonihei committed -
Sometimes it's useful to be able to block until something on some other thread "really has finished". This will be needed for moving caching operations onto the executor in Downloader implementations, since we need to guarantee that Downloader.download doesn't return until it's no longer modifying the underlying cache. One solution to this is of course just to not interrupt the thread that's blocking on the condition variable, but there are cases where you do need to do this in case the thread is at some other point in its execution. This is true for Downloader implementations, where the Download.download thread will also be blocking on PriorityTaskManager.proceed. Arranging to conditionally interrupt the thread based on where it's got to is probably possible, but seems complicated and error prone. Issue: #5978 PiperOrigin-RevId: 313152413
olly committed -
Every timeline refresh currently assumes that it corresponds to a manifest refresh and issues the respective load events. However, there are other timeline updates that don't have a manifest refresh (e.g. ad state updates)and thus shouldn't issue these events. PiperOrigin-RevId: 313150489
tonihei committed
-