- 20 Oct, 2020 5 commits
-
-
1. The first time the player controls are are made visible, there is no animation. 2. The first time the player controls are made visible, the "select tracks" button isn't displayed. When tapping to subsequently hide the player controls, the button briefly becomes visible and then is hidden again. This bug is due to state in StyledPlayerControlViewLayoutManager being out of sync, resulting in StyledPlayerControlView's onVisibilityChange not being called properly. After this change both of these issues should be resolved. PiperOrigin-RevId: 336704031
olly committed -
This should fix gradle errors like: "warn: removing resource com.google.android.exoplayer2.demo:string/exo_controls_fastforward_by_amount_description without required default value." PiperOrigin-RevId: 336670827
andrewlewis committed -
We stopped using using this MIME type in https://github.com/google/ExoPlayer/commit/74a9d8f680995f2096c59fde6cd1ef6e85bb4d55 This broke subtitle decoding in some cases (Issue: #7985), which I fixed in https://github.com/google/ExoPlayer/commit/7b8895d655c9b48e042f66045bc9c7ab27e93346. After some discussion we've decided SubtitleDecoderFactory shouldn't depend on Format.containerMimeType (since the samples have already been extracted by this point, so the container shouldn't matter). So this change fixes DashManifestParser to use MimeTypes.APPLICATION_MP4VTT (and reverts the no-longer-needed SubtitleDecoderFactory change). PiperOrigin-RevId: 336668450
ibaker committed -
PiperOrigin-RevId: 336643621
ibaker committed -
Adjusted the bottom layout of StyledPlayerControlView : - Enlarged bottom button's height to make tapping easier. - Extended greyed background area to upper edge of seekbar. - Gave padding between bottom edge of the overall layout and bottom buttons. - Reduced horizontal margins between bottom buttons. PiperOrigin-RevId: 336041160
insun committed
-
- 17 Oct, 2020 35 commits
-
-
Issue: #8024 PiperOrigin-RevId: 335846035
bachinger committed -
The bug affects playlists that start with an I-FRAME only variant. Issue: #8025 PiperOrigin-RevId: 335819497
aquilescanta committed -
PiperOrigin-RevId: 335642909
andrewlewis committed -
Issue: #8005 PiperOrigin-RevId: 335625992
kimvde committed -
Context: Issue: #7988 PiperOrigin-RevId: 335608610
kimvde committed -
Issue: #7944 PiperOrigin-RevId: 335012643
andrewlewis committed -
`subtitle` is only guaranteed to be non-null if `nextSubtitleEventIndex != C.INDEX_UNSET`. The null check added in https://github.com/google/ExoPlayer/commit/0efec5f6c12a5d583f24c122fbcbc1b1eebbabc3 was too early. Issue: #8017 PiperOrigin-RevId: 334777742
ibaker committed -
This was broken by https://github.com/google/ExoPlayer/commit/74a9d8f680995f2096c59fde6cd1ef6e85bb4d55 because DashManifestParser switched to setting Format.sampleMimeType to text/vtt while SubtitleDecoderFactory was still expecting application/x-mp4-vtt. This change teaches SubtitleDecoderFactory to check both Format.containerMimeType and Format.sampleMimeType. I'll investigate a follow-up change to remove MimeTypes.APPLICATION_MP4VTT completely (it's currently still used in AtomParsers). Issue: #7985 PiperOrigin-RevId: 334771672
ibaker committed -
This holds shared test infrastructure that needs to depend on Robolectric. PiperOrigin-RevId: 334604041
ibaker committed -
When I moved ParsableByteArray#data behind a getter I replaced some assignments with calls to reset(byte[]): https://github.com/google/ExoPlayer/commit/ce2e6e2fd625db787b1f400614adcd7458144bbd reset(byte[]) deliberately sets `limit` to `data.length`, in order to handle cases that were reassigning `data` but not updating `limit`. However OggPacket was already using `limit` to track where to write 'new' data into the array, so changing `limit` to `data.length` caused us to try and write new data beyond the end of the array. I looked at other uses of reset(byte[]) in https://github.com/google/ExoPlayer/commit/ce2e6e2fd625db787b1f400614adcd7458144bbd and condluded the only other usage in MatroskaExtractor is legit and shouldn't be updated like this (because MatroskaExtractor previously *wasn't* correctly updating/maintaining `limit`). Issue: #7992 PiperOrigin-RevId: 334601586
ibaker committed -
PiperOrigin-RevId: 334567234
andrewlewis committed -
PiperOrigin-RevId: 334562209
andrewlewis committed -
Non-realtime AudioTrack playback speed was not taken into account when extrapolating the old mode's position, causing the position not to advance smoothly. This should be a no-op when not using AudioTrack playback params for speed adjustment. Issue: #7982 PiperOrigin-RevId: 334151163
andrewlewis committed -
Every other subtitleButton has an if not null check, but does not force non null. Issue: #7962 PiperOrigin-RevId: 334124323
samrobinson committed -
On receiving a fetch error for an ad that would otherwise play based on an initial/seek position, the pending content position wasn't cleared which meant that position reporting was broken after a fetch error. Fix this by always clearing the pending position (if there was a pending position that will have triggered the fetch error). Also deduplicate the code for handling empty ad groups (fetch errors) and ad group load errors. Issue: #7956 PiperOrigin-RevId: 334113131
andrewlewis committed -
PiperOrigin-RevId: 333751261
Oliver Woodman committed -
Issue: #7949 PiperOrigin-RevId: 333733615
kimvde committed -
ISSUE: #7977 PiperOrigin-RevId: 333726625
bachinger committed -
PiperOrigin-RevId: 333712782
christosts committed -
Issue: #7967 PiperOrigin-RevId: 333709003
samrobinson committed -
Fix bug to place the negative sign in the beginning of the returned String. PiperOrigin-RevId: 333504868
christosts committed -
PiperOrigin-RevId: 333485323
kim-vde committed -
PiperOrigin-RevId: 333480727
tonihei committed -
This issue has been observed on a test app stress testing setEndOfStream. The issue has not been observed on ExoPlayer, probably due to timing differences, but it is fixed preventively. #exo-offload PiperOrigin-RevId: 333472136
krocard committed -
This seems to be an exact copy of sample.adts. Update the test to use the same sample but just output to a different dump file. PiperOrigin-RevId: 333469714
ibaker committed -
These are from https://medium.com/google-exoplayer/improved-japanese-subtitle-support-7598fee12cf4 PiperOrigin-RevId: 333296789
ibaker committed -
PiperOrigin-RevId: 333272292
andrewlewis committed -
PiperOrigin-RevId: 333051018
andrewlewis committed -
We have a workaround for uneven sample stream durarions in playlists that assumes a renderer allows playback if it's reading ahead or waiting for the next stream. https://github.com/google/ExoPlayer/commit/652c2f9c188bf9d9d6e323ff5333e5026454a082 changed this logic to no longer require to wait until the next stream is prepared due to a change in how we advance media periods in the queue. However, the code falsely still requires the next stream to exist (even if it's not prepared). This can cause a stuck buffering state when the difference in the duration of the streams is more than what we buffer ahead because we never create the next stream in such a case. Note: DefaultMediaClock.shouldUseStandaloneClock has roughly the same logic and also doesn't require the next stream to be present. Also fix a test that seemed to rely on this stuck buffering case to test stuck buffering detection. Changed the test to not read the end of stream to ensure it runs into the desired stuck buffering case. Issue:#7943 PiperOrigin-RevId: 333050285
tonihei committed -
PiperOrigin-RevId: 333031399
ibaker committed -
https://github.com/google/ExoPlayer/commit/f2c51560c21bdd757c30678223345fa8f59fb82b
PiperOrigin-RevId: 333031301
tonihei committed -
PiperOrigin-RevId: 333029935
tonihei committed -
PiperOrigin-RevId: 333023580
olly committed -
We're not using regex so there's no need to use replaceAll() PiperOrigin-RevId: 332865724
ibaker committed -
Without this patch, playback would be frozen indefinitely until the user manually pauses and unpauses it. This has the side effect of disabling offload until the next stop due to the workaround of disabling offload when it encounters a failure. As an audio server crash is considered very infrequent, especially in stable conditions like an audio only playback, it is unlikely that disabling offload is an issue. PiperOrigin-RevId: 332857094
krocard committed
-