- 05 Feb, 2022 7 commits
- 04 Feb, 2022 1 commit
-
-
Dustin committed
-
- 02 Feb, 2022 2 commits
- 01 Feb, 2022 4 commits
- 31 Jan, 2022 8 commits
- 30 Jan, 2022 4 commits
- 29 Jan, 2022 6 commits
- 28 Jan, 2022 8 commits
-
-
Dustin committed
-
https://github.com/google/ExoPlayer/commit/651fa0dbb7c935480ab82a4ddf370b43134a45ab
*** Original commit *** Apply suggested AVC profile depending on the API version. *** PiperOrigin-RevId: 424856077
claincly committed -
PiperOrigin-RevId: 424850283
andrewlewis committed -
Enforcing the correct thread usage has been enabled since 2.13.0. Opting-out of this enforement is dangerous as it can hide very hard to debug bugs. PiperOrigin-RevId: 424815808
tonihei committed -
If muxerWrapper.release() was throwing an exception, the progress state was not updated and getProgress could throw an exception. #minor-release PiperOrigin-RevId: 424696783
kimvde committed -
This shouldn't be required for transformer instrumentation tests, as they don't use a foreground service. PiperOrigin-RevId: 424654463
andrewlewis committed -
The second error is probably a consequence of the first one. #minor-release PiperOrigin-RevId: 424619944
kimvde committed -
When the decoder output buffer was partially read, a call to Codec.getOutputBuffer() was returning the same buffer, but with the position reset to 0. The reason was that, in Codec.maybeDequeueAndSetOutputBuffer(), mediaCodec.getOutputBuffer() was called with the same buffer index (L350 in old rev), even though there was already a buffer available (outputBufferIndex >=0). This change avoids calling mediaCodec.getOutputBuffer() if the previous buffer has not been released. #minor-release PiperOrigin-RevId: 424612197
kimvde committed
-