- 04 Dec, 2017 15 commits
-
-
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=177184331
tonihei committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=177175377
andrewlewis committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=177173618
olly committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=177170994
aquilescanta committed -
This allows to keep the state synced with ExoPlayerImpl after stopping the player, but still releases the media source immediately as it needs to be reprepared. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=177167980
tonihei committed -
- Align class summary Javadoc - Fix ErrorProne + Style warnings ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=177165593
olly committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=177146923
aquilescanta committed -
Against all odds, samples can be reordered by using drag & drop. Issue:#1706 Issue:#2283 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=177145553
aquilescanta committed -
We can acknoledge seeks before preparation finished immediately now, because ExoPlayerImpl won't leave the masking state until the first prepare operation is processed. As a side effect, it also cleans up the responsibility of the callbacks. Prepares are always acknowledged with a SOURCE_INFO_REFRESHED, while seeks are always acknowledged with a SEEK_ACK. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=177144089
tonihei committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=177141094
olly committed -
The ExoPlayerImpl implementation forwards the stop request with this optional parameter. To ensure correct masking (e.g. when timeline updates arrive after calling reset in ExoPlayerImpl but before resetInternal in ExoPlayerImplInternal), we use the existing prepareAck counter and extend it also count stop operations. For this to work, we also return the updated empty timeline after finishing the reset. The CastPlayer doesn't support the two reset options so far. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=177132107
tonihei committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=177063576
olly committed -
Feature/iso8601 parser 2
ojw28 committed -
Pavel Stambrecht committed
-
Pavel Stambrecht committed
-
- 28 Nov, 2017 1 commit
-
-
ojw28 committed
-
- 27 Nov, 2017 14 commits
-
-
Merge of https://github.com/google/ExoPlayer/pull/3495 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=177057183
olly committed -
Unconditionally waiting for the action schedule to finish in ExoPlayerTestRunner doesn't work if the action schedule is not intended to be finished. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=177024139
tonihei committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=177011497
tonihei committed -
Also slightly improve language normalization/documentation. For this CL, it is assumed that null and "und" languages are different entities. Once we fully tackle language tag normalization, we can decide whether to normalize the "undefined" language. Issue:#2867 Issue:#2980 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=177008509
aquilescanta committed -
Guard against out-of-range timestamp
ojw28 committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=176997767
tonihei committed -
A message to stop the playback and to quit the playback thread was posted in release(). The stop message removed all other already queued messages which might include the second message to quit the thread. That led to infinite waiting in the release method because the playback thread never got the quit signal. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=176997104
tonihei committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=176989632
andrewlewis committed -
Update the default AdaptiveTrackSelection and DefaultLoadControl to use playback speed information. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=176989168
andrewlewis committed -
currentTimeMillis is not guaranteed to be monotonic and elapsedRealtime is recommend for interval timing. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=176853118
andrewlewis committed -
Fixed by explicitly waiting for the timeline update. This shouldn't be necessary and will be removed as soon as the correct order of events can be guaranteed (timeline change -> state change -> onSeekProcessed). The waiting for the timeline update is implemented by introducing the feature that the test runner also waits until the action schedule has finished before stopping the test. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=176848540
tonihei committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=176837939
andrewlewis committed -
In a test run where no exceptions were thrown on the main thread and the test did not time out, exceptions from onPlayerError were not correctly propagated to the test thread (handleException would be called with null). Fix ExoPlayerTestRunner.onPlayerError to propagate the actual exception from the player. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=176825907
andrewlewis committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=176821463
baiming committed
-
- 24 Nov, 2017 1 commit
-
-
We've found that in our production environment, the AAC stream's timestamp exceeds the 33bit limit from time to time, when it happens, `peekId3PrivTimestamp` returns a value that is greater than `TimestampAdjuster.MAX_PTS_PLUS_ONE`, which causes a overflow in `TimestampAdjuster.adjustTsTimestamp` (overflow inside `ptsToUs`) after playing for a while . When the overflow happens, the start time of the stream becomes negative and the playback simply stucks at buffering forever. I fully understand that the 33bit is a spec requirement, thus I asked our stream provider to correct this mistake. But in the mean time, I'd also like ExoPlayer to handle this situation more error tolerance, as in other platforms (iOS, browsers) we see more tolerance behavior.
simophin committed
-
- 23 Nov, 2017 8 commits
-
-
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=176768835
olly committed -
This change broke playback through playlists. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=176764830
olly committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=176763841
olly committed -
Also prevent skip when there's a pending reset, and add a TODO to split/fix chunk discard and downstream format change reporting. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=176760955
olly committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=176759080
tonihei committed -
This is mostly useful for suppressing the initial position discontinuity reported by ClippingMediaPeriod. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=176758972
olly committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=176749136
tonihei committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=176693785
olly committed
-
- 22 Nov, 2017 1 commit
-
-
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=176666247
olly committed
-
