- 07 Apr, 2018 9 commits
-
-
In MatroskaExtractor TrueHD audio samples are joined into larger chunks. For some streams the resulting chunked samples seem never to start with a syncframe. This could result in playback of TrueHD streams getting stuck after seeking because we could never read a syncframe at the start of a sample to determine the sample size. Instead of expecting to find a syncframe at the start of a sample, search for it within the sample, to fix this issue. Note: this means that we may search a few thousand bytes to find the sample size, but the cost is only incurred for the first audio sample read. Issue: #3845 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=191775779
andrewlewis committed -
Also increase the chunking size to sixteen samples. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=191768169
andrewlewis committed -
This field (formerly "id") is almost impossible to use so far. Having setters in the factories allows to specify custom tags for all media sources. Also added a ExoPlayer.getCurrentTag() method to retrieve the tag of the currently playing media source in a convenient way. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=191738754
tonihei committed -
The data collector keeps track of active media periods to assign each event to the correct media period and/or window. This information, together with other information like playback position and buffered duration, is then forwarded with the event to all registered listeners. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=191726408
tonihei committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=191722477
hoangtc committed -
Issue: #4084 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=191716636
olly committed -
------------- 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 16 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
-