- 07 Apr, 2018 3 commits
-
-
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=191704629
andrewlewis committed -
Previously the SonicAudioProcessor and SilenceSkippingAudioProcessor would track their pending playback parameters and only apply them in flush(). Having the values only take effect once flushed made the processors a bit more difficult to use, especially because the value returned by isActive wouldn't update immediately. Make DefaultAudioSink only set the new speed/pitch/skip silence setting after the audio processors have drained. This means it's no longer necessary to keep track of pending parameter values and also fixes a bug where initial playback parameters weren't applied because the audio processors weren't flushed while uninitialized before DefaultAudioSink called isActive() on them. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=191586727
andrewlewis committed -
The previous API allowed to pass in null to the constructors although variants without listeners exist. That's why we need to handle these null values. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=191577891
tonihei committed
-
- 04 Apr, 2018 2 commits
-
-
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=191561921
olly committed -
Partial rollback of [] which caused b/77294898 by deleting a public Exoplayer API. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=191519591
sxp committed
-
- 03 Apr, 2018 13 commits
-
-
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=191442704
olly committed -
Previously it was necessary to create a new Sonic instance every time the processor was flushed. Add a flush() method to Sonic so that it can be reused when seeking. It still needs to be recreated when parameters change. SonicAudioProcessor and SilenceSkippingAudioProcessor have methods for setting parameters that are documented as taking effect after a call to flush(), but actually the value returned by isActive() was updated immediately. Track the pending values and apply them in flush() to fix this. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=191442336
andrewlewis committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=191422866
olly committed -
- Upgrade to latest version - Use api dependency, since application code that uses the extension more has to use OkHttp directly to make an OkHttpClient instance - Add proguard configuration Issue #4059 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=191422594
olly committed -
We currently refresh repeatedly in this case. According to the DASH spec omitting minUpdatePeriod indicates that the manifest does not change, and therefore we should not refresh. I think it might be valid to omit minUpdatePeriod in a dynamic manifest if relying exclusively on EMSGs to trigger manifest refresh. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=191420247
olly committed -
Issue #4059 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=191419955
olly committed -
applyContentMetadataMutations and getContentMetadata methods suppossed to be synchronized and assert the instance isn't released. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=191419637
eguven committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=191418665
olly committed -
Issue: #4059 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=191414566
olly committed -
This is in preparation for making it possible to flush a Sonic instance so that it's not necessary to create new ones every time the processor is flushed. There should be no behavior changes here. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=191410326
andrewlewis committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=191409777
olly committed -
Issue: #3723 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=191407560
olly committed -
To be immediately rolled back after submission Submitting on behalf of cblay. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=191128111
danarapagna committed
-
- 29 Mar, 2018 22 commits
-
-
- Fix typo - Reinstate copy step. It's needed for images ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=190976774
olly committed -
- Remove stray extra "/" from postprocessed oracle URLs - Remove date lines so the Javadoc diff better shows what actually changed between releases ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=190973079
olly committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=190942033
olly committed -
Weirdly, the Android Javadoc indicates that it returns something before the API level on which the same Javadoc states it was added. In any case, we can simply not call the method to avoid the warning, since we only use the value if the API level is at least 23 anyway. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=190941776
olly committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=190941619
olly committed -
Video renderers assume that the player position is advancing linearly while in the started state. MediaCodecVideoRenderer schedules frames for rendering in the future in the expectation that the player position is advancing. This assumption is not currently true when using a position from the AudioTrack: the player position can be fixed for (in the worst case) up to about 100 ms before it starts increasing. This leads to an effect where the first frame is rendered then a few other frames are rendered, then there's a pause before frames start being rendered smoothly. Work around this issue by checking whether the position has started advancing before scheduling frames to be rendered in the future. It might be preferable to make the audio renderer only become ready when its timestamp can start advancing, but this is likely to be complicated. Issue: #3841 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=190937429
andrewlewis committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=190927811
andrewlewis committed -
Issue: #3729 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=190922866
eguven committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=190917894
andrewlewis committed -
In audio processors an audio frame consists of a sample (which is 2 bytes for 16-bit PCM) for each channel. Sonic used "sample" to refer to this. We've already diverged from the original source for Sonic quite a bit (deleting code and making stylistic changes) and there haven't been upstream changes so far, so it seems fine to start making more substantial changes here. There should be no behavior changes here. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=190916793
andrewlewis committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=190916130
olly committed -
Use string concatenation for Metadata.Entry instances, and add Util.formatInvariant for numerical formatting. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=190915643
andrewlewis committed -
This adds two options to the ClippingMediaSource which allow proper clipping of live streams: 1. The clipping stays fixed relative to already created media periods. That means that playback actually progresses through the clipped media and eventually reaches the end of the clipping. The window is also marked as non-dynamic to let playback end in this case. 2. Allow to specify a clipping duration relative to the default position to be able to specify the duration of live stream which is to be played. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=190911049tonihei committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=190907004
tonihei committed -
*** Reason for rollback *** b/76391022 was caused by a timestamp correction in StabilizableSimpleExoPlayer which will be fixed with this CL. *** Original change description *** Automated g4 rollback of changelist 189570277. *** Reason for rollback *** causes b/76391022, motion still playback in Photos is broken *** Original change description *** Used fixed time frame in clipping media period. Currently, whenever the clipping is updated, we move the time frame of the clipped period to start at 0. This causes problems when we are already playing this period and the renderer position does no longer match the stream positions. This change keeps the time frame of the... *** ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=190906020
tonihei committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=190896757
olly committed -
- Ensure that no memory is used by audio processors that are always inactive, by only allocating in flush() if active. If data was already allocated but a processor becomes inactive we assume that the allocation may be needed in future so do not remove it (e.g., in the case of ResamplingAudioProcessor). - Make SilenceSkippingAudioProcessor set up its buffers in flush(), and clarify that it is always necessary to call flush() if configure() returns true. - Make reset() reset all state for all processors. - Use @Nullable state or empty arrays for inactive audio processor buffers. - Miscellaneous style/consistency cleanup. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=190895783
andrewlewis committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=190817805
eguven committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=190787979
aquilescanta committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=190787884
eguven committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=190782395
eguven committed -
A merge error in a previous change removed the drmSessionManager from the player factory call. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=190769364
tonihei committed
-