- 17 Jan, 2020 40 commits
-
-
This change makes it clear the SampleQueue doesn't outlive the wrapping PlayerTrackEmsgHandler, and releases it from PlayerTrackEmsgHandler.release(). This change is a no-op because calling release() is the same as reset() in this case (the behavior only differs if a non-dummy DrmSessionManager is being used). PiperOrigin-RevId: 289416622
olly committed -
As a result, onMediaChunkLoadStarted gets invoked on the loading thread, and init on the playback thread, matching the thread access comments. Issue:#6321 PiperOrigin-RevId: 289167981
aquilescanta committed -
PiperOrigin-RevId: 289092332
Oliver Woodman committed -
PiperOrigin-RevId: 289091494
olly committed -
PiperOrigin-RevId: 289054937
olly committed -
Unfortunately devices such as the MI 8 do not provide an alternative working decoder. Some Vivo devices do provide one though. PiperOrigin-RevId: 288911897
olly committed -
PiperOrigin-RevId: 288860159
olly committed -
PiperOrigin-RevId: 288855515
andrewlewis committed -
PiperOrigin-RevId: 288772277
Oliver Woodman committed -
This improves readability by making clearer that reading no bytes from the input in readFrames() is an expected case if the buffer is full. PiperOrigin-RevId: 288711841
kimvde committed -
This doesn't work because the Chronometer text layout can only count in realtime. Issue:#6816 PiperOrigin-RevId: 288711702
tonihei committed -
Issue: #6845 PiperOrigin-RevId: 288688716
andrewlewis committed -
PiperOrigin-RevId: 288667790
kimvde committed -
Issue: #4078 PiperOrigin-RevId: 288651166
olly committed -
PiperOrigin-RevId: 288468497
olly committed -
PiperOrigin-RevId: 288464154
kimvde committed -
PiperOrigin-RevId: 288304477
olly committed -
- Simulate IO exceptions in the test using FlacBinarySearchSeeker for seeking in FlacExtractorTests. This makes the test slower but covers more test cases. PiperOrigin-RevId: 288285057
kimvde committed -
PiperOrigin-RevId: 288292488
olly committed -
PiperOrigin-RevId: 288280500
tonihei committed -
This typo was introduced in https://github.com/google/ExoPlayer/commit/ddb70d96ad99f07fe10f53a76ce3262fe625be70 when migrating a static method with parameter `durationUs` to an instance method where the correct field to use was `blockDurationUs` (but `durationUs` also exists). The test that catches this was only added in https://github.com/google/ExoPlayer/commit/45013ece1e3fe054ff8960355a89559241eeb288 (and therefore configured with the wrong expected output data). issue:#6833 PiperOrigin-RevId: 288274197
ibaker committed -
PiperOrigin-RevId: 287973192
kimvde committed -
PiperOrigin-RevId: 287999703
olly committed -
Issue: #6552 PiperOrigin-RevId: 287964221
andrewlewis committed -
PiperOrigin-RevId: 287854701
olly committed -
Issue: #5789 PiperOrigin-RevId: 287828559
olly committed -
Issue: #6779 PiperOrigin-RevId: 287828273
olly committed -
Issue: #6266 PiperOrigin-RevId: 287821640
olly committed -
Issue: #6602 PiperOrigin-RevId: 287816831
andrewlewis committed -
It's unreliable for at least one IMA ADPCM file I've found. Calculating the blockIndex to seek to using exact properties also seems more robust. Note this doesn't change anything for the existing PCM test, since averageBytesPerSecond is set correctly. It does make a difference for an upcoming IMA ADPCM test though. PiperOrigin-RevId: 287814947
olly committed -
PiperOrigin-RevId: 287810018
andrewlewis committed -
Issue: #6733 PiperOrigin-RevId: 286621715
olly committed -
PiperOrigin-RevId: 286197990
olly committed -
Add support for MP3 as an encoding format for passthrough. This change does not change the observable behavior of Exoplayer. Also name the magics. #exo-offload PiperOrigin-RevId: 286146539
krocard committed -
PiperOrigin-RevId: 285823771
kimvde committed -
Fix the FlacExtractor constructor for the case where seek(0,0) is not called before reading. PiperOrigin-RevId: 285811161
kimvde committed -
PiperOrigin-RevId: 285799995
kimvde committed -
- Make extractor output samples that are uniformly distributed with respect to time, with a target of ~10 samples per second. The old approach could in theory put every frame into its own sample, which would be very inefficient downstream because we'd need to pass them individually to MediaCodec. It could also put data corresponding to a long duration of time into a single sample (e.g. if the sample rate of the content is low), which is bad downstream because we decide whether to set the decodeOnly flag on a per sample basis. More generally, the new approach is more predictable :). - Stop using the WavSeekMap to get sample timestamps, and instead calculate them directly from the number of frames output. It's more obviously correct, particularly for data formats like IMA ADPCM where we'll need to adjust the data prior to output. PiperOrigin-RevId: 285750010
olly committed -
PiperOrigin-RevId: 285716982
andrewlewis committed -
PiperOrigin-RevId: 285407744
olly committed
-