- 09 Jul, 2019 13 commits
-
-
PiperOrigin-RevId: 256147805
Oliver Woodman committed -
1. Only output video starting from a keyframe 2. When calculating the timestamp offset to adjust live streams to start at t=0, use the timestamp of the first tag from which a sample is actually output, rather than just the first audio/video tag. The test streams in the referenced GitHub issue start with a video tag whose packet type is AVC_PACKET_TYPE_SEQUENCE_HEADER (i.e. does not contain a sample) and whose timestamp is set to 0 (i.e. isn't set). The timestamp is set correctly on tags that from which a sample is actually output. Issue: #6111 PiperOrigin-RevId: 256147747
olly committed -
Issue: #6047 PiperOrigin-RevId: 255992898
bachinger committed -
Issue:#6109 PiperOrigin-RevId: 255933121
tonihei committed -
PiperOrigin-RevId: 255584000
andrewlewis committed -
ISSUE: #6093 PiperOrigin-RevId: 255471282
bachinger committed -
PiperOrigin-RevId: 255380796
olly committed -
Also add layer of indirection between code and the guide, to make moving content easier going forward. PiperOrigin-RevId: 255182216
olly committed -
Fix a super tiny typo.
Nam Nguyen Hoai committed -
These are mostly nullability issues. PiperOrigin-RevId: 253537068
tonihei committed -
This permission has normal access right and can't be revoked by the user. However, an app can choose to revoke it when using ExoPlayer, e.g. if no network is required and the app doesn't want to list this permission. Support this use case by gracefully catching the exception in the relevant places. Issue:#6019 PiperOrigin-RevId: 253759332
tonihei committed -
PiperOrigin-RevId: 254182080
Oliver Woodman committed -
We currently don't display the last frame because the seek time is behind the last frame's timestamps and it's thus marked as decodeOnly. This case can be detected by checking whether all data sent to the codec is marked as decodeOnly at the time we read the end of stream signal. If so, we can re-enable the last frame. This should work for almost all cases because the end-of-stream signal is read in the same feedInputBuffer loop as the last frame and we therefore haven't released the last frame buffer yet. Issue:#2568 PiperOrigin-RevId: 251425870
tonihei committed
-
- 26 Jun, 2019 1 commit
-
-
Oliver Woodman committed
-
- 23 Jun, 2019 1 commit
-
-
r2.10.2
Oliver Woodman committed
-
- 21 Jun, 2019 4 commits
-
-
Issue: #6016
Oliver Woodman committed -
Issue: #5928 PiperOrigin-RevId: 254379085
andrewlewis committed -
PiperOrigin-RevId: 254156143
olly committed -
Issue: #6073
Andrew Lewis committed
-
- 19 Jun, 2019 13 commits
-
-
Oliver Woodman committed
-
PiperOrigin-RevId: 253959976
bachinger committed -
ISSUE: #6041 PiperOrigin-RevId: 253958225
bachinger committed -
PiperOrigin-RevId: 253808562
olly committed -
We are currently queuing periods in a way such that the new start position lines up with the end of the previous period (to ensure continuous playback). However, if the start position of the new period is larger than the total of all previously played period durations, we may end up with negative renderer timestamps when seeking back to the beginning of this new period. Negative timestamps should be avoided as most decoders have problems handling them correctly. This change forces a renderer reset if we detect such a seek to a negative renderer time and also resets the renderer offset to 0 every time all renderers are disabled, as this is the only time where we can savely change the offset of an existing media period. Also, if playback starts with an ad, we choose the content position as renderer offset to prevent the whole issue from occurring for the seek-behind- midroll case. Issue:#6009 Issue:#5323 PiperOrigin-RevId: 253790054
tonihei committed -
Issue: #6031 PiperOrigin-RevId: 253784986
olly committed -
Issue:#6006 PiperOrigin-RevId: 253781533
aquilescanta committed -
In some edge cases the renderer position may be slightly ahead of the buffered position and the total buffered duration is thus negative. We already filter that in ExoPlayerImpl for the publicly accessible value. However, we forward the unfiltered value to other components like the LoadControl, which may be confusing. Issue:#6015 PiperOrigin-RevId: 253780460
tonihei committed -
PiperOrigin-RevId: 253762488
aquilescanta committed -
This permission has normal access right and can't be revoked by the user. However, an app can choose to revoke it when using ExoPlayer, e.g. if no network is required and the app doesn't want to list this permission. Support this use case by gracefully catching the exception in the relevant places. Issue:#6019 PiperOrigin-RevId: 253759332
tonihei committed -
PiperOrigin-RevId: 253593267
bachinger committed -
PiperOrigin-RevId: 253228214
Toni committed -
arodriguez committed
-
- 18 Jun, 2019 3 commits
-
-
Marc Baechinger committed
-
Marc Baechinger committed
-
Marc Baechinger committed
-
- 06 Jun, 2019 4 commits
-
-
It's only thrown in an edge case on API level 20 and below. If it is thrown it causes playback failure when playback could succeed, by throwing up through configureCodec. It seems better just to catch the exception and have the codec be configured using the format's own width and height. PiperOrigin-RevId: 251745539
olly committed -
PiperOrigin-RevId: 251617354
aquilescanta committed -
Issue:#5955 PiperOrigin-RevId: 251616118
aquilescanta committed -
PiperOrigin-RevId: 251399230
aquilescanta committed
-
- 03 Jun, 2019 1 commit
-
-
PiperOrigin-RevId: 251216822
olly committed
-